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
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:
The power supply can be monitored so that any flash operation can ba launched when the power supply is stable.
Regards,
Daniel
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
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?
Refer to the ARM documentation:
Then it depends on the compiler.
Regards,
Dnaiel
Hi Daniel:
The Demo code can skip the hardfault, Is there any way to fix abnormal areas?
BR
Wangbk
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
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
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?
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.
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