PIC16F877A not working again :(

[The Master]

Hi, Ive not touched 16F877A's for a while but now i need to use one again and im having more problems with it. Ive written some test code and ive tried mister_e's code from last time. My test code uses portD but ive tested ports A and B with mister_e's code too and im not picking anything up. Ive done all the usual checks (MCLR, Resonator, Capacitor etc). Ive checked the voltage with my oscilloscope and its extremely smooth. It almost looks like theres no load on it at all. The PIC is definately connected to it so im guessing its just not starting up correctly.

Im sure i got it working last time but i dont know how and im out of ideas now. I dont have any beer this time either . Does anyone have any ideas?

[skimask]

Hi, Ive not touched 16F877A's for a while but now i need to use one again and im having more problems with it. Ive written some test code and ive tried mister_e's code from last time. My test code uses portD but ive tested ports A and B with mister_e's code too and im not picking anything up. Ive done all the usual checks (MCLR, Resonator, Capacitor etc). Ive checked the voltage with my oscilloscope and its extremely smooth. It almost looks like theres no load on it at all. The PIC is definately connected to it so im guessing its just not starting up correctly.

Sir...SIR!!!!
Put down the PIC...now step away from the PIC...Hands behind your ankles...
Is it in backwards? Ya never, know...could happen...
And this is my favorite test code...absolutely nothing fancy, but it tells me that things are working...

temp var byte
trisa = 0  'set all the pins to outputs
trisb = 0
trisc = 0
trisd = 0
trise = 0
'also turn analog ports to digital and/or set cmcon if applicable
main:
temp = temp + 1
porta=temp
portb=temp
portc=temp
portd = temp
porte = temp
'put a pauseus xxx here if the fastest pin (bit 0 for each port) is entirely too fast
goto main

That way each successive pin on each port will have exactly half the frequency of the pin before it. Of course things change with each different type of PIC and it's application, i.e. whether or not I'm using MCLR as MCLR or an I/O, whether or not I'm using OSC1/OSC2 as clock pins or I/O, and so on and so on...

[The Master]

Its not in backwards. I know it can happen, Ive done it pleanty of times myself. Usually i put it in the programmer the wrong way. This is definately correct though. I am using the OSC1 and OSC2 pins for a 3 pin resonator (20MHz). MCLR is being used as MCLR. I dont see any options to use it as an I/O pin on this chip. It has a 10K resistor to VDD.

CMCON doesnt make much sense to me but that only seems to affect portA. My Code tested portD by turning 2 outputs on and off alternately. mister_e's code tests both portA and portB. I had trouble with portA before but at least portB worked. The only thing i see about portD is that it can act as a parallel port. The datasheet says trisE.4 must be set to enable "PSPMODE" but its default value is 0 so portD should be working as normal I/O pins.

The values of portD are unknown at startup. Usually that means the LEDs i have connected will flash sometimes when the PIC powers up. This time there not doing. Its like the chip is never turning on. I thought there might be a problem with my breadboard so i tested the power pins on the PIC and there is definately power getting there.

Ill have a go with your test code when i get home but for now ill continue reading the datasheet to see if there are any other registers that might affect it

[Acetronics2]

Ha,Ha,Ha

ive tried mister_e's code from last time.

 ifdef PM_USED
            device  pic16F877A, xt_osc, wdt_on, lvp_off, protect_off
        else
            __config _XT_OSC & _WDT_ON & _LVP_OFF & _CP_OFF
        endif
        endasm

I am using the OSC1 and OSC2 pins for a 3 pin resonator (20MHz).

Dit you also try to heat your pic, just some degrees ????

could be another solution ... the Hardware one

Alain

[The Master]

I know last time i was using a 4MHz one instead. Whats bad about using that code with a 20MHz?

The test code i wrote myself has "DEFINE OSC 20" at the top so that should have worked

Edit: The PIC didnt get noticably warmer at all

[skimask]

I know last time i was using a 4MHz one instead. Whats bad about using that code with a 20MHz?
The test code i wrote myself has "DEFINE OSC 20" at the top so that should have worked
Edit: The PIC didnt get noticably warmer at all

Check the datasheet, Oscillator section in particular...
Have to change the oscillator configuration from XT to HS when using a higher frequency crystal/resonator/etc.

[The Master]

I see. The datasheet says XT is for 200KHz to 4MHz. Anything above that is HS. I checked the datasheet for PIC16F87 too and that says the same thing yet ive been using one with a 20MHz resonator without setting it to HS. Ill change the 16F877A to HS when i get home

[skimask]

I see. The datasheet says XT is for 200KHz to 4MHz. Anything above that is HS. I checked the datasheet for PIC16F87 too and that says the same thing yet ive been using one with a 20MHz resonator without setting it to HS. Ill change the 16F877A to HS when i get home

I think you've just been lucky so far. Some of the various oscillator modes (XT, HX, etc) change the 'gain' inside the PIC, drive the crystal/resonator/whatever harder at higher freq's.
The F87 is a bit newer than the F877A. Maybe it's a bit more tolerant of that sort of thing.

[The Master]

So if i set it to XT when it should be HS then i dont risk blowing anyhting up it just means that the resonator might not have enough power to run correctly?

From what ive seen the PIC seems to be in a kind of standby mode. I do remember them doing the same kind of thing if the resonator isnt connected so that might be the problem.

[skimask]

So if i set it to XT when it should be HS then i dont risk blowing anyhting up it just means that the resonator might not have enough power to run correctly?

It's got nothing to do with 'power' in the way that you're thinking about it. It's the 'gain' for the oscillating signal that goes into/comes out of the crystal/resonator itself.
The higher the frequency, the more juice you need... i.e. takes more energy to swing an electrical signal back and forth at 20Mhz than it does at 4Mhz. (if you really want to go crazy, pull up the datasheet for any old op-amp and look at 'slew rate')
You won't blow anything by setting the wrong mode, it'll either work or won't. (well, I should re-state that a bit...you SHOULDN'T blow anything up)

