S32K3 Hard fault exception on startup for ECC error in DFlash/FEE memory

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

S32K3 Hard fault exception on startup for ECC error in DFlash/FEE memory

618 Views
erik_gulliksson
Contributor II

Hi,

Migrating from PlatformSDK_S32K3_2022_03 and S32DesginStudio 3.4 toS32K3 Real-Time Drivers AUTOSAR R21-11 Version 5.0.0 and S32DesignStudio 3.6. Previously we had problems with ECC errors triggering a Hard fault exception on startup if a memory write was abruptly aborted by a power failure for instance. Can be read about here:

Abnormal power down causing the Dflash area S32K342-MCAL 

and

S32K3 Fee data corrupt causing hardfault 

together with example of how to counter act the triggered exception which was to basically clear the error and move stack pointer. However, the example is for an older RTD and doesn't seem to be applicable any longer due to missing functions and defines in the C40_Ip module.

Is this now handled in the RTD itself to take care of ECC errors on startup and not triggering a hard fault exception as previously? If a hard fault exception is still triggered due to ECC errors how shall this be handled for newer RTD versions, is there an updated example?

Regards,

Erik

0 Kudos
Reply
3 Replies

570 Views
danielmartynek
NXP TechSupport
NXP TechSupport

Hi Erik,

It is not handled by the C40_Ip driver.

If there is any Core fault exception, it always goes to HardFault_Handler (or BusFault_Handler if enabled in this case), and it is down to the user to handle the recovery.

The API is indeed missing, you can to write your customer code to implement it.

 

Regards,

Daniel

 

 

0 Kudos
Reply

519 Views
erik_gulliksson
Contributor II

Hi Daniel

Thanks for reply. Okay then it needs to be handled in a similar way as older RTD versions then if a hard fault exception is triggered on ECC errors. However, the API's that existed in previous RTD's is that going to be re-implemented (or similar functionality) or is this totally up to the user to handle now? To me this sounds like is something that the abstraction layer shall provide so that the user/application doesn't need to handle these low level scenarios.

Regards,

Erik

0 Kudos
Reply

490 Views
danielmartynek
NXP TechSupport
NXP TechSupport

Hi @erik_gulliksson,

You mentioned the C40_Ip driver that is a low-level non-autosar driver.

There is the Mem driver in Autosar R21-11.

danielmartynek_0-1748934864232.png

RTD 4.0.0 and never have Mem_43_INFLS_PropagateError API.

 

Have a look at Chapter 10 ECC Management in RTD_MEM_43_INFLS_IM that is available in the RTD installation folder.

 

Best regards,

Daniel

 

0 Kudos
Reply