Corrupt EEPROM

[xfmrhelp]

My company has been using your PLCs pretty successfully for years now and have never encountered corrupted EEPROMs.  We're using the 2018 eeprom and the code is VERY large.  Again, we've done every trick in the book to reduce the size of the program.  As of right now, the EEPROM is at 8159 words.

Now recently we've been encountering this problem.  We've always been using the same power supply and same I/O.  The EEPROMs have not been damaged, we've only had to reload the programs.  But we can't allow this to happen with our customers.  Is there some link between the size of the EEPROM program and the frequency of program corruption?  Should we really be staying below some number other than 8191 to avoid this problem?

[support]

We have no previous report that code size nearing 8190 words limit would cause corruption of EEPROM. In the attempt to tighten the code there may be programming related issues that cause problem.  Is the same board behaving normally with a smaller code size program but encounter errors with a larger code downloaded to it?

Please contact support@tri-plc.com and give us more details about the problem you experience and the code you use. Are you experiencing any run-time error? We will try to help you determine whether this is a hardware or software related issue.

From a few reported incidents, the EEPROM corruption mainly occured in 12V battery-powered system with potential load dump problem when charging circuit switch in and out. Some users reported that they have installed voltage monitoring system and shut down power to the PLC when the DC voltage drop below 10V and that has protected the EEPROM from corruption or damage.

[ccdubs]

xfmrhelp,

Do you definitely have to reload the code? Or does a reboot (power off then on) solve the problem?

[xfmrhelp]

Actually, we have been burning in the same PLC for another three days after having to reload the program.  This morning we found the PLC energized, but the watchdog timer had tripped out.  We couldn't get it to respond to any command, even IR* using TLServer.

When we cycled the power it went right back to normal operation.  We've pulled that particular EEPROM and are downloading a program into a new one and commencing with burn in.

[support]

If the same problem occur again then please swap out the controller with a new one to test. If it doesn't happen to the new controller then it is not a software issue and therefore it could be a hardware problem. You can send the faulty PLC back to us for testing and repair if that is the case.

[benb2000]

I have had the opportunity to see the brochure on the "F" series PLC's that are coming.

I see that the EEPROM has been replaced by Flash memeory and the SDRAM have been replaced by a Ramtron FRAM. Is there any chance that the T100MD-888 series could be retrofitted to FRAM for the EEPROM?

[support]

There is no immediate plan to do so. The current CPU would not be able to take advantage of the speed of FRAM even if it were retrofitted.

[benb2000]

Speed is not the issue, reliability of data in the EEPROM is.

I would settle for a OTP 8 pin PROM, if it would solve my constant EEPROM corruption problems. I have 35 PLC's operating in the field with 12 VDC automotive power. I have installed the 1.5KE24A TVS diodes, and I still receive about 4 units a month, for reprogramming of the EEPROM.

[ccdubs]

BenB2000,

I have also had some issues where EEPROM was originally to blame and it was later found to be something else.

How do you know for certain that the problem is EEPROM? Do repaired units repeatedly fail? Do you replace the EEPROM or just reprogram?

[benb2000]

Hi,  ccdubs

I have done both, I attempt to re-programm first, then if this fails, I will replace the EEPROM. I will admit that mobile applications are one of the most hostile environments, and being in the oilfield, the field personnel do not show the TLC one would expect.

In my case it's almost always the EEPROM,  that when replaced or reprogrammed, will get the unit running again.

I am in the process of installing a DCDC converter to power the T100MD-888+ PLC's, but it will be some time before I see any results, and I do not know, if the EEPROM's "wear out" from the exposed "Load dump" conditions.

Do you have any recommendations?

[ccdubs]

It sounds like our problem is quite different to yours. I would suggest a DC to DC converter is a good first step as driving directly off the car 12V supply is almost always a no-no.

I would have thought it quite easy to get something specifically designed for automobile use.

[support]

One user who had a EEPROM corruption problem in mobile application suggested using a low voltage detection circuit which cuts power to the PLC when voltage falls below 10V and it has resolved the problem for him. You may want to give that a try?

[benb2000]

The design requirements for mobile use was underestimated, both electrically and physically.

Vibration is a big issue, with LM7810 regulators breaking off, connectors coming off, MXRTC/SDRAM's coming out of their socket.

We have moved to using tie wraps to hold the MXRTC stack, and Hot melt to stake the connectors, and to connect the regulators to the filter caps ( creating a larger mass)

Now we will progress with the DC/DC converters to see if we can minimize EEPROM failure

[support]

Did you mount the PCB on a shock-absorbing standoff - might help quite a lot in terms of vibration damage to the components.

[ccdubs]

It sounds like your vibration issue may be low frequency/high impact if you are breaking components off. This would be quite hard to mitigate.

Supports post regarding the undervoltage cutout circuit is a good one also. I have had to implement this when running from battery backed up supplies which can cause constant rebooting of the PLC as the battery dies. After a while the PLC doesn't like this anymore. You could be seeing something similar every time the car is started.