S32K144 issue in EEPROM data storage

[Shubha_Ravi]

Hello Team,

According to my project requirement i have partitioned the memory into 4KB EEPROM, recently i was working on creating a fault memory and storing all faults to EEPROM and while doing so i observed two incorrect behavior that could be of importance in breaking the complete logic that the application works on

1. During run time i see that the faults occurred are stored in the EEPROM at the specific memory location allocated for it but, after a power cycle i expect that the location (FlexRAM configured as EEPROM--(14000064-140000A4 i.e, 64bytes of fault ID +CRC 1 byte) to retain the fault ID's that i saw during runtime but even before running the code i just found that all values in the EEPROM memory are FF.This behavior doesnt happen always but this does repeat quiet often.(According to my project, the partition code will execute only once if the board has not already partitioned).

2. I created 7 faults and found that updated in EEPROM during runtime, and also found 7 faults stored in EEPROM, so after power cycle even before running the code my expectation is to find only the 7 faults that was created in the previous cycle but i found 14 faults which were basically duplicated. please find the below attachment for better understanding . 

It would be great if you could share some document related to the EEPROM state machine and how the data stored in Flex RAM configured as EEPROM is synchronized with backup EEPROM memory.

Could you please help me with this issue as early as possible we are nearing the project delivery. Please let me know if you need further information

Thanks in advance

[lukaszadrapa]

Hi @Shubha_Ravi 

We provide this application note which describes the EEE in detail:
https://www.nxp.com/docs/en/application-note/AN11983.pdf

If you need to store some data before power down, see especially section "5 S32K1xx brownout detection" and "6 S32K1xx new quick write mode".

1. It takes some time to store the data from FlexRAM to FlexNVM. If this operation is terminated by reset or power-down, the data may not be stored to flash memory. In this case, you will read previous data after reset.
The time to store the data can be quite long if maintenance is currently running on background. Use mentioned quick write mode if you have limited time before power down.

2. The EEPROM does not duplicate records in FlexRAM as you described. This sounds rather like some software issue.

Regards,
Lukas

[Shubha_Ravi]

Hello Lukas, 

Thanks for the information. I will look into the quick write mode to see if it could help with the first issue i had but although it says it would not take more that 1.5ms for EEE to be erased and written. And also it seems that Pre-erasure can result in the values FF, can i know when exactly does this pre erasure event happen?

And regarding your reply to my second issue that says it could be a software problem, this was my first thought as well so i checked the code to see if im writing the same ID again but its not the case and moreover i would agree that this could be software issue if the behavior occurs when the code is executed ,but no it happens when i just flash the code and look into memory. If the issue exists with software the same behavior should occur during run time but i do not observe that as well. its working perfectly fine during runtime. This is why i have to get the issue into forum to see if there is a possibility for such issue.

[lukaszadrapa]

Pre-erase means that user writes 0xFF to required addresses in FlexRAM when needed. It's operation triggered explicitly by user, not by EEE.

"it happens when i just flash the code and look into memory" - The partition is not removed when you just program new code. That means EEE data are still retained and you will see data written in the past. Isn't this the problem? The EEE mechanism is robust enough, I'm pretty sure it won't duplicate records, create some dummy records or anything like that.