ST's gdb server, probe-rs, JLink, BlackMagic differences between them? - Page 1
Forum section: electronics / general

author: incf
author_rank: Frequent Contributor
timestamp: January 21, 2025, 10:01:23 pm
content: 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 exceptionsMonitor reset don't work reliablyWhen 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 workWould 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 searchedit: copying example here for visibilityCode://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 = 123unexpected token(gdb) print {int}0x20000000unexpected token//These "unexpected tokens" were perfectly valid one or two commands ago...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.

author: thm_w
author_rank: Super Contributor
timestamp: January 22, 2025, 12:39:14 am
content: 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?

author: pcprogrammer
author_rank: Super Contributor
timestamp: January 22, 2025, 07:36:28 am
content: 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.

author: elektryk
author_rank: Regular Contributor
timestamp: January 22, 2025, 08:35:29 am
content: Quote from: pcprogrammer on January 22, 2025, 07:36:28 amThat'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

author: SiliconWizard
author_rank: Super Contributor
timestamp: January 22, 2025, 09:07:03 am
content: 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.

author: pcprogrammer
author_rank: Super Contributor
timestamp: January 22, 2025, 09:43:56 am
content: Quote from: elektryk on January 22, 2025, 08:35:29 amThat will be it. I mostly have it set to -o3 to get maximum performance.Don't use the debugger that often. There are other techniques that can be used, like using a GPIO and an oscilloscope to check if an interrupted routine is used and how long it stays in it.

author: incf
author_rank: Frequent Contributor
timestamp: January 22, 2025, 11:55:02 am
content: Yes, under the hood all the GUIs use gdb plus a "gdb server" to connect to the debug probe. They often seem to send the same text commands that a terminal user would.I started tracing/printing the extended-remote protocol packets going between gdb and the stlink gdb server.By accident, I partially figured out one issue (it still does not work). In the case of setting memory and printing addresses with gdb and ST's gdb server, it turns out that ST's gdb server needs killed and restarted every single debug session. (and possibly every time the MCU is reset?) (this "fix" does not actually make the issue go away, it just delays it)gdb can start with the ability to print and set memory addresses (if any only if the debug server is restarted each debug session), but gdb looses the ability to set and print addresses once the "continue" command is issued.For some reason, communicating with the stlink gdb server changes the "mode/state" that gdb is in and cause it to start rejecting valid commands with "unexpected token" errors*Code://After connecting to stlink gdb server with target extended-remote :61234//This command is rejected and no packets related to this command are sent to the gdb server(gdb) set {int}0x20000000 = 123unexpected token(gdb) print {int}0x20000000unexpected tokenwhereas after restarting stlink gdb server it initially works, and then stops working after typing continueCode://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//It Works!(gdb) print {int}0x20000000$1 = 123//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//This breaks it for some reason(gdb) set {int}0x20000000 = 123unexpected token(gdb) print {int}0x20000000unexpected tokenit still does not work, but it is a small step in the right directiongdb 14.2 compiled from sourcestlink gdb server 7.9.0Footnote, tips for debugging stlink gdb server -> gdbin gdb set `set debug remote 1` - this will show the presence or lack of packets going from gdb to stlink gdb serverin stlink server's config.txt enable verbose mode and all logging and give it a valid path to write the logfile (not really needed if you "set debug remote 1" in gdb)search tags: STM32 gdb server unexpected token error, target remote, extended-remote

author: incf
author_rank: Frequent Contributor
timestamp: January 22, 2025, 12:42:55 pm
content: For completeness. With probe-rs it is just like with the st-link gdb server - except I don't even have to type in "continue" for it to start rejecting valid commands.Code://After connecting to probe-rs gdb server with target extended-remote :1337//This command is immediately rejected and no packets related to this command are sent to the gdb server(gdb) set {int}0x20000000 = 123unexpected token(gdb) print {int}0x20000000unexpected tokenYou can also send stlink gdb server packets via netcat while gdb is connected, but it only seems to work for read commands.Probe-rs does not respond at all to gdb extended-remote packets sent via netcat when gdb is connected.

