Original question:
TM4C123BE6PM: EESUPP.PRETRY bit = 1, and unable to clear it in free run.
Hello,
Could you give us your advice about the failure cause, which is described on the related question's thread?
After replacing the device on EK-TM4C123GXL to the failure device, we executed the attached testing project.
As a result of 100 times iteration, LED lits 100%; therefore, EESUPP.PRETRY is never initialized (not becoming 0).
(We used CCS v10.0 and Tivaware v2.1.4.)
We need your advice for the problem.
Best Regards,
Nomo
Hi Nomo-san,
Nomo said:1.In the previous post, you mentioned "It is possible that any one of them might have occurred during the EEPROM programming (e.g. reset or unstable power during the programming)" as a possible cause.
In case of the possible cause, will the device be in an unrecoverable state keeping the EESUPP.PRETRY bit = 1?2.If the answer of 1 is yes, is there any method to recover from the abnormal state?
As much as I wanted to answer your questions, I just don't have all the answers you want. My answer to your question is yes, the device may be in an unrecoverable state when one of the events happen during the EEprom program/erase. Let's example the errata description again. Let me break it up into three sections.
(1) Do not use the START bit for error recovery. (2) If either the PRETRY or ERETRY bits are
set, the EEPROM was unable to recover its state. If power is stable when either of these
bits are set, this indicates a fatal error and is likely an indication that the EEPROM
memory has exceeded its specified lifetime write or erase specification. (3) If power is
unstable when either of these bits are set retry the operation once the voltage is
stabilized to clear the error.
(1) Did your customer ever remember if he attempted to use the START bit even once? If the START bit is never used, then we can take this out of the picture. The chip failure may have happened a long time ago. Sometimes the customer may not remember everything they did.
(2) Did your customer ever remember if the power was stable when he was doing the EEprom program/erase? This is again hard to remember what was happening at the time of the failure. There is no "Blackbox" recording of all the electrical parameters at the time of the failure. Based on your description, it seems the power was somewhat stable. If the power was not stable, you should be able to retry the operation based on (3). But you have tried to recover the device by power cycle again with no success.
So the question is - can the EEprom be unrecoverable without exceeding its specified lifetime write specification? My answer is yes. According to the datasheet, the minimum number of write cycles is 500,000. I doubt you have reached the limit but it is nonetheless still unrecoverable. Can you confirm how many write cycles you may have performed? Suppose you are within the limit then there is a strong indication that the EEprom can be unrecoverable without reaching the limit.
Nomo said:3.Is there any way to know whether the memory has exceeded its specified lifetime write/erase cycle?
Not that I'm aware of. This is why I asked if your customer remembered how many write cycles have been performed. It is his application, he has a better ideas how often he is writing to the EEprom per minute, per hour, or per day and how long the part has been on the field. From the hardware point of view, there is no register to tell how many cycles have been written.
I want to give you a heads-up. i will be on vacation for the rest of the week as we have a US holiday coming.
