-
Notifications
You must be signed in to change notification settings - Fork 116
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Dropped 'gdb' connection #348
Comments
Thanks for the report, I guess that's an issue with the new startup. Please report Other than this you possibly could try to configure remote debugging instead of the launch option, see https://github.com/WebFreak001/code-debug#using-gdbserver-for-remote-debugging-gdb-only for details. |
xtensa version:
Debug console output:
|
hm this seems like weird output:
can you also run again with downgradede extension where it works and send the log there? |
My suspicion is that this has to do with the timing changes that occurred between v0.25.1 and v0.26.0. In the previous version we'd try to start running 50ms after the debugger was started. This means, we weren't waiting for the rest of the initialization to complete (i.e., setting breakpoints, etc). My guess is that the According to the normal "target remote mode" (Types of Remote Connections), the Looking at the configuration, this really should be described as an {
"version": "0.2.0",
"configurations": [
{
"type": "gdb",
"request": "attach",
"name": "Flash and Debug Jlink",
"executable": "./build/ninja-fiw.elf",
"cwd": "${workspaceFolder}",
"gdbpath": "xtensa-esp32-elf-gdb",
"target": ":3333",
"remote": true,
"stopAtEntry": "app_main",
"autorun": [
"mon reset halt",
"flushregs"
]
}
]
} |
I have the same problem using the esp32 and I can confirm that using type "attach" instead of type "launch" resolved it for me and everyone here. |
MAybe it would be good to inspect the launch configuration at start (we already do this) and when we get a launch inspect the autorun commands for an "attach" or "target" - and in this case create at least a stderr message that this likely should be adjusted to the attach configuration - or better do this with a popup and as the user if we should create a converted configuration... If any of the windows users doing embedded debugging here could check if using gdb-multiarch from MSYS2 works at least as well a special debugger like xtensa-esp32-elf-gdb, this would be useful. |
I can confirm that changing the request to an "attach" also works for xtensa-esp32s3-elf-gdb. |
Well, or not. This is... weird. I'm currently trying to use the built-in USB JTAG thing the new ESP32S3 chips have. bin/openocd -f board/esp32s3-builtin.cfg
Open On-Chip Debugger v0.11.0-esp32-20220411 (2022-04-11-08:47)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
Info : esp_usb_jtag: VID set to 0x303a and PID to 0x1001
Info : esp_usb_jtag: capabilities descriptor set to 0x2000
Warn : Transport "jtag" was already selected
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : esp_usb_jtag: serial (F4:12:FA:42:B0:A8)
Info : esp_usb_jtag: Device found. Base speed 40000KHz, div range 1 to 255
Info : clock speed 40000 kHz
Info : JTAG tap: esp32s3.cpu0 tap/device found: 0x120034e5 (mfg: 0x272 (Tensilica), part: 0x2003, ver: 0x1)
Info : JTAG tap: esp32s3.cpu1 tap/device found: 0x120034e5 (mfg: 0x272 (Tensilica), part: 0x2003, ver: 0x1)
Info : esp32s3.cpu0: Target halted, PC=0x40000400, debug_reason=00000000
Info : esp32s3.cpu1: Target halted, PC=0x40000400, debug_reason=00000000
Info : starting gdb server for esp32s3.cpu0 on 3333
Info : Listening on port 3333 for gdb connections
Info : accepting 'gdb' connection on tcp/3333
Warn : No symbols for FreeRTOS!
Info : esp32s3.cpu0: Target halted, PC=0x403B245E, debug_reason=00000001
Info : Set GDB target to 'esp32s3.cpu0'
Info : Flash mapping 0: 0x10020 -> 0x3c020020, 30 KB
Info : Flash mapping 1: 0x20020 -> 0x42000020, 93 KB
Info : esp32s3.cpu0: Target halted, PC=0x403B245E, debug_reason=00000001
Info : Auto-detected flash bank 'esp32s3.cpu0.flash' size 8192 KB
Info : Using flash bank 'esp32s3.cpu0.flash' size 8192 KB
Info : esp32s3.cpu0: Target halted, PC=0x403B245E, debug_reason=00000001
Info : Flash mapping 0: 0x10020 -> 0x3c020020, 30 KB
Info : Flash mapping 1: 0x20020 -> 0x42000020, 93 KB
Info : Using flash bank 'esp32s3.cpu0.irom' size 96 KB
Info : esp32s3.cpu0: Target halted, PC=0x403B245E, debug_reason=00000001
Info : Flash mapping 0: 0x10020 -> 0x3c020020, 30 KB
Info : Flash mapping 1: 0x20020 -> 0x42000020, 93 KB
Info : Using flash bank 'esp32s3.cpu0.drom' size 32 KB
Info : New GDB Connection: 1, Target esp32s3.cpu0, state: halted
Warn : negative reply, retrying
Warn : Prefer GDB command "target extended-remote :3333" instead of "target remote :3333"
Info : Detected FreeRTOS version: (10.4.3)
Info : JTAG tap: esp32s3.cpu0 tap/device found: 0x120034e5 (mfg: 0x272 (Tensilica), part: 0x2003, ver: 0x1)
Info : JTAG tap: esp32s3.cpu1 tap/device found: 0x120034e5 (mfg: 0x272 (Tensilica), part: 0x2003, ver: 0x1)
Info : esp32s3.cpu0: Debug controller was reset.
Info : esp32s3.cpu0: Core was reset.
Info : esp32s3.cpu0: Target halted, PC=0x500000EF, debug_reason=00000000
Info : esp32s3.cpu0: Core was reset.
Info : esp32s3.cpu0: Target halted, PC=0x40000400, debug_reason=00000000
Info : esp32s3.cpu1: Debug controller was reset.
Info : esp32s3.cpu1: Core was reset.
Info : esp32s3.cpu1: Target halted, PC=0x40000400, debug_reason=00000000
Info : esp32s3.cpu1: Debug controller was reset.
Info : esp32s3.cpu1: Core was reset.
Info : esp32s3.cpu0: Target halted, PC=0x42005937, debug_reason=00000001
Info : Set GDB target to 'esp32s3.cpu0'
Info : esp32s3.cpu1: Target halted, PC=0x4037829E, debug_reason=00000000
Info : Detected FreeRTOS version: (10.4.3) When I start OpenOCD as normal user the log looks exactly the same as when launching it as SU, but connecting GDB with Native-Debug suddenly gives me a bin/openocd -f board/esp32s3-builtin.cfg
Open On-Chip Debugger v0.11.0-esp32-20220411 (2022-04-11-08:47)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
Info : esp_usb_jtag: VID set to 0x303a and PID to 0x1001
Info : esp_usb_jtag: capabilities descriptor set to 0x2000
Warn : Transport "jtag" was already selected
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : esp_usb_jtag: serial (F4:12:FA:42:B0:A8)
Info : esp_usb_jtag: Device found. Base speed 40000KHz, div range 1 to 255
Info : clock speed 40000 kHz
Info : JTAG tap: esp32s3.cpu0 tap/device found: 0x120034e5 (mfg: 0x272 (Tensilica), part: 0x2003, ver: 0x1)
Info : JTAG tap: esp32s3.cpu1 tap/device found: 0x120034e5 (mfg: 0x272 (Tensilica), part: 0x2003, ver: 0x1)
Info : esp32s3.cpu0: Target halted, PC=0x42005937, debug_reason=00000001
Info : esp32s3.cpu1: Target halted, PC=0x4037829E, debug_reason=00000000
Info : starting gdb server for esp32s3.cpu0 on 3333
Info : Listening on port 3333 for gdb connections
Info : accepting 'gdb' connection on tcp/3333
Warn : No symbols for FreeRTOS!
Info : esp32s3.cpu0: Target halted, PC=0x403B245E, debug_reason=00000001
Info : Set GDB target to 'esp32s3.cpu0'
Info : Flash mapping 0: 0x10020 -> 0x3c020020, 30 KB
Info : Flash mapping 1: 0x20020 -> 0x42000020, 93 KB
Info : esp32s3.cpu0: Target halted, PC=0x403B245E, debug_reason=00000001
Info : Auto-detected flash bank 'esp32s3.cpu0.flash' size 8192 KB
Info : Using flash bank 'esp32s3.cpu0.flash' size 8192 KB
Info : esp32s3.cpu0: Target halted, PC=0x403B245E, debug_reason=00000001
Info : Flash mapping 0: 0x10020 -> 0x3c020020, 30 KB
Info : Flash mapping 1: 0x20020 -> 0x42000020, 93 KB
Info : Using flash bank 'esp32s3.cpu0.irom' size 96 KB
Info : esp32s3.cpu0: Target halted, PC=0x403B245E, debug_reason=00000001
Info : Flash mapping 0: 0x10020 -> 0x3c020020, 30 KB
Info : Flash mapping 1: 0x20020 -> 0x42000020, 93 KB
Info : Using flash bank 'esp32s3.cpu0.drom' size 32 KB
Info : New GDB Connection: 1, Target esp32s3.cpu0, state: halted
Warn : negative reply, retrying
Warn : Prefer GDB command "target extended-remote :3333" instead of "target remote :3333"
Info : Detected FreeRTOS version: (10.4.3)
Info : JTAG tap: esp32s3.cpu0 tap/device found: 0x120034e5 (mfg: 0x272 (Tensilica), part: 0x2003, ver: 0x1)
Info : JTAG tap: esp32s3.cpu1 tap/device found: 0x120034e5 (mfg: 0x272 (Tensilica), part: 0x2003, ver: 0x1)
Info : esp32s3.cpu0: Debug controller was reset.
Info : esp32s3.cpu0: Core was reset.
Info : esp32s3.cpu0: Target halted, PC=0x500000EF, debug_reason=00000000
Info : esp32s3.cpu0: Core was reset.
Info : esp32s3.cpu0: Target halted, PC=0x40000400, debug_reason=00000000
Info : esp32s3.cpu1: Debug controller was reset.
Info : esp32s3.cpu1: Core was reset.
Info : esp32s3.cpu1: Target halted, PC=0x40000400, debug_reason=00000000
Info : dropped 'gdb' connection |
Your output says:
That's likely a good idea, see #330 for the documentation of how this needs to be setup (so far no one has provided a PR to get the missing pieces into README). In any case - can you please provide the debug console log output from the extension in both cases so we see what is happening on the GDB side? |
Well... not really no. Don't get me wrong, I'd like to, I just discovered that changing the tiniest thing in the configuration leads to the GDB connection to get established. So, for example, setting Also, even if OpenOCD complains about the GDB connection getting dropped, simply running GDB again by re-running the launch configuration is enough to make it work. Someone above mentioned something about a timeout or delay... this smells a lot like a timing issue to me. |
Hm, then I suggest to post the log with Any thoughts about using extended-remote? |
Oh I'm sorry. Now I get it. I thought the Not working. (started OpenOCD manually) Reading symbols from /home/vinci/Develop/VSCode/ESP32Playground/build/ESP32Playground.elf...
0x4037829e in esp_cpu_wait_for_intr () at /home/vinci/esp/esp-idf/components/xtensa/include/xt_utils.h:81
81 asm volatile ("waiti 0\n");
[New Thread 1070547120]
[New Thread 1070545232]
[New Thread 1070536052]
[New Thread 1070540500]
[New Thread 1070534676]
[Switching to thread 1 (Thread 1070549008)]
JTAG tap: esp32s3.cpu0 tap/device found: 0x120034e5 (mfg: 0x272 (Tensilica), part: 0x2003, ver: 0x1)
JTAG tap: esp32s3.cpu1 tap/device found: 0x120034e5 (mfg: 0x272 (Tensilica), part: 0x2003, ver: 0x1)
esp32s3.cpu0: Debug controller was reset.
esp32s3.cpu0: Core was reset.
esp32s3.cpu0: Target halted, PC=0x500000EF, debug_reason=00000000
esp32s3.cpu0: Core was reset.
esp32s3.cpu0: Target halted, PC=0x40000400, debug_reason=00000000
esp32s3.cpu1: Debug controller was reset.
esp32s3.cpu1: Core was reset.
esp32s3.cpu1: Target halted, PC=0x40000400, debug_reason=00000000
Hardware assisted breakpoint 1 at 0x42005937: file /home/vinci/Develop/VSCode/ESP32Playground/main/main.cpp, line 20.
Register cache flushed.
[Inferior 1 (Remote target) detached] Working. (started OpenOCD with
Well, yes. Switching from this "target": ":3333",
"remote": true to this "target": "extended-remote :3333" basically works. But again the latter seems to produce timings which result in the initial connection getting dropped... |
@higaski, looking at your logs above, it appears when you run OpenOCD manually, it starts running the inferior before the extension has even finished initialization (seeing that the "[New Thread ...]" lines show up before we've set the "app_main" breakpoint). I'm not familiar with OpenOCD or with your target, so just asking as part of trying to understand what normally happens on startup. I assume the target may start running, but that you issue "monitor reset halt" in the Look at where the "[New Thread ...]" lines are between the two different logs. When you manually start, those occur much earlier in the log, which means the inferior has started running at that point in time. This happens before we can even set the breakpoint for "app_main" as part of the In the second log, you can see the "[New Thread ...]" lines appearing after the breakpoint is set. That is consistent with what I would expect. As part of the As far as the disconnect in the first log, I do have a suspicion about what might be happening. As part of the extension's default behavior (unless As an experiment to help prove if this is what is happening, can you make the following changes to your configuration and let me know if this fixes the issue:
See if when you run this, and then manually continue (by pressing the continue button), if this fixes your problem. If so, this is likely an indication of my suspicion of the extension issuing the "continue" command before all of the |
I've updated the launch config just as you've described and the behavior is exactly as predicted. |
@higaski, I've created an update that hopefully addresses the issue you are having. I'm hoping you can install the attached VSIX to confirm if this fixes your problem. If so, this will get rolled into the next official release. The current set of changes are in my forked branch here. If you're unsure how to manually install an extension, refer to the Install from a VSIX. Note, you will need to rename the .zip extension to .vsix before following those instructions...apparently Github only allows attachments with certain file extensions and .vsix was not one of them. |
Using the old configuration "stopAtEntry": "app_main",
"autorun": [
"mon reset halt",
"thb app_main",
"flushregs"
], this now works yes. The only time I can still trigger the "dropped connection" message is by trying to restart the target (green circle arrow button). |
I'm glad to hear that is working properly now. As for the "restart" scenario, do you have a log for that you can post? Does the "dropped connection" happen at the same spot as the previous scenario? I think the restart is equivalent to hitting the stop button and then relaunching the debug configuration...I assume that sequence works as expected. |
Actually there are two options depending on the support the debug extension claims. If it claims it supports a restart then an appropriate command is executed, if it doesn't then dap issues a stop and then a start command. In both cases it could be that the server side has an issue, especially in the "supported" case if the extension does not execute the autorun commands and/or more are needed for the restart scenario. |
It would also be good to know if the "restart" behavior differs between the use of the "remote" configuration and the "extended remote" configuration. Looking at the internals for handling the disconnect request, it appears for an "extended remote" we send "-target-detach" and for the regular "remote", we just send "-gdb-exit". I wonder if the "dropped connection" only happens with one of these. |
I'm claiming this as fixed with f37ffb2, which is the proposed fix that was successfully verified to address the original issue. Feel free to create a new issue for the "restart" behavior if you are still seeing that problem. |
Environment:
OS: Windows 10, 11, MacOS (tried in all)
Visual Studio Code
Native Debug version v0.26.0
OpenOCD session running in background
Hardware ESP32
JTAG hardware ESP-prog
Issue:
My debugging environment stops working after updating to v0.26.0. When starting a session openocd reports gdb session as dropped.
After reverting to v0.25.1 it works as usual.
Copy of launch.json
If submitting a bug please make sure
gdb --version
>= 7.7.1gdb
cwd
andtarget
are properly setlldb --version
>= 3.7.1lldb-mi
cwd
andtarget
are properly setScreenshots are helpful but not required
The text was updated successfully, but these errors were encountered: