Frz Bit is set when starting another core

[Ahmed02]

Hello, I am developing a project which is based of 3 SWE (bootmanager - application - bootloader) using MPC5748G and S32 Design Studio. Both the app and bootloader uses FreeRTOS when starting another core in the startup code of bootmanager the bootloader FRZ bit becomes set and the code is stuck at prvIdleTask while that doesn't happen at the application. The flow of the project (bootmanager starts and boots another core then jumps to the app which jumps back the bootmanager that then jumps to bootloader) when removing booting the other core the code works fine and has no issues

[petervlna]

Hello,

No sure if I understand correctly whole process.

But to start core1 you simply have to:

void Core_Boot (void)
{
/* ~~~~~~~~~~~~~~~~~~~~~~~ Configure Cores ~~~~~~~~~~~~~~~~~~~~~~~~~ */ 
/* Enable Cores - Will start on next mode transition */

//MC_ME.CCTL1.R = 0x00FE; // (z4a) - boot core_0 is active
MC_ME.CCTL[2].R = 0x00FE; // (z4b) - core_1 is active
MC_ME.CCTL[3].R = 0x00FE; // (z2) - core_2 is active

/* Set Start address for other cores: Will reset and start */
/* Flash addresses */
MC_ME.CADDR[2].R = 0x00F90001; // core_1 (z4b) boot address
MC_ME.CADDR[3].R = 0x00F9C001; // core_2 (z2) boot address

/****************************** Preform mode change **************************/

/* Mode change Re-enter the drun mode, to start cores */
MC_ME.MCTL.R = 0x30005AF0; /* Mode & Key */
MC_ME.MCTL.R = 0x3000A50F; /* Mode & Key inverted */

while(MC_ME.GS.B.S_MTRANS == 1); /* Wait for mode entry complete */
while(MC_ME.GS.B.S_CURRENT_MODE != 0x3); /* Check DRUN mode entered */

}//Core_Boot

What does debugging show? Where is the code stuck?

Some timeout? IVOR exception? Clocks issue, mode transition stuck?

Best regards,

Peter

[Ahmed02]

Hello,

This is the project's flow for clarification (-> means jumping to the other image before each jump I deinitialize all the drivers):

bootmanager (starts the core using the same function you have sent) -> application -> bootmanager -> bootloader

The code gets stuck in the idle task of the freeRTOS and the clock seems to be the issue as the count register doesn't change. Sometimes the code doesn't get stuck without me changing anything and gets into an IVOR1 when initializing the CAN driver at the bootloader image.

When removing the booting function of the core all goes well and there are no issues.

Best Regards,

Ahmed

[petervlna]

Hello,

The code gets stuck in the idle task of the freeRTOS and the clock seems to be the issue as the count register doesn't change.

So I expect it will end in some endless loop and waiting for watchdog to trigger reset.

What is the precondition to get into the idle task? Also is your mode transition successful when you enable the cores?

Its quite hard to find issue if you do not provide some failure analyzes via chat.

I suggest to focus on step by step debugging, especially in the case right before you end up in the idle task. To see what is the precondition for such behavior.

Then check assembly code, to see of the instructions are correct and addresses core registers GPRs point to valid locations.

Best regards,

Peter

[Ahmed02]

Hello,

The mode transition was successful when I enabled the core, but it resulted in an endless loop. Upon further debugging, I discovered that after completing the mode transition, it was necessary to continue debugging the second core through the startup code and the main function. This approach prevents the main core from getting stuck in the idle task. I am uncertain about the exact reasoning behind this solution, and I would appreciate any insights you could provide regarding this behavior.

Additionally, the issue with the CAN initialization being stuck in an IVOR1 exception was resolved by increasing the heap size in FreeRTOS.

Best Regards,

Ahmed

[petervlna · Accepted solution]

Hello,

I am uncertain about the exact reasoning behind this solution, and I would appreciate any insights you could provide regarding this behavior.

Cores does not require to wait for other cores to finish their initialization.

They act independently. You can even have all cores active out of reset.

I am uncertain about the exact reasoning behind this solution, and I would appreciate any insights you could provide regarding this behavior.

I expect that this is caused by your SW. There must be some handshake, waiting for core initialization to finish, which is putting main core into the idle task.

So check where the second core get stuck in initialization causing the main core to go into idle task.

This seems to me like application issue.

You can try this example to see how the cores are enabled, initialized by SW and SW executed.

https://community.nxp.com/t5/MPC5xxx-Knowledge-Base/Example-MPC5748G-DPM-Multicore-GHS614/ta-p/10996...

Best regards,

Peter