TM4C123BE6PM: EESUPP.PRETRY bit = 1, and unable to clear it in free run.

Hi Hideaki-san,

Hideaki Nambu said:

Q1. Can I ask your advice about the failure cause ?

  It is hard to say. There are multiple erratum in the errata sheet, about the EEprom. It is possible that any one of them might have occurred during the EEPROM programming (e.g. reset or unstable power during the programming) It is also possible that the memory has exceeded its specified lifetime write/erase cycle. This type of problem is extremely hard to debug, especially via forum. 

Important: Failure to perform these initialization steps after a reset may lead to incorrect operation
or permanent data loss if the EEPROM is later written.

If the PRETRY or ERETRY bits are set in the EESUPP register, the EEPROM was unable
to recover its state. If power is stable when this occurs, this indicates a fatal error and
is likely an indication that the EEPROM memory has exceeded its specified lifetime
write/erase specification. If the supply voltage is unstable when this return code is
observed, retrying the operation once the voltage is stabilized may clear the error.

Hideaki Nambu said:

None of corruption found in the EEPROM read values.

I don't think you can be sure about that. See below errata description.

MEM#03 EEPROM Data May be Corrupted if an EEPROM Write is Interrupted
Revision(s) Affected: 6 only.
Description: Corrupted EEPROM data can occur if an EEPROM write is interrupted with any of the
following power events:
• Power failure
• External reset (RST)
• Brown-out (BOR) event
When the WORKING bit of the EEDONE register is set, an EEPROM program or erase
operation is occuring. The corrupted EEPROM data that can result from this sequence is
not limited to the current word being written. If these events do not apply to your system,
then normal EEPROM operation is expected. If a failure occurs, there will not be any
indication of the failed erase or corrupted data (for example in the PRETRY and the
ERETRY bits in the EEPROM Support Control and Status (EESUPP) register.

Hideaki Nambu said:

As a trial the same firmware was executed as CCS debug run.
It was tried over 20 times. In the case they found two results:

• (Found just one time N=1): The PRETRY bit read was ONE. The phenomenon was reproduced.
• (Other trials): The PRETRY bit read was zero. The phenomenon was not reproduced

This phenomenon was found first time. They have shipped over 200k good sets.

Does your CCS debug run involve soft resetting the device? See below.

Soft Reset Handling

The following soft resets should not be asserted during an EEPROM program or erase operation:
¡ Software reset (SYSRESREQ)
¡ Software peripheral reset
¡ Watchdog reset
¡ MOSC failure reset
The WORKING bit of the EEDONE register can be checked before the reset is asserted to see if an
EEPROM program or erase operation is occurring. Soft resets may occur when using a debugger
and should be avoided during an EEPROM operation.

Hideaki Nambu said:

• There would be more cases which EEPROMInit() doesn't work. I'm sorry but can I ask your advice ? --(*2)
• EEPROMInit() arrange was not good.
• VDD voltage drop (as explained in DS p.527).  I'm asking to observe VDD by an oscilloscope.
• EEPROM wore out (as explained in DS p.527)  -- Low possibilities. The device was returned very shortly after ship.

What was changed in the EEPROMInit()? Again, this will be very hard to debug via forum and I don't know where to start especially when you only have failure out of 200k.  All I can provide and you are already aware is to avoid all the erratrum described in the errata document. 

Hi,

  My colleague Bob also suggests the customer to check whether or not the timeout added to the EEPROMInit() is too short. The time to execute EEPROMInit() will vary widely. Eventually they will need to allow time for two sector erases.  The TivaWare code is proven. Please be mindful on what is changed that can lead to unpredictable or unstable behavior on the EEprom.