Debugger gets stuck on 'starting target CPU'

[gabriel-green]

Hello, I am having an issue where sometimes debugging will get stuck after flashing new code onto my micro. I am using the "servertype: external" option as I am launching the JLink GDB server myself each time prior to running cortex debug. The issue seems to be most repeatable after first trying to flash the code after building. Sometimes just stopping the current debug session and restarting it will get it working again with no issue.

Steps to reproduce the behavior:

1. Build code
2. Launch debug (see launch.json)

Environment:

• Cortex-Debug Version 1.12.0
• OS: Linux Ubuntu 22.04 LTS (Container)
• GDB Version: v12.2
• Compiler Toolchain Version: arn-none-eabi v12.2

launch.json file { "name": "CortexDebug Container launch", "type": "cortex-debug", "request": "launch", "cwd": "${workspaceFolder}", "executable": "./build/debug/sw0478-gcu-app.elf", "servertype": "external", "gdbTarget": "host.docker.internal:50000", "device": "MKV58F1M0xxx24", "runToEntryPoint": "main", "svdFile": "${workspaceFolder}/tools/build/MKV58F24.svd", "showDevDebugOutput": "vscode", "internalConsoleOptions": "openOnSessionStart", },

Debug Console Output debug_console.txt

Some additional context: using the attach configuration works every time! launch.json (attach version)
{ "name": "CortexDebug Container attach", "type": "cortex-debug", "request": "attach", "cwd": "${workspaceFolder}", "executable": "./build/debug/sw0478-gcu-app.elf", "servertype": "external", "gdbTarget": "host.docker.internal:50000", "device": "MKV58F1M0xxx24", "svdFile": "${workspaceFolder}/tools/build/MKV58F24.svd", "showDevDebugOutput": "vscode", "internalConsoleOptions": "openOnSessionStart" },

what JLinkGDBServer outputs when it gets stuck:

Additional context Running VSCode and Cortex debug in a container, while running JLinkGDBServer on host machine.

[haneefdm]

I am having an issue where sometimes debugging will get stuck ...

Could you explain what "stuck" means?

Also, I need more (or full) of the text from the Debug Console...

[gabriel-green]

Sorry, didn't realize the full debug console output was not pasted in. Full output with it not working is attached here: debug_console.txt

I can also record a longer console output, where I try to pause and/or breakpoint without any success, if that would be helpful.

Also here is a console output from a time where it worked: success_debug_console.txt

By stuck, I mean it never gets to the entry point which I have set as 'main' currently in the launch.json. And looking at the output from JlinkGDBServer where it hangs at "Starting target CPU" it doesn't look like GDB is trying to do much after that point.

[haneefdm]

Can you pause the debugger while it seems stuck though. None of us (gdb, cortex-debug, vscode, users) can do anything until the program halts by itself ... because we are all waiting for the program to hit a breakpoint. If you can pause, it is an issue in your FW. I bet you can't even pause...

I will look at the logs soon while I wait for the answer

[gabriel-green]

Correct, I couldn't even pause in that situation.

I have an update! I was playing around with cpptools launch configuration instead and running into similar issues with their tool. Eventually found this thread https://github.com/microsoft/vscode-cpptools/issues/10558 which lead me to this thread https://github.com/Marus/cortex-debug/issues/795#issuecomment-1365085716 where I think you basically solved this issue already.

My understanding now is that "servertype": "external" does not use quite the same sequence of launch commands as you would get with servertype "jlink", which I've used successfully before with a Windows only setup.

Now with these overrides added to my launch configuration, everything works in the container!

 ...        "overrideLaunchCommands": [
                "monitor halt",
                "monitor reset",
                "-target-download",
                "monitor reset"
            ],
            "overrideResetCommands": [
                "monitor reset",
            ],
            "overrideRestartCommands": [
                "monitor reset",
            ]
...

[PhilippHaefele]

@gabriel-green Another solution colleges using at work is by using the https://wiki.segger.com/J-Link_Remote_Server which is maybe easier than your approach and you can easily use the jlink servertype with the ipAddress option

[gabriel-green]

@PhilippHaefele Good suggestion. I've used Segger's remote server a bit as well with Cortex-debug. Its useful, especially if you are trying to have remote debugging or for example run your dev container in codespaces. I find the latency and speed for their remote tunnel is not so great through - so not the best solution for local debugging.

[gabriel-green]

@haneefdm Thanks for looking into my issue! I think I will close this issue now, since there is already a launch configuration that fixes this particular problem with JLink.

Edit: Also wanted to mention, Live watch seems to work as well even though I'm using the 'external' servertype configuration