2198028_en-US

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

2198028_en-US

2198028_en-US

After resetting, the s32k312 enters the HardFault_Handler abnormally

The chip used is s32k312, with the compiler version being S32DS3.5 and RTD3.0. During the production of uds-boot, some valid information is fixed in pflash at address 0x0043E000.

sensen_1_0-1762236756459.png

sensen_1_1-1762236817623.png


sensen_1_2-1762236843789.png


sensen_1_3-1762236858994.png

Program the bootloader into the chip, and then flash the app program via the host computer. After the first flash, you can use the internal watchdog timeout reset to ensure the program correctly enters the app. However, when the program is running in the app and another app flash operation is performed, the program enters the HardFault_Handler after resetting. Please help me check if there is a configuration issue, or if there is a standard configuration method. As long as the information is not fixed in p_flash, but instead written to 0x0043E000 through instructions later, the program can run normally.

Thank you very much for your support.


Re: After resetting, the s32k312 enters the HardFault_Handler abnormally

Do you use RTD drivers? 

The INFLS MCAL driver includes a feature that allows relocating code to SRAM:

danielmartynek_0-1762249915732.png

If you use the C40_Ip driver, refer to this example:

https://community.nxp.com/t5/S32K-Knowledge-Base/S32K312-C40-Ip-SRAM-RTD-500-DS35/ta-p/2074245


Regards,

Daniel


Re: After resetting, the s32k312 enters the HardFault_Handler abnormally

These codes are indeed stored in the same block0 area, specifically the block0 area of the s32k312, with effective addresses ranging from 0x00400000 to 0x00500000. However, if they are not fixed and instead written through p_flash programming operations in the program later on, the HardFault_Handler will not appear. It's similar to the following.

sensen_1_0-1762248268141.png


Re: After resetting, the s32k312 enters the HardFault_Handler abnormally

Hi @sensen_1,

This is probably due to an RWW (Read-While-Write) collision on the flash block.
The executed code must not reside in the flash block that is currently being programmed.
Can you confirm if this is the issue?


Regards,

Daniel

Tags (1)
No ratings
Version history
Last update:
‎11-21-2025 05:03 AM
Updated by: