[J-Link] Debug session doesn't stop in breakpoint after flash is erased

[DragosMiloiuNXP]

Environment

• OS and version: Windows, Linux
• VS Code: 1.77
• C/C++ extension: v1.14.5
• OS and version of remote machine (if applicable): N/A
• GDB version: any

Bug Summary and Steps to Reproduce

Bug Summary: [J-Link] Debug session doesn't stop in breakpoint after flash is erased.

Steps to reproduce:

1. Connect a Segger J-Link Probe to a NXP LPCXPRESSO55S69 board.
2. Open a terminal in the project folder and erase the flash by issuing the following command: "C:\Program Files\SEGGER\JLink\JLink.exe" -if SWD -speed auto -commanderscript script.jlink -device LPC55S69_M33_0
3. Debug the attached project from VS Code.

Result: Target doesn't stop at main. From the logs, it seems that the target actually stops, but cppdbg tells it to continue execution. If the debug session is done without erasing the flash first it stops at main as expected.

Debugger Configurations

launch.json:
{
  "configurations": [
    {
      "type": "cppdbg",
      "name": "Debug project configuration",
      "request": "launch",
      "cwd": "c:\\Bug\\lpcxpresso55s69_hello_world",
      "MIMode": "gdb",
      "program": "c:\\Bug\\lpcxpresso55s69_hello_world\\armgcc\\debug\\hello_world.elf",
      "miDebuggerPath": "c:\\gdb\\bin\\arm-none-eabi-gdb.exe",
      "debugServerPath": "C:\\Program Files\\SEGGER\\JLink\\JLinkGDBServerCL.exe",
      "miDebuggerServerAddress": "localhost:2330",
      "postRemoteConnectCommands": [
        {
          "text": "monitor reset"
        },
        {
          "text": "load"
        },
        {
          "text": "tbreak main"
        },
        {
          "text": "monitor semihosting enable"
        },
        {
          "text": "monitor exec SetRestartOnClose=1"
        },
        {
          "text": "monitor reset"
        }
      ],
      "debugServerArgs": "-nosilent -swoport 2331 -telnetport 2332 -singlerun -endian little -noir -speed auto -port 2330 -vd -device LPC55S69_M33_0 -if SWD -halt -reportuseraction",
      "serverStarted": "Connected to target",
      "unknownBreakpointHandling": "stop"
    }
  ]
}

Debugger Logs

Debug log attached. debug.log

Other Extensions

No response

Additional Information

lpcxpresso55s69_hello_world.zip

[benmcmorran]

Based on offline discussion, setting "stopAtEntry": true in the launch.json seems to resolve this issue.

[CristiLupascuNXP]

Hi @benmcmorran,

Unfortunately, this doesn't completely solve the issue. Setting stopAtEntry: true causes the target to stop before main() sometimes. More specifically, it stops in the Reset_Handler(), right where the actual entry point is. It seems that sometimes MIDebugger treats main() as the entry point and sometimes Reset_Handler() is treated the entry point.

I've tested this with multiple boards and gdb servers, and the common pattern is the following:

• If at target-connect, the target is stopped at an address that GDB recognizes, Reset_Handler (the proper entry point) is treated as the entry point. In this case the debug session first stops here, then the user needs to resume debugging to stop at the breakpoint we placed at main.
• Instead, if at connect time the GDB doesn't recognize the address, the first stop is at main() as expected.

In short, if after target remote GDB shows a proper function name, it will stop at Reset_Handler when debugging from vscode.

Remote debugging using :2366
0x000019e2 in USART_ReadBlocking (base=0x40086000, data=0x20032fe7 "", length=1)
    at C:/Users/nxf67777/Desktop/sdks7/core/drivers/flexcomm/fsl_usart.c:697
697             while ((base->FIFOSTAT & USART_FIFOSTAT_RXNOTEMPTY_MASK) == 0U)
Resetting target

If instead it shows ??, it will stop at main when debugging from vscode.

Remote debugging using :2366
0x20006040 in ?? ()
Resetting target