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

[CNarendra]

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
  
  MPC5674F 

[petervlna]

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.

• Anybody has tried MPC56xx series with VSCODE debugging?

Not here in NXP.

Best regards,

Peter