Sorry for OT, but I in big trouble!
From time to time my devices with above mentioned processors corrupt content of internal program memory. Does anyone see this behavior od 80C51ED2?
Dozsa Gyoergy
P.S. Keil C51 user since '91
Hi Gyoergy!! Im using this microcontroller now. Have you used this micro under RTX51??
Thanks
From time to time my devices with above mentioned processors corrupt content of internal program memory. I'll bet you are using RC reset. install a proper reset chip
Erik
install a proper reset chip
How would that fix the OP's problem?
that if you use RC reset (which do not hold the uC in reset during power down) your chip will occasionally lose its flash contents.
99% of the users of flash based '51s agree that if you use RC reset (which do not hold the uC in reset during power down) your chip will occasionally lose its flash contents.
This thread is not about 99% of users of flash based 8051 derivatives, though. It is about the AT89C51ED2.
Do you still think your solution will fix the OP's problem?
Hello Jack, Could you quickly explain how (and why) this kind of data loss can occur?
Do you still think your solution will fix the OP's problem? I'll bet you dollars to doughnuts that it will.
to the OP: you have not replied to: "do you have a RC reset?"
I've no idea - that's why I'm asking Erik why replacing the supposed RC reset circuit with a reset supervisor would fix this problem with the AT89C51ED2.
that's why I'm asking Erik why replacing the supposed RC reset circuit with a reset supervisor would fix this problem with the AT89C51ED2
already answered: (which do not hold the uC in reset during power down)
Even the magnificent Jack Sprat can not tell what a uC will do when outside the Vcc limits and not in reset.
These problems are always reported as "during power up" but they actually happen during power down.
Yes, I use reset IC. This is an device in (my) production seven years, without significant modification. In the past two years sporandic errors are reported from customers, eg. flash corruption. I can't reproduce this error in lab, testing with more than 10,000 power on/off cycles.
Georg
Erik, It this a problem specific to 51s (as suggested above) due to a design flaw?
It this a problem specific to 51s (as suggested above) due to a design flaw? no, it applies to all flash based micros.
the 'design flaw' is not realizing the situation at power down by the developer, not the chipmaker.
Yes, I use reset IC. good, then we have to hunt for the remaining 1% of causes. Which reset IC, partnumber, please. Do you have a decoupling cap directly across Vcc and Gnd on each and every chip on the board?
This is an device in (my) production seven years, without significant modification. In the past two years sporandic errors are reported from customers, eg. flash corruption. is this certain (one) customer(s) or across the board?
I can't reproduce this error in lab, testing with more than 10,000 power on/off cycles. it seems nobody can.
You keep repeating this without exlaining why it would matter.
I'm sorry to disappoint you, but I can.
Yes, RC resets are deadly to all forms of non-volatile data. But any chip with IAP capabilities can corruct the program in case the program runs awol, and the chip doesn't have a hardware-based lock support.
Have you seen any indications of watchdog resets or other troubles that may indicate that you may get a stack overflow or stack corruption? Are you using function pointers?