PIC problem

[llilrex]

I am having a problem with my PIC18F1220 keeping its EEPROM settings. it has thrown me for a loop for a while. Here is how it goes.

In simulation it works perfectly,

When running for the first time it loads default settings by detecting the presents of settings within the EEPROM

There after you load your settings Via. RS232 it places them in the EEPROM the EEPROM is then referenced every time the board is turned on.

Global variables are referenced and set when ever you communicate the settings as a "working" table independent from the EEPROM and are used for program operation.

What happens in real life is:

It does not load default settings on the first start up

it will set the working table as can be verified by the RS-232 com. but the program will not use them for program operation I.E. the Duty Cycle will show changed but the board will not use the new settings and the EEPROM will not be updated with the new settings.

A problem with my program you say? (of course!)

But here is the kicker!

if you program the PIC and then read the EEPROM from the programmer the first time it will show blank "all FFs" but if you load it the second time it will show that the internal (load default) subroutine has worked.

And on top of that. It all works perfectly after that!

I don’t get it! Its simple you just program it and run it and it does not work! You read the EEPROM two times and it Works exactly as it was designed!

if you mess with the power (brown outs) rapid on-off on-off cycles it will loose the EEPROM settings and you will have to re read the EEPROM twice to get it to work again.

I tried resetting with /MCLR but to no avail!

Has anyone else had this problem? ANY help will be greatly appreciated!

If you have an idea and want to see part of the code I will be happy to post it!

Thank you.

[MacGyver]

Post the routines (and any supporting code, such as #defines) related to your EEPROM read/write functionality. Unless your write routine is seriously unprotected, poor startups should not cause any issue with loss of EEPROM data. This leads me to believe either your code is not actually writing the EEPROM (and your programmer is), or you're calling the write routine without realizing it.

[llilrex]

Hmmm. I didn’t think of it writing to the EEPROM randomly I will have to look into it further. But it will reliably loose its settings after four hours of being turned off.

There is code that will look for an "off value" in one of the settings and if it sees this setting is "off value" it will automatically write the default to all of the setting. The default routine uses the routines listed below when writing to the EEPROM and is at a higher level and does it explicitly using hard coded data for values.

void PTEE (int DAT,int ADRS) //Writes data into the EEPROM
{
EEADR = ADRS;
EEDATA = DAT;
EECON1bits.EEPGD = 0;
EECON1bits.WREN = 1;
INTCONbits.GIE = 0;
EECON2 = 0x55;
EECON2 = 0xAA;
EECON1bits.WR = 1;
while(PIR2bits.EEIF == 0); //wait for write to complete
PIR2bits.EEIF = 0;
}

int GTEE (int ADRS) //Returns a byte stored in the address denoted by ADRS
{
EEADR = ADRS;
EECON1bits.EEPGD = 0;
EECON1bits.RD = 1;
return EEDATA;
}

int GetDutyCycle (void)
{
return GTEE(0);
}

void PutDutyCycle (int DC)
{
PTEE(DC,0);
}

[Horsedorf]

Is it possible that you have some of this stuff going on in an interrupt routine? And that you have an interaction with some variables between the background interrupt processing and the foreground processing that is touching variables inccorectly? ie.. in teh foreground, you go to read something, so you set up some registers, then in teh background something happens to alter one of those registers, then it returns from interrupt and your foreground routine tries to complete the read or write, only to have had the register change values?

Also, could you be using an array in an interrupt process that writes 'out of bounds' of the array and stomps on a foreground variable that is being used to index into the data you are working with?

Just a few kinds of things to look at that can seem totally unrelated until suddenly you notices that one peice of code that 'aint quite right'.

Good luck.

[llilrex]

thank you for the idea, I will look into this kind of thing, I am not using interupts in the software (exept for flagging) but there still can be other conflicts.

[Horsedorf]

Originally Posted by llilrex thank you for the idea, I will look into this kind of thing, I am not using interupts in the software (exept for flagging) but there still can be other conflicts.

Yeah, unless the device is like.. HORRIBLY broken, the kind of behaviour you are describing sounds symptomatic of 'rules of touch' being violated somewhere. It sounds like you have the kind of bug that is actually just an artifact of a completely unrelated section of code. Those are the ones that are usually hardest to find.

Some tricks to try.. Use one or more unused IO pins to drive led's (Or a logic analyzer if you are lucky enough to have one) when sections of code are entered or exited or variables are set or cleared. They can sometimes help you find what's going on. ANother trick is if you have teh serial port free, to simply write a character into the serial port or the value of a variable of interest and do so at different points of execution of the code to see if it is changing in ways you don't expect.

The downside is, of course, that this will slow down execution of the code which could make it work correctly, or break it even further. Anyways, I hope one of these tricks helps you find what's going on . If it DOES get you to the solution, then you owe me a beer. LOL

Good luck!
Rick

[neilw20]

What programmer/development paltform are you using?

I have had weird EEPROM telling lies type issuse before.

PC gets confused between what is in it's EE image which it displays.
I have have had issuses where you write some stuff.
PC says it not here. PIC says it is. Exit, restart PC program. Magically appears.

Some screwy logic regarding stale/fresh EE state in PC can be misleading.
Believe what the PIC does, and guess waht the PC sees!

50% chance you've screwed it, 25% USB latency, 25% opearting system (today anyway).