HardFault during startup on S32K324 M7 core

[Changyuke]

Description: I am experiencing a HardFault during the startup phase of an S32K324 Cortex-M7 core. After configuring drivers based on the FEE demo, the program halts in _INIT_DATA_BSS() inside startup_cm7.s.

Details:

• MCU: S32K324, dual Cortex-M7

• Dev Environment: S32DS + Segger J-Link

• Call stack shows:

HardFault_Handler() at exceptions.c:97
memset() at 0x40a66c
init_data_bss() at startup.c:144
_INIT_DATA_BSS() at startup_cm7.s:565

• Linker sections:

.sram_bss (NOLOAD) : { *(.bss) *(.bss*) *(.mcal_bss) } > int_sram_c0
.bss_tcm_data (NOLOAD) : { *(.dtcm_bss*) } > int_dtcm

• The HardFault occurs during memset() of .bss_tcm_data.

It appears the startup initialization

#S32K324

[Changyuke]

Hi Daniel,
I updated the MEMACC settings and adjusted the period in the FEE main function, and now everything is running fine. Thanks for the help!

[danielmartynek]

Hi @Changyuke,

What kind of fault exception is it?

Can you read Configurable Fault Status Register (CFSR)?

https://developer.arm.com/documentation/ddi0403/d/System-Level-Architecture/System-Address-Map/Syste...

Have you modified the default linker file and startup code?

If so, please share the files.

Regards,

Daniel

[Changyuke]

Hi Daniel ,

Apologies, I initially thought the issue was resolved, but after further testing, the issue still persists under certain conditions.

We are testing the FEE functionality on an S32K324, referencing the S32K344 FEE demo. The system enters a HardFault during the startup phase, before reaching main(). The linker file and other configurations have not been modified.

Observed behavior:

• If we first flash the NXP S32K344 FEE demo, then flash our S32K324 project, the program starts successfully.

• If we flash the S32K324 project directly, the system always HardFaults on power-on.

Attempts and observations:

• Reducing the CPU frequency to 80 MHz does not resolve the issue.

• Commenting out FEE/Flash initialization (i.e., MemAcc_Init and Fee_Init) still results in HardFault.

• The flash order of Core0 and Core1 does not affect the phenomenon.

• Short power-cycles behave consistently, but after long-term power-off (several days), the system again HardFaults on power-on.

We suspect the issue may be related to startup memory, MPU/cache/TCM configuration, or Flash readiness at power-on.

Has anyone encountered similar behavior on S32K3xx devices, and what would be the recommended troubleshooting steps?

Thanks in advance for any guidance!

Regards,
Changyuke

[danielmartynek]

Hi @Changyuke,

Is this still PRECISERR with BFAR invalid?

Anyway, you should see the fault instruction on the stack, unless the fault occurs during stacking. https://community.nxp.com/t5/S32K-Knowledge-Base/Fault-handling-on-S32K14x/ta-p/1114447

After POR, catch it at the beginning of the startup code and then attach the debugger and step the code:

Start:
mov r0, #1
cmp r0, 0 /* change r0 to 0 in register view */
bne Start /* Capture after power-on reset */

MPU can be disabled in system.c. If the MPU regions are not aligned to the size of the regions, it can cause unpredictable behavior.

Use strictly one of the clock options listed in the RM, e.g. Table 158. Option B - Reduced Speed mode (CORE_CLK @ 120 MHz), other configurations can cause unpredictable behavior. 

Regards,

Daniel

[Changyuke]

Hi @danielmartynek 

During debugging on S32K324 with RTD, I observed that the application always enters HardFault at the following assignment:

Mem_43_INFLS_eJobRuntimeInfo[InstanceIndex].JobResult = JobResult;

Debugger observation:

• Variable Mem_43_INFLS_eJobRuntimeInfo is located at 0x20440000 (size: 40 bytes).

• Faulting instruction:

  str r0, [r3, #32]

• Exception registers:

  • CFSR = 0x00000400 (IMPRECISERR = 1)

  • HFSR = 0x40000000 (FORCED = 1)

  • BFARVALID = 0

  • BFAR = 0x00000000

This phenomenon is reproducible every time the above line executes.

Could you please advise:

1. Which documentation or application notes should I refer to for correct placement and configuration of Mem_43_INFLS_eJobRuntimeInfo?

2. Are there recommended debug methods to verify whether the memory region (0x20440000) is valid and properly initialized for this variable?

Thanks,
Changyuke

[danielmartynek]

Hi @Changyuke,

I'm sorry for the delay, I was out of office for a few days.

ldr r3, [pc, #12]

str r0, [r3, #32]

This code first reads a 32-bit value from the memory address at PC + 12 and loads it into register R3. This value typically represents a pointer to a data structure or memory region.
Next, a direct store instruction writes the contents of R0 to the memory address calculated as R3 + 32, which in this case resolves to 0x20440020.
Since the fault is not caused by MPU or XRDC configuration, it is likely due to the SRAM at that location not being properly initialized. The initialization must be performed using 64-bit aligned writes, not 32-bit writes. Attempting a 32-bit write to such a region that is not initialized will trigger an imprecise bus fault.

At the beginning of main(), you could initialize the memory:

    volatile uint64* ptr = (uint64*)0x20440000;
    *ptr = 0ULL;  // Write 64-bit zero

In disassembly, you should see STRD instruction.

Can the project then update Mem_43_INFLS_eJobRuntimeInfo?

Regards,

Daniel

Any support, information, and technology (“Materials”) provided by NXP are provided AS IS, without any warranty express or implied, and NXP disclaims all direct and indirect liability and damages in connection with the Material to the maximum extent permitted by the applicable law. NXP accepts no liability for any assistance with applications or product design.  Materials may only be used in connection with NXP products. Any feedback provided to NXP regarding the Materials may be used by NXP without restriction.

[Changyuke]

Hi Daniel,

Thanks for the suggestions. I have checked the fault status registers, and here are the results:

• CFSR = 0x00000400

  • IMPRECISERR = 1

  • PRECISERR = 0

  • BFARVALID = 0

• HFSR = 0x40000000 (FORCED = 1)

• BFAR = 0x00000000

I also:

1. Disabled the MPU (removed MPU_ENABLE from the preprocessor).

2. Configured the system clock strictly according to the options listed in the RM (Option B core clk @120Mhz), but the system still enters HardFault.

3. I am not fully sure how to capture the exact fault instruction from the stack – could you please clarify how to do this in practice?

Do you have any further suggestions on how I can narrow down the root cause?

Thanks,
Changyuke

[Changyuke]

Hi Daniel,

Thanks for your quick reply.

I checked the fault status registers during the HardFault:

• CFSR = 0x00000400 (PRECISERR, precise data bus error)

• HFSR = 0x40000000 (FORCED)

• MMFAR = 0

• BFAR = 0

For context: before integrating the FEE module, the program runs normally without any HardFault. The fault only occurs after configuring and integrating FEE according to the demo, suggesting the issue is related to the FEE initialization sequence.

Also, I have not modified the default linker file or startup code — they are still the original ones from the SDK.

Regards,
Changyuke