Environment:
- Device: NXP S32K324 (dual-core Cortex-M7_0 + M7_1)
- IDE: S32 Design Studio, Debugger: Segger Ozone + J-Link
- Project: Bootloader (M7_0) + Application (M7_0 + M7_1), MULTIPLE_IMAGE mode, FreeRTOS
---
Background / What we changed:
Our bootloader had CM7_1_ENABLE defined in all build configurations, we
removed CM7_1_ENABLE from both the bootloader and the Core 0 application builds .
To still have the ability to start Core 1 when needed, we added the following MC_ME-based startup function in the Core 0 application:
int MultiCoreBoot_StartCore1(void)
{
/* Skip if Core1 is already running */
if ((MC_ME_PRTN0_CORE1_STAT & MC_ME_CORE_STAT_CCS) != 0U)
{
return 0;
}
/* Step 1: Set M7_1 vector table address */
MC_ME_PRTN0_CORE1_ADDR = M7_1_VECTOR_TABLE_ADDR; // 0x00600000
/* Step 2: Enable Core1 clock */
MC_ME_PRTN0_CORE1_PCONF = MC_ME_CORE_PCONF_CCE;
/* Step 3: Trigger update */
MC_ME_PRTN0_CORE1_PUPD = MC_ME_CORE_PUPD_CCUPD;
/* Step 4 & 5: Unlock key sequence */
MC_ME_CTL_KEY = MC_ME_KEY; // 0x5AF0
MC_ME_CTL_KEY = MC_ME_INV_KEY; // 0xA50F
/* Wait for Core1 clock active */
while ((MC_ME_PRTN0_CORE1_STAT & MC_ME_CORE_STAT_CCS) == 0U) {}
return 0;
}
This function is called from the Core 0 application after system initialization.
---
Current problem:
We are trying to debug Core 1 in Ozone using "Attach to Running Program" (a second Ozone instance, separate .jdebug project pointing to the Core 1 ELF at
0x00600000). However, Ozone throws an error immediately on connection.
Questions:
1. Is the MC_ME startup code above correct for S32K324?
2. What is the correct Ozone / J-Link configuration to attach to Core 1 without resetting Core 0?
Hi @Julián_AragónM ,
Thank you for your support and the reference materials—they were very helpful in narrowing down the issue. We have successfully resolved the Core 1 "Attach" failure. Here is a quick summary:
MPU/Startup: Verified as requested; configurations are correct and not the cause.
Root Cause: The default S32K324.jlinkscript triggers an ECC RAM initialization (writing 0xDEADBEEF) when the second Ozone session connects. This inadvertently overwrites the SRAM regions being used by the running Core 0 (FreeRTOS), causing the system to crash.
The Fix: We overrode SetupTarget() in a custom J-Link script to skip the RAM initialization during "hot attach."
We can now stably debug both cores simultaneously. Hope this finding is useful for your team as well.
Best regards,
Changyuke
Hi @Changyuke,
The routine for starting Core 1 seems okay. Just could you please check the CM7_0 startup code and verify the MPU region attributes for the address 0x00600000? Just to confirm table base is a valid VTOR.
As for Ozone, I believe this is a question for SEGGER themselves. Please try contacting them instead: Ticket | SEGGER - The Embedded Experts.
We provide some documentation, but it is based on PEmicro, I am not sure if there is any specific configuration needed for Ozone:
Lastly, SEGGER does provide a wiki page for multi-core debugging: Multi-Core Debugging - SEGGER Knowledge Base. It seems like the needed configuration is shown there.
Best regards,
Julián