Eeprom accidentally erased?

[Josuetas]

Hi, i´ve had this problem before, i store configuration DATA of some device in the Eeprom memory but seems to get erased for no reason!

Has someone experienced this before?

What could be the reason for this behavior?

This is really troublesome because the device just stops working and has to be configured all over again!

Thanks for your replies!

[BrianT]

Hello Josuetas,
I recently had a similar issue with the PIC 18LF4620. Here the battery running the system went completely flat so the processor was working well off the datasheet and out in no mans land. I had six systems all display an identical fault. The same three locations in EEROM were scrambled. These were at locations 44, 45 and 47 (decimal). These cells are read by the code every hour but are NEVER written to by the code other than via the DATA statement at program load time.

What was particularly noticeable was that the flash program code memory was all FF from about location 60 to the top of memory. All six showed exactly the same erasure. LVP is turned off in the configuration fuses and the PGM, PGC, PGD and LVP pins are all floating.

Because the code memory was all erased the bootloader would not work so retrieving data from the external was a challenge. In future all my boards will have ICSP pinouts to a header as well as the bootloader.

HTH
Brian

[Jerson]

One of the possibilities is a stack failure. You havent said which device you use. So, if its one with a 2 level stack, the possibilities of stack failure increase. I usually avoid nesting GOSUBs beyond 4 calls since PBP needs around 4 calls to itself in different instructions. So, if you want to play safe, keep GOSUBs to the minimum.

A run away stack will drive you nuts for days on end. I've experienced this and its very hard to tell whats breaking the program flow. If your code is not very big, you could put it through MPSIM and monitor the stack level.

Just my thoughts

[mister_e]

or use MicroCode ICD if at all possible with your device.

few times ago i posted a little something. Have a look at post #5 of the following.

PIC16F917 stack issues
http://www.picbasic.co.uk/forum/showthread.php?t=5746

But yeah MPSIM would be a nice choice.

[Melanie]

I'm sorry but I have to disagree with Stack Failure causing corruption of EEPROM space.

I use a lot of 18F2420's in a particular application which is several years old and there are hundreds built and continue to be built...

I have had a batch (this spring/summer) that were exceptionally sensitive to noise and corrupted randomly internal EEPROM (I do a CRC check on EEPROM as part of the Power-On Tests). Changing BOR and various other parameters didn't help. Using MCLR pin as PORTE.3 input seemed to also be a problem.

I changed PORTE.3 back to MCLR usage and connected it directly to Vdd... that helped a lot but didn't eradicate the problem altogether.

I was running out of time... Fortunately, there was an external EEPROM with spare space available on the board. I changed all the internal EEPROM routines to external EEPROM and abandoned using the internal EEPROM on this application altogether. Not had a problem since - 100% reliable.

When the 18F's first came out, they were VERY sensitive to noise - almost to the extent they were unreliable. I think Microchip addressed these issues because the reliability of the 18F parts today is nowhere near as bad as it was some years back. However, occasionally, I think an odd batch gets out...

Also, I think this next comment is going to be contentious - especially amongst those that resell Microchip parts. The only and I repeat ONLY time I have EVER experienced PIC problems is when they have been sourced from resellers. When purchased from Microchip directly, there has NEVER been any problem. OK, sometimes Microchip is out of stock, and production must go on... so sourcing from elsewhere is unavoidable... but I have suspicions that sometimes the stock you receive isn't 'fresh'. Years after you think all the issues have been resolved with a part, you end up buying from a distributor/reseller that has had product on the shelf for Gawd knows how long with resultant consequences...

[Josuetas]

Ok, about the device i am using it´s PIC16F628A.

And i DO am using the MCLR pin as input, might that be any reason?.

By the way Melanie, why would doing CRC help any good? i would still have to reconfigure the device and this is really BAD!!!

Now i don´t know if the discussion should be open here but.. this error seems to be of the device, else microchips. Does this happen to the uC`s of other companies like ATMEL or MOTO? You guys know that none cares if it´s the device, ultimately it`s the designers fault!. If this keeps happening to me i would have to change to other brands to avoid such bothers! Wouldn´t you? We need faultyless bases to develop our devices don´t we?

I still hope this can be fixed, could some other configuration help me avoid the problem? i don`t have any extra memory outside the device and if for some reason is a stack problem i am not using any gosub... just GOTO sentences in my program.
What could be worst is that the number don´t just gets erased to FF or 00 but takes any random number wich means a different configuration for the firmware.

Could a Voltage peak at startup be the reason? i don´t get how programming works or even how LVP works (628 doesn´t have this does it?)

I will try this, maybe store the same data (it´s just one byte) in two or three different places of the memory and handle differently if they don´t match.

Thanks for your replies.

DJC

[Acetronics2]

Hi, Josuetas

I use a lot of 628s on R/C equipments . To the day I did not get any problem with EEPROM ( all the working parameters are stored in EEPROM )

The only thing is EEPROM is only accessed at programming time ( a jumper has to be placed to enter this mode and allow Writing ), or at startup, as values are read/verified/pasted in RAM. But no access during run mode.

Over that, writing to the EEPROM is protected by a Voltage detector ( MC34034P5 )... also active in run mode.

But, MCLR pin is used as external reset ... without any brownout ( no reset admitted ! ).

Alain

[Bruce]

I had the exact problem on a 16F627A. It was caused by entering a routine at power-up
that wrote to EEPROM.

The cure was as simple as adding a short delay at power-up to allow things to stabilize.

See if adding a short delay at power-up doesn't cure this.

[Luciano]

What could be worst is that the number don´t just gets erased to FF or 00 but takes
any random number wich means a different configuration for the firmware.

Hi,

This is where the CRC will help you. If the CRC calculated at startup is not the
same as the CRC you have stored in the EEPROM the last time you have written the
settings into the EEPROM, then the system will not start and will display "ERROR".

Best regards,

Luciano

[mister_e]

Now i don´t know if the discussion should be open here but.. this error seems to be of the device, else microchips. Does this happen to the uC`s of other companies like ATMEL or MOTO?

i heard it happen on most popular brands, not always in the eeprom section, sometimes in the code section as well.

Can you post your schematic, code and your config fuses? ... just for my own curiosity. If, for some reason, you can't post it in the public area, you can post it on my e-mail.

[Jerson]

I have my electronic safe working around the 628A and it works like a song. Out in the field for years now. Never had a problem with eeprom corruption. I save the user codes in EEPROM and read them from there for comparison.

I suspect your code is 'running away' either due to power glitches or maybe an oversight in coding. To confirm this theory, I can suggest you to try MPSIM(I use it extensively to debug). Put a breakpoint on every WRITE statement which puts data into the EEPROM. This you can find by getting the addresses from the LST file. Then just run your code. If it breaks, you have the answer.

Power line glitches may be hard to catch. In my case, the safe works off 4 D size cells (6V in all) directly. I know I am violating the Vcc(typ) spec. However, what I'm trying to convey is to power the unit by batteries if you suspect power line glitches.

Hope you are able to 'catch the culprit'.