S32k144 Firmware upgrade - NVM read issue

[stark21]

We are currently working on the firmware upgrade process for the S32K144 microcontroller, which involves a bootloader and two separate applications: App1 and App2.

In the memory layout:

• App1 is mapped to start at 0x11000

• App2 starts at 0x42000
  (as defined in their respective linker files).

We have successfully created combined HEX files that include both applications. Each application can be downloaded correctly, and the bootloader is responsible for jumping to the appropriate application address (0x11000 for App1, 0x42000 for App2).

In application, we write certain parameters to NVM (non-volatile memory). For upgrade process when the system switches back to the bootloader, it reads back those parameters successfully.

However, we’ve encountered an issue:
When GPIO PTD15 is configured as an output in the bootloader, when system switch, the bootloader fails to read the NVM data correctly. If PTD15 is not configured, the data is read back as expected.

We are looking for insights into the potential cause of this issue.

[danielmartynek]

Hi @stark21,

First of all, the NVM either contains the data at the expected location or it doesn’t — this should be verified immediately after programming.

• Can you confirm that the API used to write the data returns a success status (no errors)?
• Are you able to read back the data correctly from within the application after programming, before switching to the bootloader?

Also, could you clarify what you mean by “the bootloader fails to read the data correctly”?

• Are the values incorrect or unexpected?
• Are they in an erased state (e.g., all bytes reading as 0xFF)?
• Is the data corrupted (ECC)?

Additionally, are you using DFlash or the hardware-emulated EEPROM for storing these parameters?

Finally, what exactly does PTD15 control when configured as an output?

Regards,

Daniel

[stark21]

Hello Daniel,
Please find below inline comments.

• Can you confirm that the API used to write the data returns a success status (no errors)?
  Yes, returns success.
• Are you able to read back the data correctly from within the application after programming, before switching to the bootloader?
  Yes.

Also, could you clarify what you mean by “the bootloader fails to read the data correctly”?

• Are the values incorrect or unexpected?
  Incorrect.
• Are they in an erased state (e.g., all bytes reading as 0xFF)
  Yes, all the data is 0xFF
• Is the data corrupted (ECC)?
  Not sure

[danielmartynek]

Hello @stark21,

Can you also answer these questions:

• Are you using DFlash or the hardware-emulated EEPROM for storing these parameters? 
• What exactly does PTD15 control when configured as an output?

Thank you

[stark21]

We are using EEPROM and PTD15 is configured as GPIO and set to high.

[danielmartynek]

Hi @stark21,

When reading data from the emulated EEPROM, the data is accessed from the FlexRAM.

Do not reset the MCU until the EEPROM state machine has fully completed the backup operation to FlexNVM. Interrupting this process may result in data loss or corruption.

For detailed guidance, refer to the application note:

AN11983 Using the S32K1xx EEPROM Functionality

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

Follow Figure 12. EEE initialization flow chart in your code.

To detect a potential brownout condition, use the Quick Write Status Query FTFC command. This helps verify whether the EEPROM write process was interrupted.

Regards,

Daniel

[stark21]

But the data loss or corruption happens only when we configure the GPIO PTD15.

[danielmartynek]

Hello @stark21,

This doesn't quite make sense.

Regardless of the port configuration, the data is either programmed into the EEE backup flash or it isn't. The FTFC Set FlexRAM Function command with the EEPROM quick write status query parameter can help determine whether the programming process was interrupted.

You mentioned that the data reads as all 0xFF.
This typically indicates one of two possibilities:

• The data was never programmed into the EEE backup flash.
• The data has become corrupted:

Regards,

Daniel