Abnormal power down causing the Dflash area ???????(S32K342 MCAL)

[WangBk]

Hello Support:

When we were testing, there was a very small chance that it would occasionally cause abnormal Dflash data：

We suspect that it was caused by the chip powering off while operating the Dflash

When powered on again，FLS will read Dflash data, it will trigger hardfault.

And the error cannot be corrected.

Is there any way to resolve this error?

S32K342

FEE:Fee_TS_T40D34M20I0R0

FLS:Fls_TS_T40D34M20I0R0

BR

WangBk

[danielmartynek]

Hi @WangBk,

It can be resolved by reprogramming the DFlash, which requires erasing the whole sector.

The read instruction that cause the hardfault can be skipped:

https://community.nxp.com/t5/S32K-Knowledge-Base/Example-C40-Ip-ECC-Fault-Skip-S32K312-DS34-RTD2211-...

The power supply can be monitored so that any flash operation can ba launched when the power supply is stable.

Regards,

Daniel

[Oskar_Waldemarsson]

Hi @danielmartynek,

I also has some issues with ECC faults in DFlash area leading to hard fault when reading. I tested your example and it seems to work. But, some additional questions thet perhaps you could answer:

1. Is there no other way of dealing with ECC faults other than trying to handle and escape the hard fault manually? I.e. is there no setting that can make the read instruction continue without triggering an exception?

2.  In your example HardFault_Handler code you assume that the fault instruction address (stored PC) is always 8 positions from the top of the stack. Why is this so? I noticed that depending on how you configure the compiler (GCC) optimization the function prologue sometimes push 2 registers and sometimes 4 registers to the stack, making the 8 position offset somewhat unreliable. How can this be mitigated in a reliable way?

Regards, 

Oskar

[danielmartynek]

Hi @Oskar_Waldemarsson,

1.

2.

Yes, it depends on local variables, for example.

Regards,

Daniel

[Oskar_Waldemarsson]

Thanks for the quick reply! The DERR_SUP bit seems to be what I was looking for. 

Regarding the population of the stack. Do you have any information on how the stack gets populated during an exception and why the fault instruction address should be expected to be at position 8?

[danielmartynek]

Refer to the ARM documentation:

https://developer.arm.com/documentation/dui0646/c/The-Cortex-M7-Processor/Exception-model/Exception-...

Then it depends on the compiler.

Regards,

Dnaiel

[erik_gulliksson]

Hi @danielmartynek 

Continuing here as the topic is the same regarding corrupt Dflash Area and ECC errors. I'm using a newer version of the RTD compared to the example above, specifically "SW32K3_S32M27x_RTD_R21-11_5.0.0_D2410". Is ECC errors handle by the MemAcc driver itself now and corrected/discarded or will it still trigger an Hard Fault exception that needs to be handled?

If a Hard Fault exception is triggered, do you have an updated example of how to handle the same scenario for a newer RTD version? As C40_Ip_DsiHandler() doesn't exist any longer.

Regards,
Erik

[danielmartynek]

Hi @erik_gulliksson,

Can you please create a new thread?

Thank you,

Daniel

[erik_gulliksson]

Created a new thread here:
S32K3 Hard fault exception on startup for ECC error in DFlash/FEE memory 

Regards,

Erik

[WangBk]

Hi Daniel：

    The Demo code can skip the hardfault, Is there any way to fix abnormal areas?

BR

Wangbk

[danielmartynek]

Hi @WangBk,

According to AN13388 S32K3 Memories Guide, the data flash can be over-programmed only when used with NXP approved FEE driver.

Otherwise, the flash sector must be erased first.

Regards,

Daniel

[WangBk]

Hi Daniel：
We also want to know what is the reason for this problem? What are the situations? Can you give some examples?
BR
Wangbk

[danielmartynek]

Hi @WangBk,

The flash controller programs the data + its ECC checksum into the flash.

If the programming is interrupted by power loss, the operation is incomplete, the data and its ECC checksum might not match.

The power supply can be monitored, so that any flash operation can be launched only under stable power supply.

Regards,

Daniel

[WangBk]

Hi Daniel

I have another question:
I plan to create an ECC fault in the 0x10014000 area. Some data is written in the 0x10014000 area through the FEE module.

