I've used the debugger a bit but anyone who's also used has quickly found out it is still very buggy and as a prominent feature of the v2 IDE I want to let you know people are bailing because of that. Just read this thread and look at the "solution"
FWIW, I just pulled out my Zero board and debugged a little blink app and it went rather well. But I did find a bug. When I started the debugging process using the "Start Debugger" icon in the toolbar(next to Upload button) it and the "start debugger" icon in the Debugger sideview were still enabled and clicking on them caused a debugger server error. I would think that once the debugger is running, These icons/actions would be disabled until the debugger was stopped.
I also didn't run into any breakpoint issues as long as I stopped the debugger before changing breakpoints. I will continue to try and break this.
Maybe look at the date while you are at it. The Arduino IDE developers updated the version of the Cortex-Debug VS Code extension that is the debugger you use in Arduino IDE in the 2.0.3 release:
Essentially all the bugs we were aware of were actually bugs in the previous version of that extension, not bugs in the Arduino IDE codebase.
There are currently only three outstanding formal bug reports related to the debugger:
Two of these are more closely related to the Arduino IDE user interface than the debugger functionality. The last is actually a deficiency in the "Arduino Mbed OS Portenta Boards" platform, but we are tracking it in the Arduino IDE repository because it was reported there by a user.
The developers can only work on problems they are aware of, so it is very valuable for users to submit reports of bugs they encounter (ideally to the extension repo if it is a bug in the extension), and essentially to follow up when we ask them to provide additional information about the problem. If we don't have any significant bugs in the tracker, the project managers aren't going to allocate resources to working on what appears to be a fully functional component.
I think the developers of the "Cortex-Debug" extension intentionally leave the "Start Debugging" button in the debugger widget enabled. There are likely use caseswhere you would start multiple simultaneous threads using different configurations.
There is also the question of whether that use case is applicable to using the debugger in the context of Arduino IDE 2.x. This is less clear to me. The situation is a bit different because the IDE automatically generates a single debugger configuration and I didn't see any way it would be useful to launch the same configuration twice.
But I'm also not very knowledgeable on the full scope of the potential for the IDE's debugger. I am only familiar with the specific usage of it by the "Arduino SAMD Boards (32-bits ARM Cortex-M0+)" platform with the CMSIS-DAP compliant and J-Link debug probes. The debugger is flexible enough that significantly different use cases are possible. For example, the ESP32 and "Raspberry Pi Pico" boards platforms now support the debugger and these are significantly different from the SAMD platform. We are sure to see many other platforms take advantage of the debugger over time.
Thanks! I remember some breakpoint-related bugs were fixed by that debugger extension update but there might still be some remaining bugs.
True that, ie it's and old post and maybe the same bugs aren't there any longer. But I have had a dickens of a time with the debugger. When the Espressif devs added the openocd capabilities it worked but not smoothly. I was trying to jump over things and it was jumping into them instead AND I had issues with the breakpoints not clearing and a few times I could no longer stop the frozen debugger and had to restart the IDE.
It still had worked well enough for the last bug I was chasing and was very nice not sprinkling Serial.println entries all over the code to chase it down.
I've updated the nightly builds twice since then and a guy on another forum took my comments about the IDE v2 having incircuit debugging and he went to try it and had problems with breakpoints not clearing and wasn't familiar with step-into, step-outof, step-over debugging but I found the docs and pointed him to it and recommended for the time being to stop the debugger, change breakpoints and start the debugger.
But OMH @ptillisch what hell I've been going through since this morning when I fired up the Zero and checked out that debugging. I went back to my esp32 and tried to debug a simple blink app and the debugger stopped working. I tried loading my esp-idf build env vars, fresh install of esp32, clearing /tmp and a bunch more and the debugger would not start. So I go back to the Zero and it no longer worked and keep wanting the xtensa debugger. I blew away my .arduino15/ directory, blew away my ~/.config/arduino-ide/ directory and emptied the /Arduino/ directory of everything by my blink sketch and even blew away and replaced the arduino-ide_nightlyxxx installation. Still getting zero with the Zero debugger. The latest full gdbserver output looks like this now:
Waiting for gdb server to start...[2023-01-20T03:54:14.356Z] SERVER CONSOLE DEBUG: onBackendConnect: gdb-server session connected. You can switch to "DEBUG CONSOLE" to see GDB interactions.
/home/maker/.arduino15/packages/arduino/tools/openocd/0.10.0-arduino7/bin/openocd -c "gdb_port 50000" -c "tcl_port 50001" -c "telnet_port 50002" -s /home/maker/Arduino/30DaysMaroonedOnAlphaCentauri/sketch_000-testing-MC-CPU-and-UNO-CPU -f /home/maker/Projects/Arduino/arduino-ide_nightly-20230119_Linux_64bit/resources/app/plugins/cortex-debug/extension/support/openocd-helpers.tcl -f /home/maker/.arduino15/packages/arduino/hardware/samd/1.8.13/variants/arduino_zero/openocd_scripts/arduino_zero.cfg
Open On-Chip Debugger 0.10.0+dev-gf0767a31 (2018-06-11-13:40)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
CDRTOSConfigure
Info : auto-selecting first available session transport "swd". To override use 'transport select <transport>'.
none separate
adapter speed: 400 kHz
cortex_m reset_config sysresetreq
Info : Listening on port 50001 for tcl connections
Info : Listening on port 50002 for telnet connections
Error: CMSIS-DAP command CMD_INFO failed.
[2023-01-20T03:54:15.524Z] SERVER CONSOLE DEBUG: onBackendConnect: gdb-server session closed
GDB server session ended. This terminal will be reused, waiting for next session to start...
I tried only installing the SAMD M0 board and then I installed the SAMD M3 board even though the docs don't say anything but installing the IDE and installing the Zero/SAMD M0 board. And after rebooting my computer that error is different from the one before the reboot. THAT is odd for a Linux system from my experience but maybe it has to do with /tmp droppings not being there on this run... Welp, in this case a disconnect and reconnect of the Zero on the USB port seemed to be what the debugger wanted. I did that many times before the reboot with no effect. Unfortunately I use an Anonymous browser to do lots of searching and so I don't get inundated with stuff about patching roof leaks, etc and I'd used it to search on the errors I was getting before the reboot so I can't find the key-words in my history. I have to move .arduino15/ back since there are so many libs there so hopefully it keeps working.
It's likely some of my problems originated by the fact that I had a stored sketch that I was trying to debug with different platforms and the extra stuff in the sketch directory was interfering with debugging with another board type. That's probably where the Zero debugging was looking for the xtensa openocd server. My head is spinning from this little outing.
yes and it turns out the esp32 build will create those with or without the Sketch menu option "Optimized for Debugging" being enabled.
Just removing debug_custom.json enables the Zero debugging to work again.
I offered two options to solve this, one is to use the "Optimize for Debugging" option in the Sketch menu and the other is to do like STM32 Arduino devs did and have compiler options in the Tools menu. Personally, I like having control of the compiler optimization settings and turning On/Off debugging levels makes sense there too.