MC68HC05B32 EEPROM cleared problem

[DonG]

Hi,

We have been using the MC68HC05B32 devices for years without any problems (until recently).

Recently, some of our customers have reported that the contents of the onboard EEPROM have been wiped out. It appears that all of the bytes have changed to zeros.

What would cause the contents of the onboard EEPROM to suddenly change to zeros?

Thanks.

Don

[DonG]

A little more information...

It appears that something is damaging the onboard EEPROM in some MC68HC05B32 devices. Once damaged, the EEPROM will no longer stay programmed. The bytes slowly change from ones to zeros within half an hour of being programmed.

We are not sure if this is relavent, but customers usually notice this problem after a power disruption.

Any ideas as to what might damage the onboard EEPROM?

[DonG]

If you wear out a byte in EEPROM, would the bits unexpectedly change to zeros or ones?

[Encoder]

I started using 68HC705B16 in 2002.

In the first 6 month of production we were plagued by sudden and scattered changes in the EEPROM contents, where some cells varied with no apparent reason.

We spent hundreds of hours improving our routines, we introduced a second EEPROM area in which we copied our main data (we used only some 80 bytes on each bank on the main 255 bytes of EEPROM area) and we managed them with CRC and comparing the two banks. We stopped any action when the voltage before the main regulator was approaching a safe lower limit, but no success: EEPROM continued to fail randomly till eventually complete failure. We were able to reprogram EEPROM from scratch but some CPU were completely damaged and unrecoverable.

Some apparatus where plagued more than others in different places. We were desperate....

We came out from the tunnel when discovered that the problem appeared only at turn-off turn-on at a fast pace (short dips, perhaps 1 second off than on). We made an automatic mains relay switch driven by a 1Hz generator and discovered that after some ten to some hundreds switch, EEPROM weared always, no matter which routine we used to protect it.

Having found that, we introduced a hardware reset manager completely fixing our problems. We tested near istantaneous reset manager (MC33164) and delayed ones (MCP130) with identical results: after that we where able to test up to 10000+ on/off mains switching with no problems.

We continue using that design till now with utmost success and great reliability: we will be forced to redesign our controller in next months because Freescale announced last orders and production stop on next August....

We did not thougth to introduce an external voltage supervisor earlier on the design table because of the declared internal reset action of the 68HC705B family and because we already used other Motorola smaller CPUs with no EEPROM and no external reset supervisor with not any single problem.

Encoder

[DonG]

Thank you for posting such a detailed response.

If I understand correctly, you had EEPROM reliability problems when the power to the 6805 was repeatedly turned on and off. Is that correct?

Don

[JimDon]

Not so much just cycling the power, the chip did not reset properly when this happened.

The IC he mentioned will hold reset down when Vcc gets below a certain voltage so the mcu will not attempt to run at a low voltage.

It sounds like using the EEPROM with low voltage kills it.

[bigmac]

Hello,

My previous experience with HC705 devices was that an external LV reset was always necessary for reliable operation, not just for MCUs with internal EEPROM.  The main issue seemed to be reliable start-up and operation after "brown-out" conditions had occurred, insufficient to initiate a POR.

Regards,

Mac

[DonG]

Hi,

Thanks for the suggestions.

We are using the MC68HC05B32 devices in transfer switch controllers. They are periodically exposed to supply voltage fluctuations. We are using a MC34164P to detect low supply voltage conditions.

We have thousands of these units in the field, and for some reason, the EEPROMs in some of these units have been cleared recently. So far, we haven't been able to figure out what is going on.

Thanks.
Don

[JimDon]

How often does it get written and how many years?


EEPROMS are only good for so many cycles. It can add up.

[DonG]

Hi Jim,

Most of the bytes in the EEPROM are rarely changed.

I would expect an EEPROM to wear out on a byte by byte basis. I wouldn't expect all of the bytes to change to zeros simultaneously. Does that sound like a reasonable assumption?

Thanks.

Don

[allawtterb]

That does sound reasonable, you might even expect them to fail on a bit by bit basis.  Have you had any of these returned to test that you can't program the EEPROM anymore?

[DonG]

I just submitted a service request.

We are waiting for some failed units to arrive.

[JimDon]

Hard to say, but yes that does sound reasonable.
If nothing else has changed that could cause a problem, I would submit a service request.
There could well be a know issue with this.
There is not much 05 expertise here, and tech support may already have a solution.
If they come up with something, tell us here.