Port A of PIC fried ?

Hi,

Im using a PIC16F877A. Is it normal to have all the pins of port A be 5V when nothing is connected except power ? The other pins are at 0V.

I suspect that I may have burnt my port A, because I accidentally sent about 10V into the Vref+ pin of port A (but only for a short while, about 1 sec). I also tried this simple code,

define osc 20

define adc_bits 10 'define number of bits in result
define adc_clock 2 'clock source 2 = Fosc/32 = 20Mhz
define adc_sampleus 50 'set sampling time in microsec

trisa = %11111111
trisd=0
adcon1 = %10000010


pause 500

adc var word

start:

adcin 0, adc

if adc > 10 then
high portd.0

else
low portd.0

endif

pause 500

goto start

Click to expand...

but the program couldnt run as expected. How do I check if my port A is OK ?

Thank you.

The PIC's header's files often (maybe always?) have the PIC digital ports set to high by default (as well as a default setting for almost everything else).

THe easiest way to check PortA is just to set the entire port low with a command that is something like PortA = 0b111...1 (use however many if you have an oscope just put two lines of something like


and you will see a square wave on the scope of the same frequency as the oscillator. THis is approximately C code, however. But I'm sure you understand what I mean if you are using something other language. Does your clock startup, first of all?

dknguyen said:

The PIC's header's files often (maybe always?) have the PIC digital ports set to high by default (as well as a default setting for almost everything else).

THe easiest way to check PortA is just to set the entire port low with a command that is something like PortA = 0b111...1 (use however many if you have an oscope just put two lines of something like

Code:

while(1)
{
   PortA = 0b111...1
   PortA = 0b000...0
}

and you will see a square wave on the scope of the same frequency as the oscillator. THis is approximately C code, however. But I'm sure you understand what I mean if you are using something other language. Does your clock startup, first of all?

Click to expand...

The weird thing is that only port A is high while the rest of the ports are low.
What do you mean by clock startup ?

edit:Im using PICBasic Pro language btw.

If you are using an external crystal and the circuit is right, you will only be able to see a Sine-wave on the clock pins of the PIC if the oscillator has properly started up (since the PIC contains the drivers for the oscillator circuit inside it).

BUt if other parts of your code are working it probably means your oscillator is fine. So you're saying that if you have code and all it does is set PortA low, it won't work? THen yeah, it might be busted.

EDIT: I noticed something. You know the TRIS register controls the whether the pin is an input or output right? Not the state of the pin. YOu don't seem to have code that does that for PORTA anywhere. In which case, the default state of the pins in the previously mentioned header files will take precedence making all the pins high (probably). And for the TRIS register, doesn't 0 make it an output and 1 make it an input? YOu seem to have set PORTA to be all inputs.

dknguyen said:

If you are using an external crystal and the circuit is right, you will only be able to see a Sine-wave on the clock pins of the PIC if the oscillator has properly started up (since the PIC contains the drivers for the oscillator circuit inside it).

BUt if other parts of your code are working it probably means your oscillator is fine. So you're saying that if you have code and all it does is set PortA low, it won't work? THen yeah, it might be busted.

EDIT: I noticed something. You know the TRIS register controls the whether the pin is an input or output right? Not the state of the pin. YOu don't seem to have code that does that for PORTA anywhere. In which case, the default state of the pins in the previously mentioned header files will take precedence making all the pins high (probably).

Click to expand...

OK so I tested a simple LED blink program using porta.0 and it works. So I guess its fine after all ? Then it must be my ADC code thats the problem..

Yup I know tris is to determine input/output. Do i have to set the state of port A as well ? I've seen many examples and they do not do this


edit : Yes, 1 is for input because im using port A to get an analog input.

Doesn't your

trisa = %11111111

Set port a to be all inputs? THat's what it seems to say in the datasheet for TRIS registers. If you want to output something over A you have to do this.

The reason the examples do not set explicity is because how they are by default in those header files are what they need.

Yes, I set tris=%111111 because I want all the ports to take input. Is something wrong there ?

Oh, sorry for the confusion, that code is for ADC input, not for testing for blinking LEDs. I tried a separate code for blinking a LED at porta.0 and it works fine.

But the simple ADC code above cannot work..

OK, figured out the problem, after testing all the port A pins a couple of times, turns out the ports are fine.. It was actually something wrong with the code even though I did not get any compile errors.

Yay for logical errors! If you can invent a compiler that will check for logical errors...well...you'd get something like SkyNet

Actually this part

define adc_bits 10
define adc_clock 2
define adc_sampleus 50

had to be in block letters