MPC5744P - Emulated eeprom driver - Blankspace pointer not initialized properly

[nlarose]

We are using S32 Design Studio for Power Architecture v2.1.7 with S32 SDK For Power Architecture Version 3.0.0 RTM version 2.1.0

We are using Emulated EEprom driver to perform non volatile data storage on MPC5744P.

We configured 2 blocks of 16KB (located at addresses 0x00800000 and 0x00804000).

The data that is saved is 16 bytes long, which make the record saved to the flash 32 bytes long.

The EEPROM is used to share info between bootloader and application.

Write to EEPROM is performed whenever a warm reboot request is made.

After some event on our device after which a soft reboot was performed, the device was hung up, unresponsive.

After performing some investigations, we found out that it hung up because a write access to EEPROM was performed after bootup and the write access caused an hardware exception by accessing a Null pointer. The pointer was the blankSpace pointer of the block configuration structure, which contains the pointer where to write the data record in flash. 

We found out that when block 0 is completely erased (where not even erase counter is saved at the beginning of the block) and the block 1 is completely full, blankSpace is set to 0 after calling EEE_DRV_InitEeprom().

I attached a binary file in which were saved the flash content (from address 0x00800000 to 0x00808000) where the 2 emulated EEPROM blocks are located.

We determined that an issue occurred when block0 was full and got erased. For some reason, the erase counter never got saved.

We verified that eeprom initialization was not having the same behavior (uninitialized blankSpace pointer) under the following conditions:

• block 0 full and block 1 completely erased
• block 0 and 1 completely erased
• block 0 active (not full) and block 1 completely erased
• block 0 completely erased and block 1 active (not full)

Are you aware of this issue ? Is there any mitigation strategy we could use to prevent this to happen?

[lukaszadrapa]

Hi,
which return code did you get when calling EEE_DRV_InitEeprom()?
And what do you mean by "warm reboot" and "soft reboot"? Is that software reset? Or are you jumping between the bootloader and application directly without reset?
Regards,
Lukas

[nlarose]

Hi, 

EEE_DRV_InitEeprom() was returning STATUS_SUCCESS.

By warm reboot, I meant software reset.

There is always a reset involved (power on or soft reset).

Below is an illustration of two typical use of our bootloader.

Case 1:

Case 1

Case 2:

Case 2

Regards,

Nicolas

[lukaszadrapa]

Hi Nicolas,

sorry for delayed response, I was out of office a couple of days.

I was playing with my project, trying to delete the blocks at different situations but InitEeprom was always able to do the recovery and blankSpace was initialized accordingly.

I could see described behavior only when I loaded your binary to the blocks. However, I expect I do not have exactly the same configuration as you have. Could you send me a screenshot of your configuration of eee? Is it exactly the same in the app and bootloader?

Regards,

Lukas

[nlarose]

Hi Lukas,

Thanks for your reply.

Your findings are very interesting.

For your information, the eeprom code is the same in the application and the bootloader.

I supposed by screenshot you meant the processor expert configuration of emulated eeprom.

I attached the screenshot, the generated c and h files that were generated by processor expert.

Let me know if you need more information.

Regards,

Nicolas

[lukaszadrapa]

Ok, I'm able to reproduce it on my side too. I will discuss this with driver owner. I'm afraid it will take some time. I will let you know.

Regards,

Lukas

[nlarose]

Hi,

I'm glad you could reproduce the issue.

I am eager to hear the conclusion of the driver owner.

Thanks,

Nicolas