Debugging Issues When Using a Decoupled S32K344 as an S32K324

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Debugging Issues When Using a Decoupled S32K344 as an S32K324

524 Views
yanyanwang
Contributor I

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?

0 Kudos
Reply
1 Reply

425 Views
petervlna
NXP TechSupport
NXP TechSupport

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

0 Kudos
Reply