Hello all,
I am working to confirm that our firmware responds appropriately if it were to receive a failure code from the TI driver’s EEPROMInit function, and I have a question remaining in my mind still after reading the Data Sheet and Errata information that I’ve seen at https://www.ti.com/product/TM4C1290NCPDT#tech-docs We are using Rev 3.
In the "Error During Programming" section within 8.2.4.1 of the Data Sheet, this information is presented:
After a reset and prior to writing any data to the EEPROM, software must read the EESUPP register and check for the presence of any error condition which may indicate that a write or erase was in progress when the system was reset due to a voltage drop. If either the PRETRY or ERETRY bits are set, the peripheral should be reset by setting and then clearing the R0 bit in the EEPROM Software Reset (SREEPROM) register and waiting for the WORKING bit in the EEDONE register to clear before again checking the EESUPP register for error indicators. This procedure should allow the EEPROM to recover from the write or erase error. In very isolated cases, the EESUPP register may continue to register an error after this operation, in which case the reset should be repeated. After recovery, the application should rewrite the data which was being programmed when the initial failure occurred.
Now, for comparison, I will quote a portion of 8.2.4.2
Before writing to any EEPROM registers, the clock to the EEPROM module must be enabled through the EEPROM Run Mode Clock Gating Control (RCGCEEPROM) register (see page 388) and the following initialization steps must be executed:
1. Insert delay (6 cycles plus function call overhead).
2. Poll the WORKING bit in the EEPROM Done Status (EEDONE) register until it is clear, indicating that the EEPROM has completed its power-on initialization. When WORKING=0, continue.
3. Read the PRETRY and ERETRY bits in the EEPROM Support Control and Status (EESUPP) register. If either of the bits are set, return an error, else continue.
4. Reset the EEPROM module using the EEPROM Software Reset (SREEPROM) register at offset 0x558 in the System Control register space.
5. Insert delay (6 cycles plus function call overhead).
6. Poll the WORKING bit in the EEPROM Done Status (EEDONE) register to determine when it is clear. When WORKING=0, continue.
7. Read the PRETRY and ERETRY bits in the EESUPP register. If either of the bits are set, return an error, else the EEPROM initialization is complete and software may use the peripheral as normal.
When I read the two sections that I have highlighted, there appears to be a mismatch. In the first section that I quoted, the gist seems to be that it’s appropriate to perform a soft reset of the EEPROM if there is an error encountered in PRETRY or ERETRY. But in the list of numbered steps, there is a reset performed if there is not an error encountered in PRETRY or ERETRY.
The reason why this is important to me is that I want to know what’s appropriate for our application to do if EEPROM_INIT_ERROR is returned from EEPROMInit. If that error code has been returned at Step 3, then the first section that I quoted indicates that we should perform a soft reset and then try again. (Per MEM#11 of the Errata for this device, we are using the TI driver implementation of EEPROMInit, rather than the ROM implementation. I looked at the current driver code, and it seems to match the sequence of steps listed in section 8.2.4.2. From the EEPROMInit driver source code, it looks like if we do not do that ourselves in our application, then the next call to EEPROMInit may well just early-exit at Step 3 again.)
But on the other hand, given that MEM#11 exists, I wonder whether the "Error During Programming" passage of the Data Sheet (which obviously pre-dates MEM#11) is still regarded as correct?
Please could you give me some advice on this? Should we take steps to perform that soft reset before making our next attempt to call EEPROMInit? Part of me is wondering why, if this is still the recommended practice, the EEPROMInit driver itself does not take this action on the caller's behalf if this situation is encountered?
