Question about S32K14x EEPROM data recovery

[justinsheng]

In AN11983 Using the S32K1xx EEPROM Functionality, the EEPROM data recovery mechanism is described as below:

Literally, the compromised record being replaced by the previous reliable record is done DURING THE NEXT EEE WRITE. This is quite ambiguous.

If the underlined condition is true, then what value will be returned if the EEPROM cell containing incomplete record (compromised one) is read before any explicit write is done? Will it return recovered value, or unpredictable value?

And does the statement apply to both normal write AND quick write, or only normal write? The quick write chapter in AN11983 describes a different data recovery mechanism which uses "Continue interrupted quick write" Flash command.

[harryvaltet23]

To be honest, I still don't fully understand how this whole system works. Can you throw off a guide or tutorial to make it clearer?

[nelson_scheja]

Hello,

Just to be sure: In AN11983 Revision 2 from May 2019, it still says that something happens during the first write. Also, chapter 8.3 mentions this:

which seems to be related.

So this is all still incorrect documentation, and there is really no write operation needed to get back to a consistent state, correct?

[danielmartynek]

Hello Nelson,

Let me check why it hasn't been updated.

I will update the thread once I have more information.

Thank you for pointing this out.

The attached test project triggers a SW reset during an EEPPROM update. As expected, out-of-reset after a brownout (with BO status 0x4), the EEPROM is loaded with either the previous valid value or the new value, depending on how far into the write the SW reset occurred.

Regards,

Daniel

[danielmartynek]

Hi,

The AN will be corrected. No additional write is needed.

The compromised data are replaced with the previously written valid data during the reset sequence if the device is partitioned to load FlexRAM with valid EEPROM data during the reset sequence (AN11983 Section 3.1.1).

Otherwise, SetFlexRAM command must be executed as it is described in Figure 10 in the AN.

Write Status Query command returns Brown-out code (Section 3.2.1.4, AN).

Yes, the recovery process depends on the write mode.

Normal Write mode performs maintenance/cleanup for each written record. So, if a reset/brownout occurs during a Normal Write activity, the record will be mark as invalid and no update will take place.

Whereas Quick write mode writes records as fast as possible, postponing maintenance until later.
If Quick Write operation is interrupted before the last byte is written, none of the writes are valid and no update will take place. But if the Quick Write operation is interrupted during the maintenance (all writes are complete), brownout code will be set to 0x01 and the maintenance can be completed later (by using the FlexRAM command to complete the interrupted quick write process).

Regards,
Daniel