author: peter-h
author_rank: Super Contributor
timestamp: January 22, 2025, 01:58:32 pm
content: Usually setting a breakpoint onasm "nop"or some such works fineI use -Og. I found -O3 does very little extra. -O0 makes the code some 30-40% bigger than -Og and in my case would overflow the FLASH area I have.A while ago I spent some time testing Segger stuff and could not see any point over ST's STLINK V3 - apart from the dynanic FLASH patching i.e. breakpoints in FLASH capability.But I use Cube IDE, not command line.

author: ajb
author_rank: Super Contributor
timestamp: January 22, 2025, 03:53:01 pm
content: There's an OSH project that implements the gdb server on the debug probe itself, calledBlack Magic Debug.I mostly debug with an IDE, but IME there is a notable difference in performance and reliability with J-link probes vs ST-LINKV2. Faster erase/program/verify cycles with the jlink make a big difference on large flash parts and it's also not prone to random debug session failures or needing to unplug/replug the USB connection multiple times a day like with the stlink. I don't know how much of that difference is down to better IDE support vs probe firmware vs drivers etc, but I've never regretted switching to the jlink stuff.

author: Siwastaja
author_rank: Super Contributor
timestamp: January 22, 2025, 04:25:20 pm
content: Welcome to the world of debugging. Some like to claim thatdebuggersare the magical solution with easy transparent access to the code that big boys use after they grow out of "printf debugging". Could not be further from the truth - for starters, you need to compile with -O0 or -Og or similar optimization level to make source-level debugging make any sense, which affects your program timing, performance, and size MUCH more than a simple "intrusive" logging layer ("printf debugging" without printf - e.g. saving ID numbers and values of interest to a ring buffer) of your own.Remember, with a debugger, you are really debugging the machine code, not C code. Great fit when you also write your program in assembly.It's not easy - it's not fast - it's not even supposed to be. But sometimes you need to do it. Just sometimes, not very often - for example it seems I open up gdb every two years. If you started doing it because you were told that Real Programmers use debuggers, you listened to wrong people. Invest that time into adding visibility, tracing, error checking etc. to your own code.

author: incf
author_rank: Frequent Contributor
timestamp: January 22, 2025, 05:03:37 pm
content: Quote from: ajb on January 22, 2025, 03:53:01 pmHas anyone used a Black Magic probe before?It sounds promising - a much better way to implement a debug probe from a technical perspective.I have to admit that am hesitant to spend a thousand dollars on a j-link when a black magic possibly might work.

author: uer166
author_rank: Super Contributor
timestamp: January 22, 2025, 05:11:21 pm
content: Quote from: incf on January 22, 2025, 05:03:37 pmI have: it could work flawlessly on one platform, and be utter garbage on another for reasons unknown (intermittent connections, dropping connection to debug session, no-connect, etc). I have had much better luck with the much cheaper ST-Link V3 overall. Instead of spending $1000 on a J-link, you can spend $35 on an ST-Link

author: peter-h
author_rank: Super Contributor
timestamp: January 22, 2025, 05:14:55 pm
content: QuoteTrue to some extent unless -Og is actually fine for your product, and it most certainly will be unless your CPU load is right on the margin.Some results on the finished project (11/2024), boot block (32k max) / main flash (1MB-32k max)-O0 15.3k / 623k-Og 10.3k / 440k <- used for development and production-O1 11.5k / 493k-Os 9.4k / 391k-Ofast 15.5k / 490kThe code difference between -Og and -O3 is minimal, because most of those optimisations are just GCC devs having nothing to do for the last 10 years, and moving stuff sideways, looking for and optimising increasingly esoteric cases

author: incf
author_rank: Frequent Contributor
timestamp: January 22, 2025, 05:31:24 pm
content: Code:Blackmagic for ST-Link AdaptersWith recent ST firmware, the ST-Link v2, ST-Link v2-1 and v3 can be used with Black Magic Debug App rather than having to flash this firmware to the adaptor.Running the BMP firmware on ST-Link v2 and ST-Link v2-1 provides:built-in gdb server on the dongleVCP on ST-Link v2. Access to VCP lines needs additional wires to the STM32F103C...Perhaps I do not need to purchase a probe. I might be able to reflash my ST-Link with BlackMagic firmware to see if it is less buggy.

