EEPROM corrupted data after power down

cancel
Showing results for 
Search instead for 
Did you mean: 

EEPROM corrupted data after power down

Jump to solution
341 Views
danielreinwald
Contributor II

Hello Community,

i'm trying to save some data to the EEPROM of the S32K146. Regarding to the documentation given (AN11983) and community posts, code is working and storing data into the intended address space (0x1400 0000).

After disconnecting the debugger, switch off the power supply and vice versa, stored data in the address space is corrupted. My understand of the app note is that the data remains correct after power switching. Now i'm searching for the problem data gets corrupted.

Maybe someone can help me out finding the solution? Below my test code.

danielreinwald_4-1636637131706.png

danielreinwald_1-1636637025668.pngdanielreinwald_2-1636637043035.png

danielreinwald_3-1636637068182.png

 

 

 

 

0 Kudos
1 Solution
273 Views
danielmartynek
NXP TechSupport
NXP TechSupport

Hi @danielreinwald,

Can you please implement the EEE initialization flow chart from AN11983, Figure 12.

https://www.nxp.com/docs/en/application-note/AN11983.pdf

It is important to make sure the FlexRAM data match the FlexNVM data.

Also, how do you connect the debugger exactly?

What debugger do you use and what is the configuration of it.

 

Thanks,

BR, Daniel

 

 

 

View solution in original post

0 Kudos
5 Replies
322 Views
danielmartynek
NXP TechSupport
NXP TechSupport

Hi @danielreinwald,

It seems like the application is writing the EEPROM in an endless loop.

Are you sure the power is lost when the FTFC controller is idle?

Can you please share the project so that I can test it?

 

Thank you,

BR, Daniel

0 Kudos
293 Views
danielreinwald
Contributor II

Hi @danielmartynek,

Thanks for replying and sorry for my delayed answer i was on vacation.

The FTFC Controller should be idle. I've added "i = 0" into the while loop to sure this condition.
So the endless loop now shouldn't rewrite the eeprom after i = 50.000.000, as you have mentioned it.

My test sequence is described below.

Step 1. Program S32K146 over S32DS and J-Link Debugger (Jtag)

Step 2. Start Software with S32DS and wait until "while (i <= 50.000.000)" is ready, so that data gets written to the eeprom (delay takes round about 16 seconds)

Step 3. Turn off the voltage power supply directly after Step 2. and disconnect Debugger

Step 4. Turn on the voltage power supply and connecting the Debugger ("while (i <= 50.000.000)" now prevents rewriting of the eeprom between turning on the voltage power supply and connecting the debugger)

Step 5. Check if data is correct or not (below pictures of the data space)

danielreinwald_0-1637564930252.png

Correct Data

danielreinwald_1-1637565842325.png

Corrupted Data

 

As a background information the same phenomenon also happens on my other application projects.

I shared the project. Thanks for your support.

0 Kudos
274 Views
danielmartynek
NXP TechSupport
NXP TechSupport

Hi @danielreinwald,

Can you please implement the EEE initialization flow chart from AN11983, Figure 12.

https://www.nxp.com/docs/en/application-note/AN11983.pdf

It is important to make sure the FlexRAM data match the FlexNVM data.

Also, how do you connect the debugger exactly?

What debugger do you use and what is the configuration of it.

 

Thanks,

BR, Daniel

 

 

 

0 Kudos
256 Views
danielreinwald
Contributor II

Hi @danielmartynek,

i rewrite my software by using the flow chart and NXP example project. There were errors in the initialization and the flexram write mode initialization was completely missing.

Now it works without data loss at power switching.

Only for understanding, the quick write status query is only useful if the power lost happens during a write access to the eeprom?

Thank you for helping me out with this issue.

BR, Daniel

0 Kudos
250 Views
danielmartynek
NXP TechSupport
NXP TechSupport

Hi @danielreinwald,

I'm glad it works now.

The quick write status query also reports the sector erase count.

danielmartynek_0-1637769287764.png

 

Regards,

Daniel

0 Kudos