Debugging Issues When Using a Decoupled S32K344 as an S32K324

yanyanwang — Sat, 17 Jan 2026 12:44:59 GMT

After the decoupling process, the S32K344 is equivalent to the S32K324. I created a dual-core project based on the S32K324, which contains two projects corresponding to Core 0 and Core 1. However, during debugging, even when using independent (per-core) debugging, I am only able to successfully debug Core 0, while Core 1 cannot be connected or debugged. Could you please advise on the possible reasons for this behavior?

Re: Debugging Issues When Using a Decoupled S32K344 as an S32K324

petervlna — Mon, 19 Jan 2026 08:25:19 GMT

Hello,

Once you verify the core 1 is released from reset it should be accessible by debugger if no further protection was applied.

Test A (Attach sequence):
Start a Core0 debug session first, run to the point where your code releases Core1, then attach a second debug session to Core1 (selecting Cortex‑M7_1 in your probe). If this works, the issue is likely bring‑up order or attach mode
Test B (Minimal Core1 image):
Flash a trivial Core1 firmware (just loops); ensure Core0 sets the start address and releases Core1. If Core1 attaches now, the problem is in Core1 init or watchdog.
Test C (Under‑reset attach to Core1): if apply to your debugger.
Try “connect under reset” for Core1, then immediately halt and inspect PC/VTOR to confirm the vector table address is valid. If VTOR points nowhere, fix the linker/ROM location

Best regards,

Peter

topic Re: Debugging Issues When Using a Decoupled S32K344 as an S32K324 in S32K

Debugging Issues When Using a Decoupled S32K344 as an S32K324

Re: Debugging Issues When Using a Decoupled S32K344 as an S32K324