Electronics > Microcontrollers

ST's gdb server, probe-rs, JLink, BlackMagic differences between them?

(1/11) > >>

incf:
Hi,

I currently spend a lot of time developing on Cortex-M0+ STM32s. (also use low power STOP1 mode a lot, but disable it for debugging)

I find that the debug tools are pretty buggy and have strange limitations that are not well documented.

I tend to directly use gdb in text mode to maximize my chances of having things work.

I would like find out if a J-Link probe and J-Link gdb server might be "better" than ST's gdb server, and probe-rs's gdb server.

I currently am using a ST-LinkV2 probe.

When I use ST's gdb server I encounter the following limitations:

* step and next work fine, but...
* I can't do any variation of "print *0x40000000" (x/x 0x40000000 works)
* I can't do any variation of "set *0x40000000=123"
* watchpoints don't really work (or at least, they can't be deleted)
* I can't single step instructions into interrupts or exceptions
* Monitor reset don't work reliably

When I use probe-rs's gdb server I encounter the following limitations:

* step and next only step single assembly instructions (although it is useful for looking at interrupts/exceptions it makes it useless for regular debugging)
* I can't do any variation of "print *0x40000000" (x/x 0x40000000 works)
* I can't do any variation of "set *0x40000000=123"
* watchpoints don't really work
Would a J-Link or some other gdb server software solve some of the above limitations?

edit: added black magic to subject line since it was mentioned below and did not show in search
edit: copying example here for visibility

--- Code: ---//After connecting to stlink gdb server with target extended-remote :61234
//This command is accepted and several packets related to this command are sent to the gdb server
(gdb) set {int}0x20000000 = 123
(gdb) print {int}0x20000000
$1 = 123

//It Works!
//But only before the MCU executes its first instruction

(gdb) continue
//Then either interrupt to get the prompt back with control-C or wait until you hit a breakpoint

//Running continue breaks it for some reason
(gdb) set {int}0x20000000 = 123
unexpected token
(gdb) print {int}0x20000000
unexpected token

//These "unexpected tokens" were perfectly valid one or two commands ago...

--- End code ---


edit:

gdb tries to autodetect the current language. The common casting syntax requires the current language to be set to "C".

For me it was not auto-detecting that it was debugging a C program.

For reference to the future reader the "show language" command will show the currently autodetected language in gdb
"set language c" is required to avoid "unexpected token" errors for set commands using the syntax that is shown in my posts.

thm_w:
Most of these functions work fine when using either stlinkv2 or jlink edu/pro, with visualgdb. I think the v2 was just a bit slower.

If you have a stlink clone you can convert it into a jlink and try that out:
https://www.eevblog.com/forum/testgear/alternative-to-segger-j-link-edu/
https://www.reddit.com/r/embedded/comments/165ls6k/would_you_recommend_a_segger_jlink_over_stlink/
http://www.mjblythe.com/hacks/2013/02/debugging-stm32-with-gdb-and-openocd/

But I'm sure this stuff should be working with gdb, maybe someone more familiar with command line debugging will comment.
Versions?

pcprogrammer:
Don't they all use the same GDB engine under the hood.

With the small target MCU's it is the debugging hardware that allows one to do certain things, and for this the interfaces like the ST-link implement a protocol to talk to the debugging hardware on the MCU side and the "server" on the other side. It could be that there are differences in this between the various interfaces.

I tend to use openocd to make the connection with the target, via the st-link v2 clones I have. This opens up a session with GDB and allows me to also connect to it from for instance netbeans. Have used it to inspect and modify variables and it works, but not al the time. Sometimes it states that a value has been optimized out, what ever that may mean.

It is my believe that the other tools implement the same protocol and do the same as openocd does in my case. The fact that similar things don't work like you expect with two different methods seems to indicate that the target hardware is not up to the task.

What might be a factor in play here is the host OS. I'm using Linux which is a closer match to GDB than Windows.

elektryk:

--- Quote from: pcprogrammer on January 22, 2025, 07:36:28 am ---Sometimes it states that a value has been optimized out, what ever that may mean.
--- End quote ---

That's normal, try -o0 optimization level and you will se every variable, there's also -og which was made for good debugging experience, but still some things may be optimized out.

https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html

SiliconWizard:
Debugging optimized code is not for the faint of heart. Often line numbers are all over the place and breakpoints do not correspond to what you think you set them to. Not a ton of fun.

Navigation

[0] Message Index

[#] Next page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod