K324 boot of second core

[x86]

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?

[danielmartynek]

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/Syste...

It could be related to the MPU and Cache.

BR, Daniel

[x86]

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

[danielmartynek]

Thanks @x86,

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

BR, Daniel

[x86]

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.

[danielmartynek]

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?

[x86]

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.

[danielmartynek]

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?

[x86]

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