Case 1: The following function call cannot cause ECC failure:

	/* Unlock sector if needed */
	if (STATUS_C40_IP_SECTOR_PROTECTED == C40_Ip_GetLock(FLS_SECTOR_TEST))
	{
		C40_Ip_ClearLock(FLS_SECTOR_TEST, FLS_MASTER_ID);
	}

	/* Erase sector */
	C40_Ip_MainInterfaceSectorErase(FLS_SECTOR_TEST, FLS_MASTER_ID);
	do
	{
		C40Status = C40_Ip_MainInterfaceSectorEraseStatus();
	}
	while (STATUS_C40_IP_BUSY == C40Status);

	C40_Ip_MainInterfaceWrite(FLS_SECTOR_ADDR, FLS_BUF_SIZE, writeBuffer_1, FLS_MASTER_ID);
	while (STATUS_C40_IP_BUSY == C40_Ip_MainInterfaceWriteStatus());

	/* Write 2 */
	C40_Ip_MainInterfaceWrite(FLS_SECTOR_ADDR, FLS_BUF_SIZE, writeBuffer_2, FLS_MASTER_ID);
	while (STATUS_C40_IP_BUSY == C40_Ip_MainInterfaceWriteStatus());

	/* Read */
	read_status = C40_Ip_Read(FLS_SECTOR_ADDR, FLS_BUF_SIZE, readBuffer);

Case2: The following function call can cause ECC failure

	/* Unlock sector if needed */
	if (STATUS_C40_IP_SECTOR_PROTECTED == C40_Ip_GetLock(FLS_SECTOR_TEST))
	{
		C40_Ip_ClearLock(FLS_SECTOR_TEST, FLS_MASTER_ID);
	}

	/* Erase sector */
	C40_Ip_MainInterfaceSectorErase(FLS_SECTOR_TEST, FLS_MASTER_ID);
	do
	{
		C40Status = C40_Ip_MainInterfaceSectorEraseStatus();
	}
	while (STATUS_C40_IP_BUSY == C40Status);

	/* Unlock sector if needed */
	if (STATUS_C40_IP_SECTOR_PROTECTED == C40_Ip_GetLock(FLS_SECTOR_TEST))
	{
		C40_Ip_ClearLock(FLS_SECTOR_TEST, FLS_MASTER_ID);
	}

	/* Erase sector */
	C40_Ip_MainInterfaceSectorErase(FLS_SECTOR_TEST, FLS_MASTER_ID);
	do
	{
		C40Status = C40_Ip_MainInterfaceSectorEraseStatus();
	}
	while (STATUS_C40_IP_BUSY == C40Status);

	C40_Ip_MainInterfaceWrite(FLS_SECTOR_ADDR, FLS_BUF_SIZE, writeBuffer_1, FLS_MASTER_ID);
	while (STATUS_C40_IP_BUSY == C40_Ip_MainInterfaceWriteStatus());

	/* Write 2 */
	C40_Ip_MainInterfaceWrite(FLS_SECTOR_ADDR, FLS_BUF_SIZE, writeBuffer_2, FLS_MASTER_ID);
	while (STATUS_C40_IP_BUSY == C40_Ip_MainInterfaceWriteStatus());

	/* Read */
	read_status = C40_Ip_Read(FLS_SECTOR_ADDR, FLS_BUF_SIZE, readBuffer);

Case 2 performs an erasure operation before case 1.

/* Unlock sector if needed */
	if (STATUS_C40_IP_SECTOR_PROTECTED == C40_Ip_GetLock(FLS_SECTOR_TEST))
	{
		C40_Ip_ClearLock(FLS_SECTOR_TEST, FLS_MASTER_ID);
	}

	/* Erase sector */
	C40_Ip_MainInterfaceSectorErase(FLS_SECTOR_TEST, FLS_MASTER_ID);
	do
	{
		C40Status = C40_Ip_MainInterfaceSectorEraseStatus();
	}
	while (STATUS_C40_IP_BUSY == C40Status);

Why is it not easy to reproduce ECC failures when Fee data exists?

[danielmartynek]

Hello @WangBk,

Can you read the return status of each function call?

BR, Daniel

[WangBk]

The return values are all correct, otherwise the program will be stuck in while(). My question is that the dflash is in the erasing state, which seems to make it easier to reproduce ECC faults.

[danielmartynek]

You don't even read the return status of some function e.g. C40_Ip_MainInterfaceWrite()

And it would be stuck in the while loop if the status remained BUSY.

Regards,

Daniel

[WangBk]

Hi Daniel
sorry, It is the function parameters in my test code that are inconsistent, which leads to inconsistent test results. There is no problem with the Demo code.

[WangBk]

Hi Daniel
Thanks.
BR
Wangbk