author: ajb
author_rank: Super Contributor
timestamp: January 22, 2025, 07:41:24 pm
content: Quote from: uer166 on January 22, 2025, 05:11:21 pmHeh, I almost mentioned in my post that I have a BMP, but have not managed to use it successfully -- gdb couldn't seem to see the correct COM port number, which I chalked up to some sort of gdb-on-windows configuration thing. I'm sure it's a solvable problem, but it was easier to go back to the J-Link.Quote from: incf on January 22, 2025, 05:03:37 pmFWIW, the J-Link Base models start at half that, if their feature set will work for you, and they offer software upgrades to the higher level models if you need their features later. Still not cheap, of course. I'll admit I got the Plus model for 50% off a while ago, that made it a much easier sell!

author: Silenos
author_rank: Regular Contributor
timestamp: January 22, 2025, 07:49:38 pm
content: Stm32 debugging? Certain peripherals have state machines being triggered from the r/w bus operations, often susceptible to hidden time limits like usb or QSPI. And at least stlinks tend to spuriously read over large swaths of memory, even when not halted, so they cause "bugs". I could not find a solution to suppress this behavior, so I ditched debugging that time for years.

author: incf
author_rank: Frequent Contributor
timestamp: January 22, 2025, 07:53:18 pm
content: All I was looking to do was read and write a NVIC register from the debugger using its address (ie. without having modify my program to contain a pointer to it). HoweverCode:unexpected tokengot the better of me.

author: peter-h
author_rank: Super Contributor
timestamp: January 22, 2025, 07:55:12 pm
content: It isn't possible to properly debug USB or ETH because a breakpoint buggers up the extremely complicated "protocol". About the only thing one can do is to use a breakpoint to display variable etc values, and then you have to restart the target.The only way around this is a hardware trace buffer but I am not sure any current CPU had got that. 30+ years ago one had in circuit emulators (sometimes implemented in logic analysers) which had trace buffers and could do debugging without slowing down the target.

author: thm_w
author_rank: Super Contributor
timestamp: January 22, 2025, 10:23:13 pm
content: Quote from: incf on January 22, 2025, 05:03:37 pmjlink conversion of a stlink clone ($3) is free as I mentioned above. stlink clone can also be converted to bmp:https://wiki.philpem.me.uk/elec/stlink-blackmagicNeither will have the performance of a full jlink but it may not matter. Full jlink clone can be had for $20-30.

author: amymcneil
author_rank: Contributor
timestamp: January 23, 2025, 04:52:19 am
content: I'm using the Black Magic Probe (BMP) for my debug on ARM Cortex series processors. Mainly ST, but I've played with TI as well. The BMP probe speaks natively to GDB, simplifying how it all works. I've had no issues in the years that I've owned them. I like it much better than using the stlink device.

author: peter-h
author_rank: Super Contributor
timestamp: January 23, 2025, 07:46:04 pm
content: What does the BMP probe do that a STLINK does not? I had a look at their website but can't see clear advantages.Very occassionally, STLINK needs the USB cable pulled/inserted after some days. Also, rather more often, the target bombs out of debug mode and goes off free-running (I think we have some previous thread on whether target software is capable of crashing a debugger, and I don't mean by messing with the GPIO pins used for SWD). The SWV ITM console (a high speed UART basically, which the target can "printf" to, etc) is not all that reliable.

author: thm_w
author_rank: Super Contributor
timestamp: January 23, 2025, 11:17:14 pm
content: Quote from: peter-h on January 23, 2025, 07:46:04 pmBMP supports many other devices from other vendors. Hardware is a bit cheaper.If its just STM32 you are looking at, I don't think there is a major difference.

