IDE 2.x: Source level debugging using IDE 2.x

Software IDE 2.x
1

This is sort of a continuation of my other thread:
Building debug libmbed.a - Hardware / GIGA R1 - Arduino Forum

The main difference for this thread, is this is more generic. That is the other one, we came up with a solution that at least for me that builds a debug version of libmbed.a for the different MBED boards, in my case the GIGA

This thread is more about are there any tricks on how to source level debug using the IDE 2.x debug support.

Programmer:
I know that with most of these boards it will require an external programmer connected up to the board, through JTAG or SWD. There are 4 different options for GIGA:
(ARM CMISIS_DAP, BlackMagic, JLink, STLINK)
I actually have 3 out of 4 (that is I don't have Blackmagic. Currently setup for CMSIS_DAP.
On Ubuntu requires Udev Rules... Thanks @ptillisch, for generating one for the programmer I have. (Details on other thread).

Not sure what the others require, that is I have an ST-LINK V2, and a V3, and a JLink-EDU...

Locating Source files:
The debugger appears to work fine for normal source files, in that it appears you to at a minimum do a verify of your sketch before you can enter into the debugger. This probably takes care of finding the actual source files of your sketch which are probably in the temp directory after your verify or upload commands. Without doing this step each time you start up the IDE for debugging, the sketch locate may have changed within the Arduino temp directory.

However, libmbed.a and maybe other static libraries like, this could easily change.
in the case of libmbed.a, the build steps for this library, place all of the sources out on your temp drive, and by chance if you do your debug session just after building this library,
you can source level debug into this library. In my case I was trying step into a function that was contained in a file contained in the directory:
/tmp/mbed-os-program/mbed-os/targets/TARGET_STM/TARGET_STM32H7/STM32Cube_FW/STM32H7xx_HAL_Driver

However, if I reboot the machine, the contents of the /tmp directory are cleared, and you
can no longer step into the code contained within this library. I created an issue on this:

@facchinm, gave some good suggestions:

to perform source level debug of a rootless .a library, the path of the sources should be added to gdb via dir command . AFAIK there's no easy way to perform this in IDE 2 debug console,

One thing that is unclear in the IDE debug console, is what commands can I enter into the
command prompt:

image
image698×318 42.8 KB

It appears for example that it might allow me to try to use the:
dir command:
to add a directory to the search path. Now sure if it works, but still have not found any directories I have tried, that the debugger finds the source file.

I have also tried the: set substitute-path
command, but I don't believe the debug console input code likes it.

debug_custom.json:
umbynos has also give me some good advice in the issue:

Hey @KurtE, you should be able to specify additional gdb commands creating debug_custom.json in the sketch folder:
The IDE2 should allow the user to specify a set of configurations (full list available here) in debug_custom.json that will override the configuration automatically generated on the base of a fqbn + programmer pair.

I believe I probably need to go down this rabbit hole, so wondering if anyone has some
examples of how best to do this? For example would you add gdb lines to it like:
dir /home/kurte/mbed-os-program/mbed-os/targets/TARGET_STM/TARGET_STM32H7/STM32Cube_FW/STM32H7xx_HAL_Driver

or maybe

set substitution-path /tmp/mbed-os-program /home/kurte/mbed-os-program

And which section of the file? postAttachCommands ?

Thanks
Kurt

1 Like
2

Wondering, if I wish to try using the STLink V3,
is there a link to what is needed?

I have installed the cube software and it can see the GIGA.

Do I need a debug_custom.json file?

Is there a link to web or forum page that shows what is needed in this file?
Thanks

3

I recently bought the STLINK-V3MINIE, but haven't actually tried it out until now (I have used the ST-LINK/V2 previously). Unfortunately I was disappointed with my findings.

The first problem I encountered was the debugger initialization failing with "Error: open failed":

"C:\\Users\\per\\AppData\\Local\\Arduino15\\packages\\arduino\\tools\\openocd\\0.11.0-arduino2/bin/openocd" -c "gdb_port 50000" -c "tcl_port 50001" -c "telnet_port 50002" -s "c:\\Users\\per\\AppData\\Local\\Temp\\.arduinoIDE-unsaved20241013-2888-1sut77h.opth\\Blink" -f "C:/arduino-tools/253-63e9dfd/resources/app/plugins/cortex-debug/extension/support/openocd-helpers.tcl" -f interface/stlink.cfg -f "C:\\Users\\per\\AppData\\Local\\Arduino15\\packages\\arduino\\hardware\\mbed_giga\\4.2.1/debugger/select_hla.cfg" -f target/stm32h7x_dual_bank.cfg
Open On-Chip Debugger 0.11.0+dev-gab95bac57-dirty (2021-05-11-10:45)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
CDRTOSConfigure
hla_swd
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
Info : Listening on port 50001 for tcl connections
Info : Listening on port 50002 for telnet connections
Info : clock speed 1800 kHz
Error: open failed

When I looked in interface/stlink.cfg (full path: C:\Users\per\AppData\Local\Arduino15\packages\arduino\tools\openocd\0.11.0-arduino2\share\openocd\scripts\interface\stlink.cfg), I discovered that the 0483:3754 VID/PID pair of my STLINK-V3MINIE was not present in the file's hla_vid_pid command:

I added it:

hla_vid_pid 0x0483 0x3744 0x0483 0x3748 0x0483 0x374b 0x0483 0x374d 0x0483 0x374e 0x0483 0x374f 0x0483 0x3752 0x0483 0x3753 0x0483 0x3754

but the initialization fails with the same error. But there is a warning that explains this result:

Warn : ignoring extra IDs in hla_vid_pid (maximum is 8 pairs)

So openocd has an idiotic arbitrary limitation of eight VID/PID pair arguments of the hla_vid_pid command and it happens there were already eight, so when I added 0x0483 0x3754 that made it nine, so my addition was ignored. Fine, I'll play the game and remove one of the other VID/PID pairs to get back to eight:

hla_vid_pid 0x0483 0x3748 0x0483 0x374b 0x0483 0x374d 0x0483 0x374e 0x0483 0x374f 0x0483 0x3752 0x0483 0x3753 0x0483 0x3754

Now the debugger initialization fails with a new error:

"C:\\Users\\per\\AppData\\Local\\Arduino15\\packages\\arduino\\tools\\openocd\\0.11.0-arduino2/bin/openocd" -c "gdb_port 50000" -c "tcl_port 50001" -c "telnet_port 50002" -s "c:\\Users\\per\\AppData\\Local\\Temp\\.arduinoIDE-unsaved20241013-2888-1sut77h.opth\\Blink" -f "C:/arduino-tools/253-63e9dfd/resources/app/plugins/cortex-debug/extension/support/openocd-helpers.tcl" -f interface/stlink.cfg -f "C:\\Users\\per\\AppData\\Local\\Arduino15\\packages\\arduino\\hardware\\mbed_giga\\4.2.1/debugger/select_hla.cfg" -f target/stm32h7x_dual_bank.cfg
Open On-Chip Debugger 0.11.0+dev-gab95bac57-dirty (2021-05-11-10:45)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
CDRTOSConfigure
hla_swd
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
Info : Listening on port 50001 for tcl connections
Info : Listening on port 50002 for telnet connections
Info : clock speed 1800 kHz
Error: libusb_open() failed with LIBUSB_ERROR_NOT_SUPPORTED
Error: libusb_open() failed with LIBUSB_ERROR_NOT_SUPPORTED
Error: read version failed

I am familiar with the "libusb_open() failed with LIBUSB_ERROR_NOT_SUPPORTED" error from other debug probes. With those, I fixed the error by using Zadig to install the WinUSB driver. But when I selected the "ST-Link Debug (Interface 0)" device in Zadig, I found it was already using WinUSB driver, but an older version (2.2.0.0) than the one available via Zadig (6.1.7600.16385). I was able to update the driver by clicking the ▼ icon to the right of the button in the Zadig window, then selecting "Replace Driver" from the menu, but even after that I still got the same "libusb_open() failed with LIBUSB_ERROR_NOT_SUPPORTED" error when I tried starting the Arduino IDE debugger again. I gave the "libusbK" driver a try, but had the same result.

So I gave up on Windows and switched over to my Linux machine. Initialization now failed with the familiar "Error: open failed" message:

/home/per/.arduino15/packages/arduino/tools/openocd/0.11.0-arduino2/bin/openocd -c "gdb_port 50000" -c "tcl_port 50001" -c "telnet_port 50002" -s /tmp/.arduinoIDE-unsaved20241013-7495-98i1n1.0szhk/Blink -f /home/per/arduino-tools/2.x/249-2.3.3/resources/app/plugins/cortex-debug/extension/support/openocd-helpers.tcl -f interface/stlink.cfg -f /home/per/.arduino15/packages/arduino/hardware/mbed_giga/4.2.1/debugger/select_hla.cfg -f target/stm32h7x_dual_bank.cfg
Open On-Chip Debugger 0.11.0+dev-gab95bac57-dirty (2021-05-11-10:49)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
CDRTOSConfigure
hla_swd
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
Info : Listening on port 50001 for tcl connections
Info : Listening on port 50002 for telnet connections
Info : clock speed 1800 kHz
Error: open failed

This was expected due to the VID/PID pair being missing from interface/stlink.cfg on my Linux machine. I made the same modification to the file as I described above, then tried again. This time it failed with a new error:

/home/per/.arduino15/packages/arduino/tools/openocd/0.11.0-arduino2/bin/openocd -c "gdb_port 50000" -c "tcl_port 50001" -c "telnet_port 50002" -s /tmp/.arduinoIDE-unsaved20241013-7495-98i1n1.0szhk/Blink -f /home/per/arduino-tools/2.x/249-2.3.3/resources/app/plugins/cortex-debug/extension/support/openocd-helpers.tcl -f interface/stlink.cfg -f /home/per/.arduino15/packages/arduino/hardware/mbed_giga/4.2.1/debugger/select_hla.cfg -f target/stm32h7x_dual_bank.cfg
Open On-Chip Debugger 0.11.0+dev-gab95bac57-dirty (2021-05-11-10:49)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
CDRTOSConfigure
hla_swd
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
Info : Listening on port 50001 for tcl connections
Info : Listening on port 50002 for telnet connections
Info : clock speed 1800 kHz
Error: libusb_open() failed with LIBUSB_ERROR_ACCESS
Error: open failed

I am familiar with the "libusb_open() failed with LIBUSB_ERROR_ACCESS" error from other debug probes and boards. This just means that the user account doesn't have write access to the device, to be fixed by installing the appropriate udev rules file. I did that by running this command:

printf \
'SUBSYSTEM=="usb", ATTR{idVendor}=="0483", ATTR{idProduct}=="3754", MODE="0666", TAG+="uaccess"
' | \
  sudo \
    tee \
      "/etc/udev/rules.d/60-STLINK-V3.rules" \
&& \
sudo \
  udevadm \
    control \
    --reload-rules \
&& \
sudo \
  udevadm \
    trigger

Now the initialization fails with the "Error: read version failed" message (which I note was present in addition to the LIBUSB_ERROR_NOT_SUPPORTED error on my Windows machine as well):

/home/per/.arduino15/packages/arduino/tools/openocd/0.11.0-arduino2/bin/openocd -c "gdb_port 50000" -c "tcl_port 50001" -c "telnet_port 50002" -s /tmp/.arduinoIDE-unsaved20241013-7495-98i1n1.0szhk/Blink -f /home/per/arduino-tools/2.x/249-2.3.3/resources/app/plugins/cortex-debug/extension/support/openocd-helpers.tcl -f interface/stlink.cfg -f /home/per/.arduino15/packages/arduino/hardware/mbed_giga/4.2.1/debugger/select_hla.cfg -f target/stm32h7x_dual_bank.cfg
Open On-Chip Debugger 0.11.0+dev-gab95bac57-dirty (2021-05-11-10:49)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
CDRTOSConfigure
hla_swd
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
Info : Listening on port 50001 for tcl connections
Info : Listening on port 50002 for telnet connections
Info : clock speed 1800 kHz
Error: read version failed

I did some research on this "Error: read version failed" message and it seems the problem is that version 0.11.0 of openocd doesn't have support for STLINK-V3MINIE and the solution is to use 0.12.0 instead. I grabbed the build from the asset on the release page here (I had switched back to my Windows machine), replaced the arduino:openocd@0.11.0-arduino2 installation with those files (note that they have remove the eight VID/PID pair limit and added the added the 0483:3754 VID/PID pair to interface/stlink.cfg in 0.12.0), and tried again:

"C:\\Users\\per\\AppData\\Local\\Arduino15\\packages\\arduino\\tools\\openocd\\0.11.0-arduino2/bin/openocd" -c "gdb_port 50000" -c "tcl_port 50001" -c "telnet_port 50002" -s "c:\\Users\\per\\AppData\\Local\\Temp\\.arduinoIDE-unsaved20241013-2888-1sut77h.opth\\Blink" -f "C:/arduino-tools/253-63e9dfd/resources/app/plugins/cortex-debug/extension/support/openocd-helpers.tcl" -f interface/stlink.cfg -f "C:\\Users\\per\\AppData\\Local\\Arduino15\\packages\\arduino\\hardware\\mbed_giga\\4.2.1/debugger/select_hla.cfg" -f target/stm32h7x_dual_bank.cfg
Open On-Chip Debugger 0.12.0 (2023-01-14-23:37)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
CDRTOSConfigure
hla_swd
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
Info : Listening on port 50001 for tcl connections
Info : Listening on port 50002 for telnet connections
Info : clock speed 1800 kHz
Info : STLINK V3J8M3 (API v3) VID:PID 0483:3754
Info : Target voltage: 3.272289
Error: [stm32h7x.cpu0] Cortex-M PARTNO 0x0 is unrecognized
Warn : target stm32h7x.cpu0 examination failed
Info : starting gdb server for stm32h7x.cpu0 on 50000
Info : Listening on port 50000 for gdb connections
Info : accepting 'gdb' connection on tcp/50000
Error: Target not examined yet
Error executing event gdb-attach on target stm32h7x.cpu0:

Error: Target not examined yet
Error: auto_probe failed
Error: Connect failed. Consider setting up a gdb-attach event for the target to prepare target for GDB connect, or use 'gdb_memory_map disable'.
Error: attempted 'gdb' connection rejected

I tried adding gdb_memory_map disable to interface/stlink.cfg as suggested by the error, but I still get a similar error after doing that:

"C:\\Users\\per\\AppData\\Local\\Arduino15\\packages\\arduino\\tools\\openocd\\0.11.0-arduino2/bin/openocd" -c "gdb_port 50000" -c "tcl_port 50001" -c "telnet_port 50002" -s "c:\\Users\\per\\AppData\\Local\\Temp\\.arduinoIDE-unsaved20241013-2888-1sut77h.opth\\Blink" -f "C:/arduino-tools/253-63e9dfd/resources/app/plugins/cortex-debug/extension/support/openocd-helpers.tcl" -f interface/stlink.cfg -f "C:\\Users\\per\\AppData\\Local\\Arduino15\\packages\\arduino\\hardware\\mbed_giga\\4.2.1/debugger/select_hla.cfg" -f target/stm32h7x_dual_bank.cfg
Open On-Chip Debugger 0.12.0 (2023-01-14-23:37)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
CDRTOSConfigure
hla_swd
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
Info : Listening on port 50001 for tcl connections
Info : Listening on port 50002 for telnet connections
Info : clock speed 1800 kHz
Info : STLINK V3J8M3 (API v3) VID:PID 0483:3754
Info : Target voltage: 3.273896
Error: [stm32h7x.cpu0] Cortex-M PARTNO 0x0 is unrecognized
Warn : target stm32h7x.cpu0 examination failed
Info : starting gdb server for stm32h7x.cpu0 on 50000
Info : Listening on port 50000 for gdb connections
Info : accepting 'gdb' connection on tcp/50000
Error: Target not examined yet
Error executing event gdb-attach on target stm32h7x.cpu0:

Error: Target stm32h7x.cpu0 not examined yet, refuse gdb connection 1!
Error: attempted 'gdb' connection rejected

So I gave up at this point. Hopefully someone else will have a better idea of how to proceed. I'm certainly interested in finding a way to use my STLINK-V3MINIE.

It is possible that some of this experience is specific to the STLINK-V3MINIE I have, and wouldn't occur for you if you have a different STLINK-V3 models (at least the VID/PID pair stuff is likely not universal).

1 Like
4

Thanks,

I tried some of the steps you mentioned on the Ubunutu machine, and saw the same
results.

I looked up at the link for V0.12.0 and I am probably wrong, but the assets only looked like they were for windows... Maybe have to use the sources asset instead? As you mentioned, their list now had 9 items on it, which I believe the last one is the one we have. If so you think, maybe the added support for it, but...

I am guessing, I am probably better off, sticking with CMIS-DAP or try my older STLink/V2

But will keep fingers crossed that maybe there is a way to get these to work.

EDIT: looks like my old STLink/V2 works - 483:3748 STMicroelectronics ST-LINK/V2

5

@ptillish and all

With the stlink/V2 installed, I appear to have better luck with entering commands like
set substitute-path

in the debug console, and I was able to now source level debug the libmbed.a
functions, without having to rebuild them each time I boot and/or copy the files back to temp.

In particular, I built the debug version of the libmbed.a, I then copied the /tmp/mbed-os-program directory to my home directory.

image
image999×387 53.6 KB

I was able to type in the command: set substitute-path /tmp/mbed-os-program /home/kurte/mbed-os-program
And this time I responded... And I was then able to step into the HAL function :smiley:

Not sure if easy way to create debug_custom.json that would do just this?
Or would there be additional information, like which debugger, name, ...

But at least I have some stuff to try :smiley:
Next up, maybe try on my Windows machine to see if it might be able to
substitute to a windows type path from the unix type path...

EDIT: I meant V2 not V3... edited above

6

That is correct. I think they provide the Windows build because Windows doesn't have as well established of a package management system as Linux and macOS (to a lesser extent), and because it is often more difficult for Windows users to install the toolchains for building from source for the same reason.

For Linux, they recommend using the package manager or building from source:

https://openocd.org/pages/getting-openocd.html

I don't know how well suited the installation from the package repository would be for use with Arduino IDE. Arduino IDE needs to find the tool and its assets in the expected path:

/home/per/.arduino15/packages/arduino/tools/openocd/0.11.0-arduino2

and the package manager isn't going to put it there, but you might be able to create a symlink in that path, targeting the package manager installation.

If you do want an archive with OpenOCD 0.12.0 built for Linux, Arduino does distribute one (it is a dependency of the "Silicon Labs" boards platform of the Nano Matter):

https://downloads.arduino.cc/tools/openocd-0.12.0-arduino1-static-x86_64-ubuntu16.04-linux-gnu.tar.bz2

I tried using that "0.12.0-arduino1-static" version of OpenOCD on my Windows machine and had the same result as I described above from using the 0.12.0 version distributed by OpenOCD.

I'm glad you have better luck with your stlink/V3 than I did with mine!

Do you also have the STLINK-V3MINIE, or do you have one of the other STLINK-V3 variants (e.g., STLINK-V3SET)?

1 Like
7

Oops typo... ST-Link/V2...

8

@KurtE - Did you ever get IDE 2.3.3 debugging to work on the RPI5 with JLink and the GIGA?
It is working on three other X86_64 machines using Ubuntu 22.04 and 24.04 with the GIGA.
I have tried UBuntu 24.04 with both gnome classic an Ubuntu desktops on the RPI5 as well as Raspbian. The debugger starts and then quits with this message:

Request 2 cancelled on connection close.

The only thing I have not tried is building Arduino IDE on the RPI5. Maybe it has to do with Jlink GDB version for arm64. Not sure...

Edit: Why does this always happen. I post a question then immediately find the answer :smile: It was a missing libncurses5 library. Installed it and it works :laughing:

1 Like
9

I was about to answer that nope, no luck but did your install and :smiley:

1 Like