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

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 

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

601 次查看
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 项奖励
回复
3 回复数

553 次查看
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 项奖励
回复

502 次查看
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 项奖励
回复

473 次查看
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 项奖励
回复