From what ive seen the PIC seems to be in a kind of standby mode. I do remember them doing the same kind of thing if the resonator isnt connected so that might be the problem.

How can you actually quantify that 'seems to be in a kind of standby mode'. It's either working for you or not.

[The Master]

By that i meant in an idle state where its not doing anything. It doesnt appear to be using any power and its not changing the state of any output pins etc

[mackrackit]

By that i meant in an idle state where its not doing anything. It doesnt appear to be using any power and its not changing the state of any output pins etc

Can I quote/use that statement the next time a customer calls and complains said machine is not working.

The machine is just in an idle state, not to worry

[The Master]

Ive just reprogrammed the PIC chip with my origional test code but setting the oscillator to HS and it works.

Thanx for your help

[skimask]

Ive just reprogrammed the PIC chip with my origional test code but setting the oscillator to HS and it works.

Thanx for your help

As the great 'Quagmire' says...

Gigadee-gigadee, gigadee-goo...

[rxforspeed]

I've had the same exact problems myself, especially since I've been using either an 8 or 20MHz HC-49 case crystal in a lot of recent experiements. No matter what programming software is used, it always seems to default to "XT" instead of "HS". I usually forget to change the PIC in the drop-down menu in Microcode Studio from 16F628A to whatever PIC the program is for, but that's easy to find and correct when the program doesn't assemble correctly and gives a "too many errors" error message.

Is there an .ini file or another file I can modify to have the default settings in Microcode Studio automatically select the PIC I've been using most lately, and to default to "HS" instead of "XT" in the oscillator setting? Same question for the PICFlash software from mikroElektronika-anything I can modify to change the same default settings?

[mackrackit]

Is there an .ini file or another file I can modify to have the default settings in Microcode Studio automatically select the PIC I've been using most lately, and to default to "HS" instead of "XT" in the oscillator setting? Same question for the PICFlash software from mikroElektronika-anything I can modify to change the same default settings?

Have you seen this about the config settings for the PIC?
http://www.picbasic.co.uk/forum/showthread.php?t=543

[rxforspeed]

Thanks for the link, Dave! Once I get those default settings changed, I'm sure that'll save me quite a few frustrating moments...

[The Master]

Ive got another slight problem with this. Ive just tried to control some optoisolators using porte.0 and porte.2. For some strange reason the pins just wont turn on. I added some test code and the correct data is getting to the chip. It copies a bit from the serial data directly to the pin (EG, porte.0=btemp.0). Right after if i check the status of the pin it shows as 0. Ive had a look in the datasheet and i can see that porte gets used for parallel communications but i have set the tris registers to disable it and use it as a general I/O. I have something else connected to porte.1 and that works fine :S

Edit: It seems that changing the status of another pin is causing those pins to turn off. I had this the other night with portA too. Turning 1 output on would turn another off automatically. Im going to look through all the code again incase theres a silly mistake somewhere

[mackrackit]

What are you doing with the analog settings or pins.?

[The Master]

Im not using any analogue. The datasheet says analogue is disabled if ADCON1.0 is 0. It also says that its 0 by default.

I seem to remember these outputs working before by they arnt doing now. Ive not added any code that changes the state of those pins anywhere except the 1 line

[mackrackit]

Try adding this to the start of your code.

ADCON1=7 
CMCON=7

[The Master]

That worked Now ive just gotta read the datasheet and find out why

Thanx

[mackrackit]

That worked Now ive just gotta read the datasheet and find out why

Thanx

ADCON0.0 is the start/stop bit of ADCON0.

ADCON1 is where the pins are controlled. There is a table in the ADCON1 section.
Comparators are similar.

This also helps.
http://www.picbasic.co.uk/forum/showthread.php?t=561

Have Fun

[The Master]

Im sure ive been pointed to that thread before. I knew about the problem but i thought the settings i had would stop it. Aparently not. I must have misread the datasheet and completely overlooked CMCON.

I should probably read the whole datasheet when using a PIC. The only problem is that by about page 50 i cant remember what was on page 1. There are a few PICs (including the 16F877A) which seem to cover just about everything i do so hopefully if i just concentrate on these few ill get to know them better.

[mackrackit]

It just takes a little time. You are doing fine.

I only have a dozen or so chips that I use and many of them I do not use all of the features.

Still learning myself.