author: peter-h
author_rank: Super Contributor
timestamp: January 24, 2025, 08:45:01 am
content: I can't understand why anyone would want a cheaper debugger than an STLINK, which costs just a few tens of €. It's not worth even an hour of my time, and it will be a lot more than an hour if there is any config to do.Like I said, the pricey top end Segger models have value to those who want unlimited hardware breakpoints in FLASH, but that seems to be about it... apart from a cultural preference in Germany to buy German regardless of whether it is actually Chinese, or (in the case of some total junk I've just received) Turkish.

author: voltsandjolts
author_rank: Unknown
timestamp: January 24, 2025, 11:52:38 am
content: Quote from: peter-h on January 24, 2025, 08:45:01 amUnlimited hardware breakpoints in FLASH?Anyway, I use j-links because they provide freedom......to choose mcu vendor...to avoid vendor ide nonsense (see thread 'Is CubeIDE a buggy piece of crap' for someone who's grumpy about their ide)...to use os of my choiceI also appreciate......excellent reliability...RTT is excellent, particularly useful on mcu's without swo capability...ozone...a familiar toolset, and that saves time across different mcu projectsThere are likely open tools that achieve much of the above, but vendor tools are more about lock-in than freedom.

author: peter-h
author_rank: Super Contributor
timestamp: January 24, 2025, 04:44:09 pm
content: Breakpoints in FLASH are done by replacing code there with a jump instruction to some handler code.The Segger boxes must reprogram an entire FLASH block, which might be 16k, all the way to 128k, just to set one such breakpoint. It is fairly quick; I measured some 200ms or so for a 16k block.That is how debuggers always worked in the Z80 days, except that the code had to be in RAM so it could be modified. But one guy I knew implemented breakpoints in ROM, by copying a bit of the ROM into RAM and implementing it there. It was done by Hisoft in the 1980s. It involved complicated decoding of instructions etc. More here on a similar themehttps://www.eevblog.com/forum/microcontrollers/st-32f417-any-way-to-make-an-spi-sram-to-look-like-normal-ram/and it is a fair bit of work doing this with the arm32.I looked at Ozone and was not impressed with the clunky thing

author: voltsandjolts
author_rank: Unknown
timestamp: January 24, 2025, 05:28:20 pm
content: Quote from: peter-h on January 24, 2025, 04:44:09 pmI'm well aware of flash breakpoints, but you said "unlimited hardware breakpoints in FLASH", which is nonsensical. There are hardware breakpoints and there are flash breakpoints. You conflated two different mechanisms.Quote from: peter-h on January 24, 2025, 04:44:09 pmI find ozone to be very capable and prefer it to the ide debuggers I've tried.Also provides a familiar debugger interface for use across different vendor mcus.

author: peter-h
author_rank: Super Contributor
timestamp: January 24, 2025, 06:19:12 pm
content: A breakpoint is just an instruction to jump to some debugger code. You can have any number of such in FLASH.My guess is that when you disable such a breakpoint, Segger must be reprogramming the FLASH back to its original content. This could take some time, but the user will likely not notice, unless it is on the 128k block in which case the target won't restart for a second or so. Or maybe they are leaving the jumps in the FLASH and they all point to RAM?The use of this is only to have more than the 5 or so "hardware" breakpoints which an ST CPU might support on-chip.A proper hardware breakpoint carries a zero execution penalty, when disabled.

author: Siwastaja
author_rank: Super Contributor
timestamp: January 24, 2025, 06:34:37 pm
content: Quote from: voltsandjolts on January 24, 2025, 11:52:38 amI use STLINK v2 (because I happen to have one) with OpenOCD on Linux. Never used CubeIDE. I think this is the case withmostdebug probes available: only some rare ones would tie you to a vendor bullshit.I'm not sure if STLINK v2 satisfies your list of desired features (or reliability), though.

author: mwb1100
author_rank: Frequent Contributor
timestamp: January 24, 2025, 07:25:19 pm
content: My 2 or 3 cents on this:- if you are working with STMicro devices then an ST-Link V2 works great. Even the knock offs work well as long as they aren't DOA. ST-Link V3 also works great, but I found little reason to move past V2. That may have changed in the last year or 2. My understanding is that ST-Links can often be convinced to work with non-ST devices, but I have no experience with that.If you're working with STMicro devices, I think ST-Link is the way to go. Excellent bang for buck, especially the V2 knockoffs.- JLinks are great if you need to work with multiple different architectures, and the support provided by Segger is really good. Even for no older, longer supported devices you can often get useful help on the forum (but sometimes the answer for those is a simple "that version is no longer supported"). They are expensive but you can find good deals on eBay if you're patient, though those deals seem to be more infrequent lately. The knockoffs on eBay are not good in my experience, which was years ago before I realized what I bought were knockoffs. I'd avoid them. They had a tendency to crash and often would work only with specific version of the Segger software (I'm pretty sure this is often done intentionally by Segger to disable the clones). The stability of knockoffs might have improved in the past decade or so since I last tried them then threw them out.- in my experience, open source debuggers are often in a perpetual beta or even alpha state. They may or may not need a lot of tweaking and hand holding to work. Updates to the software may make things better - or worse. For me, even when open source debuggers worked they seemed prone to crashing. Again, this is something that may have improved in the last few years.

author: Siwastaja
author_rank: Super Contributor
timestamp: January 24, 2025, 07:27:55 pm
content: Quote from: mwb1100 on January 24, 2025, 07:25:19 pmThe implication here is just plain wrong. ST-Link has no limitation to STMicro devices at all. It has ST logo printed on the plastic, but otherwise it's a generic SWD probe like any other SWD probe. I use it to program Nordic Semiconductor nRF52 family, for example.And that's one of the benefits of the ARM MCU ecosystem: standardization of the CPU core, tools like compilers, and even debugging/flashing interfaces (SWD).

author: peter-h
author_rank: Super Contributor
timestamp: January 24, 2025, 08:15:02 pm
content: Not sure if the STLINK V2 does the SWV ITM debug console (a high speed UART, typically set up to route data to a printf() and useful for debugs which don't slow the target down much).I have always used the ISOL versions.

author: mwb1100
author_rank: Frequent Contributor
timestamp: January 24, 2025, 09:26:24 pm
content: Quote from: peter-h on January 24, 2025, 08:15:02 pmI have not used (or even yet heard of) that technology. This article by an ST employee,Using the ITM console for printf redirects and LWIP debug messages, doesn't mention what hardware is needed other than a Nucleo - I think most Nucleo's have ST-Link V2 on board?TheST-LINK/V2 datasheetmentions "SWD and serial wire viewer (SWV) communication support". I think "SWV" is the key along withITM (Instrumentation Trace Macrocell)support on the MCU.The technology (or at least the uses for it, maybe not the actual technology implementation) sounds similar toSegger's Real Time Transfer (RTT).

author: peter-h
author_rank: Super Contributor
timestamp: January 24, 2025, 10:03:35 pm
content: It is a great feature, though I have used it only with STLINK V3 debuggers.The output pops up in Cube IDE's SWV debug window.It works via the SWD interface. No extra wires are needed. The 32F4 CPU has hardware support for it. It is handy for debugging where you cannot set a breakpoint for some weird reason e.g. code running out of RAM after having been copied there from FLASH e.g. a boot loader. I never found a way to set a breakpoint on code running in RAM; presumably it is possible if you know the address where you want to set it.

author: thm_w
author_rank: Super Contributor
timestamp: January 24, 2025, 10:16:57 pm
content: Quote from: Siwastaja on January 24, 2025, 07:27:55 pmWon't work with SAM D21 on stock FW, but you are right, looks like it works with more devices than I expected:https://electronics.stackexchange.com/questions/250664/can-i-use-st-link-programmer-for-non-st-chips

author: mwb1100
author_rank: Frequent Contributor
timestamp: January 24, 2025, 11:26:10 pm
content: Quote from: Siwastaja on January 24, 2025, 07:27:55 pmThe implication is that I have no experience using ST-LINK on non-ST devices.Actually, it's not even an implication. Just prior I stated:Quote

author: voltsandjolts
author_rank: Unknown
timestamp: January 25, 2025, 10:18:14 am
content: Question:If your target mcu doesn't have an SWO pin, and it only has SWDIO and SWDCLK, is Segger RTT the only option to get 'SWV' like functionality?

author: Siwastaja
author_rank: Super Contributor
timestamp: January 25, 2025, 11:36:40 am
content: Quote from: thm_w on January 24, 2025, 10:16:57 pmInteresting. Explanation (fromhttps://electronics.stackexchange.com/questions/250664/can-i-use-st-link-programmer-for-non-st-chips)QuoteSo more to do with a really esoteric flash programming interface on SAMD21 than ST-Link; so it's more like a feature limitation than compatibility issue per se, just that SAMD21 requires a special feature for flashing others do not require.

author: peter-h
author_rank: Super Contributor
timestamp: January 25, 2025, 01:49:46 pm
content: This is my SWV ITM codeCode:/** Copied here from core_cm4.h.\brief ITM Send Character\details Transmits a character via the ITM channel 0, and\li Just returns when no debugger is connected that has booked the output.\li Is blocking when a debugger is connected, but the previous character sent has not been transmitted.\param  ch Character to transmit.*/static void ITM_SendChar_2 (uint32_t ch){if (((ITM->TCR & ITM_TCR_ITMENA_Msk) != 0UL) && /* ITM enabled */((ITM->TER & 1UL ) != 0UL) ) /* ITM Port #0 enabled */{while (ITM->PORT.u32 == 0UL){__NOP();}ITM->PORT.u8 = (uint8_t)ch;}return;}// This sends debug output to the SWV ITM / SWD debug interface// was: __io_putchar(int ch) - this was for the old ST-supplied printfint _putchar (int ch){ITM_SendChar_2(ch);return ch;}// Function which sends data to the ITM debugger port. Works without needing any stdlib etc code, and// does not need interrupts. Fast output, megabits/sec.// Needs CRLF as appropriate.void debug_puts(char* str){int i=0;while (str!=0x00){ITM_SendChar_2((uint32_t) str);i++;}}It drives what looks like a simple UART.

author: voltsandjolts
author_rank: Unknown
timestamp: January 25, 2025, 02:06:46 pm
content: Which sends out through the SWO pin, right?

author: mwb1100
author_rank: Frequent Contributor
timestamp: January 25, 2025, 03:49:56 pm
content: I don't know about SWV (though I'm pretty sure it relies on SWO based on the diagram on ARM'sAbout the Serial Wire Viewerpage), but Segger says this about RTT:Quote from:https://www.segger.com/products/debug-probes/j-link/technology/about-real-time-transfer/

author: peter-h
author_rank: Super Contributor
timestamp: January 25, 2025, 04:48:46 pm
content: QuoteAccording to this, yeshttps://www.eevblog.com/forum/microcontrollers/from-pic-to-stm32/msg5164905/#msg5164905Wek knows his stuffhttps://www.eevblog.com/forum/microcontrollers/stm32f417-any-reason-why-a-min-pclk2-speed-is-required-for-ethernet-to-work/msg3573961/#msg3573961Here it seems to confirm ithttps://www.eevblog.com/forum/microcontrollers/10-pin-debug-connector-and-stlink-v3-isol-not-reliable/msg3564782/#msg3564782It sounds like SWO is not provided on a standard STLINK V2. Some people added SWO to this debugger.Maybe Segger implement the UART differently, and poll it for data via SWIO.

author: voltsandjolts
author_rank: Unknown
timestamp: January 25, 2025, 05:28:11 pm
content: With Segger RTT your firmware just does sprintf / writes data to a RAM buffer.Segger RTT software finds the RAM buffer and reads it out continuously through SWDIO while your firmware is running.With multiple RAM buffers you have multiple channels / terminal screens on your PC.You can send data to the mcu also, much like a uart.Very useful when you have no SWO pin.Is there another debug tool which provides a similar feature?

author: SiliconWizard
author_rank: Super Contributor
timestamp: January 25, 2025, 10:46:04 pm
content: SWO used this way is just like an UART, so you can connect it to any UART-to-USB adapter if your "debug probe" doesn't support it. You'll just have to set the right baudrate on the host side.

author: peter-h
author_rank: Super Contributor
timestamp: January 26, 2025, 08:05:37 am
content: Interesting. I had the impression it was a synchronous UART (USART) of some sort. But maybe not; maybe it is completely separate from the SWD debugging stuff.

author: voltsandjolts
author_rank: Unknown
timestamp: January 27, 2025, 02:18:58 pm
content: Quote from: voltsandjolts on January 25, 2025, 05:28:11 pmOK, to answer my own question, RTT seems to be supported in probe-rs, Open-OCD and BMP (as compile-time option):https://github.com/probe-rs/rtt-targethttps://black-magic.org/usage/rtt.htmlhttps://openocd.org/doc/html/General-Commands.html#Real-Time-Transfer-_0028RTT_0029Would be interested to hear your thoughts on stability of any of these, if you've tried them.

author: bson
author_rank: Unknown
timestamp: January 28, 2025, 10:02:59 pm
content: set *(int*)0x200000 = 0x123p/x *(int*)0x200000

author: incf
author_rank: Frequent Contributor
timestamp: January 28, 2025, 10:25:16 pm
content: Quote from: bson on January 28, 2025, 10:02:59 pmI get "unexpected token" (and with `set debug remote 1` I can confirm that it's not sending anything to the debug server for this particular command, although plain variables and registers work just fine)Code:(gdb) set (int*)0x2000000 = 0x123unexpected token(gdb) set *(int*)0x2000000 = 0x123unexpected token(gdb) p/x *(int*)0x2000000unexpected token(gdb)

author: wek
author_rank: Frequent Contributor
timestamp: January 29, 2025, 09:18:00 am
content: I'd say, the problem is that you build gdb yourself from scratch.Not that I have any experience with this, but I've seen enough open source projects to understand that details do matter and that there's enough badly documented or completely undocumented "magic" in building them to make this a major PITA.Try some of the"known good" builds by ARM(arm-none-eabi target).JW

author: incf
author_rank: Frequent Contributor
timestamp: January 29, 2025, 11:42:07 am
content: Quote from: wek on January 29, 2025, 09:18:00 amI've tried several different builds. I don't think many people use features like the set command.

author: peter-h
author_rank: Super Contributor
timestamp: January 29, 2025, 02:57:34 pm
content: QuotePretty much sums up the open source scenehttps://www.eevblog.com/forum/programming/a-rant-about-lack-of-support-on-open-source-software-or-anything-else-actually/

author: bson
author_rank: Unknown
timestamp: January 31, 2025, 10:20:28 pm
content: Quote from: incf on January 29, 2025, 11:42:07 amYes we do. Every time we change a value from the debugger we use it.The problem isn't the set command, it's that your build of gdb doesn't recognize your code as being C, so doesn't parse C expressions. Remember that gdb supports many languages and auto detects it by default from the source file. If just looking at some binary without debug info it might not have a clue. You can explicitly set the language with 'set language'. Seehttps://sourceware.org/gdb/current/onlinedocs/gdb.html/Languages.html#LanguagesOf course, there can also be a build dependency problem.

author: incf
author_rank: Frequent Contributor
timestamp: January 31, 2025, 11:02:30 pm
content: Quote from: bson on January 31, 2025, 10:20:28 pmI'm ecstatic, this is the solution to 30+% of my problem(s).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"set language c" is required to avoid "unexpected token" errors for set commands.Not sure what the syntax for setting would be if the language was something else like "asm"Side tangent: this link has the syntax for casting in Rusthttps://stackoverflow.com/questions/55457338/gdb-cast-depends-on-the-language-compiledfor those suitably inclined.

author: kevinpt
author_rank: Contributor
timestamp: February 04, 2025, 09:20:06 pm
content: Quote from: thm_w on January 23, 2025, 11:17:14 pmHardware wise, the BMP has bus transceivers providing some isolation of the probe and allowing 1.5V - 5V IO (wider span than STLinks support). Software wise, the BMP firmware can speak JTAG as well as ARM SW-DP.You get the benefit of fewer hassles with direct GDB access. OpenOCD, for instance, has a misfeature where it leaves the processor in debug mode after you program an image and detach. If you have any code detecting an attached debug probe it will not behave as expected. The BMP firmware handles this correctly.

author: mwb1100
author_rank: Frequent Contributor
timestamp: February 05, 2025, 12:10:19 am
content: Quote from: kevinpt on February 04, 2025, 09:20:06 pmJust a nitpick: ST-LINK also supports JTAG.