Debugging hangs until relaunch #635
Comments
|
Seems that it depends on GDB version: |
|
As you can see, we are attempting to pause the program via GDB and neither is responding. We rely 100% on GDB to do the right thing which then relies on JLink to do the right thing. We have to pause GDB before we can issue any more commands. In the output above, it is says the If a program halts by itself, JLink is supposed to report that to GDB. It doesn't matter is that is due to a breakpoint or Yes, gdb 7.4.1 is quite old. I have had a lot of issues with late 2021 releases but early 2021 releases were okay. Also, I need a bit more of the output from the Debug Console -- from the point the breakpoint was hit. Try |
|
@haneefdm, thanks for your reply. Here is debug output with ❌ARM GDB 10.3-2021.10 (GUI not responding)❌ARM GDB 9-2020-q2-update (GUI not responding)✅ARM GDB 7.4.1.20130913-cvs (GUI works)Let me know if you want me to find exact GDB version where it was broken (I can try any version) |
|
@saloid Thanks for providing the info. But the ones that fail (let us just use "ARM GDB 9-2020-q2-update"), can I have the whole output. I don't see any transactions between Cortex-Debug and GDB. |
9-2020-q2-updateSeems that |
|
@haneefdm I downloaded another one arm toolchain: 10-2020-q4-major (GDB 10.1.90.20201028-git) |
|
Also I noticed that debug more stable if I remove |
|
Can you try our latest pre-release? You have to enable it on our extension in VSCode |
|
Here is another pre-release to try. https://github.com/Marus/cortex-debug/releases/tag/v1.5.1-pre4 Please re-open with details if this is still a problem. Haven't heard back from previous message |
|
Sorry for long time to reply. |
|
I don't know how to help you if this so gdb specific, but I don't recommend using 7.4. One more try. Can you provide the logs with Or maybe this issue is really a JLink issue where it is the one who is not responding properly to gdb. Do you wee anything range in the gd-server TERMINAL window (also attach please). |
|
Seems that config |
|
With the I can believe that at the very beginning (after a power-on-reset) JLink provides garbage stack because it picks up random data in SRAM and things it is real. There can be confusion, at every level of the SW. If you let it continue and then stop until after OS is initialized, does it work? |
|
Issue was when FreeRTOS is fully initialized and running. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I'm trying to debug STM32F4 hardware with freeRTOS using J-link, but after succesfull launch and run, debug totally hangs when it hits one of breakpoints (hardware or
__asm__("BKPT")). All action buttons (reset, pause and restart) became unresponsive (I can press them and even see command in debug console, but nothing else).Before reaching breakpoint everything works fine (I can run and pause, do step-by-step debugging and everything else), but when breakpoint is reached everything hangs. If I close and launch debug session again - I can see that execution stopped at my breakpoint.
launch.json
{ "version": "0.2.0", "configurations": [ { "name": "Jlink", "cwd": "${workspaceRoot}", "executable": "${workspaceRoot}/build/first_part.elf", "request": "attach", "type": "cortex-debug", "servertype": "jlink", "svdFile": "${workspaceRoot}/STM32F407.svd", "interface": "swd", "device": "STM32F407VG", "armToolchainPath": "/home/saloid/Documents/Projects/tools/gcc-arm-none-eabi-10.3-2021.10/bin", "showDevDebugOutput": true, "preAttachCommands": [ "set substitute-path /tmp/opentx ${workspaceRoot}/new_sources_path", "add-symbol-file ${workspaceRoot}/build/another_part.elf 0x080c0080", ], "rtos": "FreeRTOS", "moduleLoad": true, } ] }When brekpoint is reached (and debug hangs) I can see this in debug console:
And buttons are still in "Running state" (but really device is stopped)
When I push any button (reset, pause or restart) this appears in debug console:
Cortex-debug 1.4.4
The text was updated successfully, but these errors were encountered: