S32KのトピックRe: K324 boot of second core

K324 boot of second core

x86 — Tue, 19 Aug 2025 09:07:29 GMT

I found this post that contains a procedure on how to boot the second core of a K324:
https://community.nxp.com/t5/S32K/S32K324-seperate-core-code/m-p/1790024

We have successfully used this internally in a project. Now I am building a bootloader, which must be able to load applications to run on the first (c0) and second (c1) cores. This loading part works, and I can verify that the application for c1 resides in memory, starting at 0x600000. The first 0x2000 Bytes are taken up by a custom header which we need to identify the application. After that, starting at 0x602000 is the Interrupt Vector Table. I can verify that it is correctly installed at this location.

However, after following the procedure documented in the Link above (and the other internal project), c1 is not booted. By attaching with a debugger, I can see that a hardfault has occurred at 0x00000000. Additionally, the SP and PC registers contain garbage values (0x2C6F7920 and 0x2E707040).

However, if I tell the debugger to load SP and PC from the locations 0x602000 and 0x602004 and start execution from there, everything works. So my question is: why is the handover from core0 to core1 not working as expected?

Re: K324 boot of second core

danielmartynek — Wed, 20 Aug 2025 12:55:37 GMT

Hi @x86,

What type of fault exception is it?

Can you read the Configurable Fault Status Register (CFSR) ?

https://developer.arm.com/documentation/ddi0403/d/System-Level-Architecture/System-Address-Map/System-Control-Space--SCS-/Configurable-Fault-Status-Register--CFSR

It could be related to the MPU and Cache.

BR, Daniel

Re: K324 boot of second core

x86 — Wed, 20 Aug 2025 13:02:41 GMT

Here's the readout of CFSR, UFSR, BFSR, MMFSR and HFSR.

Re: K324 boot of second core

x86 — Wed, 20 Aug 2025 13:52:33 GMT

Here's a readout of CFSR, UFSR, BFSR, MMFSR and HFSR.

Re: K324 boot of second core

danielmartynek — Fri, 22 Aug 2025 06:55:39 GMT

Thanks @x86,

Can you also share the code you use to start CM7_1?

BR, Daniel

Re: K324 boot of second core

x86 — Mon, 25 Aug 2025 05:50:10 GMT

Of course, here it is:

uint32_t vtor = 0x602000U; MC_ME->PRTN0_CORE1_ADDR = vtor; MC_ME->PRTN0_CORE1_PCONF = MC_ME_PRTN0_CORE1_PCONF_CCE_MASK; MC_ME->PRTN0_CORE1_PUPD = MC_ME_PRTN0_CORE1_PUPD_CCUPD_MASK; MC_ME->CTL_KEY = MC_ME_CTL_KEY_KEY( 0x5AF0); MC_ME->CTL_KEY = MC_ME_CTL_KEY_KEY(~0x5AF0);

I have also tried setting the LSB of the vtor address because the code is in Thumb format.

For reference, here is an excerpt of the Flash at the location of the bootloader, which starts at 0x400000 and is prefixed by the NXP boot header entry (8KB)

And here is the application, which starts at 0x600000 and is prefixed by our own application header (also 8KB)

From these images, to me, everything looks to be where it is expected.

Re: K324 boot of second core

danielmartynek — Tue, 26 Aug 2025 06:53:11 GMT

Hi @x86,

Could you please check the CM7_0 startup code and verify the MPU region attributes for the address 0x602000?
Also, could you try disabling the MPU temporarily and test whether Core1 boots correctly in that configuration?

Re: K324 boot of second core

x86 — Tue, 26 Aug 2025 09:25:08 GMT

I dug through the MPU init code and found the following comment on the RASR value for the relevant region:

/* Size: import information from linker symbol, Type: Normal, Inner Cache Policy: Inner write-back, write and read allocate, Outer Cache Policy: Outer write-back. write and read allocate, Shareable: Yes, Privileged Access: Read-Only, Unprivileged Access: Read-Only */

The actual value of the RASR is 0x160B0023UL.
I manually decoded it according to The ARM MPU register description.
The description seems to match.

I have also tried disabling the MPU in the two application projects, as well as the bootloader project. I can verify that the code to set up the MPU is not compiled into the binary.

However, even after power cycling, which I assume resets the MPU configuration, the behaviour persists.

Re: K324 boot of second core

danielmartynek — Wed, 27 Aug 2025 11:41:30 GMT

Hi @x86,

Thank you for the confirmation.

It could be also due to incorrect ECC initialization in volatile memories.

Do you see any flag in DMC_GPR DCMROD3, DCMROD4 registers when it crashes?