S32K D-Flash Memeory single sector is abnormal

[HuitingXu]

A hard fault reset occurs during the use of the chip. After investigation, it is found that some discontinuous addresses in one sector of the D-Flash address are abnormal. There is no specific value. To determine the cause of this phenomenon, what operation causes the discontinuous exception of a single sector in the D-Flash address segment.Please refer to the following example

example of abnomal D-Flash Memory dump:
10007080 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF DF D9 FF ?? ?? ?? ?? ?? ?? ?? ??
100070A0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
100070C0 ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? FF FF FF FF FF FF FF FF
100070E0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ?? ?? ?? ?? ?? ?? ?? ?? FF FF F5 7B FF FF FF FF
10007100 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
10007120 FF FF FF FE FE DF CF FF ?? ?? ?? ?? FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

[danielmartynek]

Hello @HuitingXu,

Can you specify the MCU part?

The debugger shows ?? on data where uncorrectable ECC error are reported.

When the DFlash is programmed, make sure the operation is not interrupted.

If you use SKD/RTD, read the return status of the APIs.

Regards,

Daniel

[charles_wangw]

Hello Daniel

While Huiting has no access to upload the the picture. I help to reply this picture.

We setting cluster0 and cluster1.

Cluster0  address from 10000000-10006FFF

Cluster1 address from 10007000-1000DFFF

Every time abnormal area is the head sector of cluster, such as 10007000-100077FF and 10000000-100007FF

The problem cannot be reproduced during normal operation, How can we reproduce the problem 

Thank you very much.

@danielmartynek 

BS

Charles

[danielmartynek]

Hi @charles_wangw,

I don't know what application does.

But to recover from this, the sectors must be erased.

Once it is erased, you should see all 1s in the sectors.

Check the sectors after each programming to confirm the data has been written correctly.

Also, always read the return return status of the APIs.

BR, Daniel

[charles_wangw]

Hello Daniel

@danielmartynek  Also I am curious about DFLash will comes to 0xFF(for byte) when we clear with the interface. When  it can reach "????" from your information. It will help us a lot.

Thanks

Charles

[danielmartynek]

All the information provided by you is rather confusing.

For example, you wrote:

"The problem cannot be reproduced during normal operation, How can we reproduce the proble"

If you mean the ???? data, this is an ECC error, it can be reproduce by interrupting a flash operation by a system reset.

Can you mass erase the MCU, so that the DFLash is blank (all 0xFF)?

"This block will be written before sleep and power down. Is it related to the abnormal address?"

Then update DFlash through FEE, and make sure the operation is not interrupted (monitor the reset_b pin and power supply), and don't put the MCU into any stop mode before the operations are finished.

Always check the status of the FEE driver after every operation, read return status of the APIs.

It would help if you could create a new simple test project that can reproduce the issue and share the project either here or via a support ticket so that we can test it.

Regards,

Daniel

[charles_wangw]

Hello Daniel

We Use IC5000 to debug.

iC5000 - iSYSTEM

What you see in the picture "????" is we read directly from the failed sample. It looks like these area is erased by debug. 

When we try to repeat this issue. All the area will also comes to "?????" when do the process "Erase Mass all" with IC5000.

We have no idea why the sample can get the status above. In the application software, all the process to update Dflash is through the Fee interface below(We use EB AutoSar and with NXP MCAL). 

And we try to ask for help in which condition can reach the issue scenario. Then we can try to repeat with application code again.

Thank you again.

Charles

[danielmartynek]

Can you share the configuration of the FEE driver?

And what version of the RTD drivers do you use?

Thanks,

Daniel

[charles_wangw]

Hello Daniel

Thank you for your support.

Please uncompress from the attachment for fee config.

We use S32K14X_MCAL4_2_RTM_HF2_1_0_2 from NXP.

@danielmartynek 

@HuitingXu 

BR

Charles  

[danielmartynek]

Can you share the screenshots of the configuration?

Or the whole project, not just .xdm?

Thank you,

BR, Daniel

[charles_wangw]

Hello Daniel

Please help to check the config below.

Thanks.

BR

Charles

[danielmartynek]

Can you share screenshots of all the configuration tabs?

Also, you did not specify the MCU part number.

BR, Daniel

[HuitingXu]

Above are our FEE configration of APP(Which has problem cluster header one)

Our MCU part number is S32K144HBT0MLHR.

[danielmartynek]

Hello @HuitingXu,

Thank you ro all the information.

What you see in the picture "????" is we read directly from the failed sample. It looks like these area is erased by debug. When we try to repeat this issue. All the area will also comes to "?????" when do the process "Erase Mass all" with IC5000.

That is interrecting, because Mass erase from the debugger should not caused any ECC issues, unless the operation is interrupted.

Can you confirm there are indeed ECC errors?

Can you read the DFlash ???? loacations by the core?

You should see a fault exception and FERSTAT[DFDIF] = 1.

You need to implement correct exception handling (AUTOSAR_MCAL_FLS_IM.pdf, Section 4.4 Implementing an Exception Handler in case of noncorrectable ECC error.

If the ECC errors are confirm there, make sure the FEE operations are not interrupted, please scope the reset_b pin along with the power supply.

Best regards,

Daniel

[HuitingXu]

This error is not caused by the debugger erase, is integrated into the ECU normal operation,

And go to the hard fault error.

from the dumped D-Flash address segment information,

A block set to write immediately was repeatedly written 181 times,

but failed to write, only the block header information was written, the actual block content was not written. This block will be written before sleep and power down. Is it related to the abnormal address?

Below is 181 times unfinished writes

Below is dumped D-flash image

Below is ???? abnormal area