MPC5674F – Breakpoints in VS Code cause PC to jump to RCHW with SIGINT/IVOR6 trap

CNarendra — Mon, 08 Sep 2025 09:59:24 GMT

Hello,

I am debugging an MPC5674F (e200z7, VLE) application.

Toolchain: GCC powerpc-eabivle-gcc, GDB powerpc-eabivle-gdb
In S32 Design Studio IDE, debugging works perfectly: breakpoints hit and resume continues as expected.
In VS Code with the same ELF, breakpoints hit, but when I continue, the PC jumps to 0x00000004 (RCHW) instead of resuming at the correct address. This immediately triggers a Program Exception (IVOR6) and I also see a SIGINT trap reported in the debugger.

Checks done:

ELF entry point is correct (0x400, Reset_Handler).
Symbols load fine.
Compiler flags: -mcpu=e200z7 -mvle -g3 -O0.
After failure, GDB shows:

$pc = 0x4 <RCHW+4>
Program received signal SIGTRAP, Trace/breakpoint trap.
Program received signal SIGINT, Interrupt.
0x00000650 in IVOR6_Vector ()
Question:
Why does PC reset to RCHW (0x00000004) and cause SIGINT/IVOR6 after breakpoints only in VS Code?
What reset/init or breakpoint handling sequence does S32 Design Studio use that I should replicate in VS Code to avoid this?
Anybody has tried MPC56xx series with VSCODE debugging?
Let me know if you need launch.json configuration

Thanks
Narendra.C

Re: MPC5674F – Breakpoints in VS Code cause PC to jump to RCHW with SIGINT/IVOR6 trap

petervlna — Mon, 08 Sep 2025 11:18:40 GMT

Hello,

Why does PC reset to RCHW (0x00000004) and cause SIGINT/IVOR6 after breakpoints only in VS Code?

There can be 2 reasons:

1. reset has occurred.

2. branch to that address was executed.

What reset/init or breakpoint handling sequence does S32 Design Studio use that I should replicate in VS Code to avoid this?

S32DS support mulitple debugger interfaces. Breakpoints are managed via GDB and the debugger interface.

Not here in NXP.

Best regards,

Peter