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

[peter-h]

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 theme
https://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

[voltsandjolts]

Breakpoints in FLASH are done by replacing code there with a jump instruction to some handler code.

I'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.

I looked at Ozone and was not impressed with the clunky thing

I 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.

[peter-h]

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.

[Siwastaja]

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 choice

I use STLINK v2 (because I happen to have one) with OpenOCD on Linux. Never used CubeIDE. I think this is the case with most debug 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.

[mwb1100]

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.

[Siwastaja]

  - if you are working with STMicro devices then an ST-Link V2 works great.

The 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).

[peter-h]

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.

[mwb1100]

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 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?

The ST-LINK/V2 datasheet mentions "SWD and serial wire viewer (SWV) communication support".  I think "SWV" is the key along with ITM (Instrumentation Trace Macrocell) support on the MCU.

The technology (or at least the uses for it, maybe not the actual technology implementation) sounds similar to Segger's Real Time Transfer (RTT).

[peter-h]

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.

[thm_w]

The 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.

Won'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

[mwb1100]

  - if you are working with STMicro devices then an ST-Link V2 works great.

The implication here is just plain wrong...

The 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:

My understanding is that ST-Links can often be convinced to work with non-ST devices, but I have no experience with that.

[voltsandjolts]

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?

[Siwastaja]

Won't work with SAM D21

Interesting. Explanation (from https://electronics.stackexchange.com/questions/250664/can-i-use-st-link-programmer-for-non-st-chips )

AFAIK the problem is in half word (16-bit) write to NVMCTRL->CTRLA register. STLink does not implement half word memory access and OpenOCD emulates is as two byte operations. Unfortunately CTRLA register comprises from key and command an have to be written atomically. If STLink writes two bytes, NVM controller sets PROGE bit in STATUS: "An invalid command and/or a bad keyword was/were written in the NVM Command register"

So 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.

[peter-h]

This is my SWV ITM code

Code: [Select]


/*
 * 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 [in]     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[0U].u32 == 0UL)
    {
      __NOP();
    }
    ITM->PORT[0U].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 printf
int _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[i]!=0x00)
{
ITM_SendChar_2((uint32_t) str[i]);
i++;
}
}


It drives what looks like a simple UART.

[voltsandjolts]

Which sends out through the SWO pin, right?

[mwb1100]

I don't know about SWV (though I'm pretty sure it relies on SWO based on the diagram on ARM's About the Serial Wire Viewer page), but Segger says this about RTT:

Q:  Can this also be used on targets that do not have the SWO pin?

A:  Yes, the debug interface is used. This can be JTAG or SWD (2pins only!) on most Cortex-M devices, or even the FINE interface on some Renesas devices, just like the Infineon SPD interface (single pin!)

[peter-h]

Which sends out through the SWO pin, right?

According to this, yes
https://www.eevblog.com/forum/microcontrollers/from-pic-to-stm32/msg5164905/#msg5164905

Wek knows his stuff
https://www.eevblog.com/forum/microcontrollers/stm32f417-any-reason-why-a-min-pclk2-speed-is-required-for-ethernet-to-work/msg3573961/#msg3573961

Here it seems to confirm it
https://www.eevblog.com/forum/microcontrollers/10-pin-debug-connector-and-stlink-v3-isol-not-reliable/msg3564782/#msg3564782

It 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.

[voltsandjolts]

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?

[SiliconWizard]

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.

[peter-h]

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.

[voltsandjolts]

With Segger RTT ...

Is there another debug tool which provides a similar feature?

OK, 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-target
https://black-magic.org/usage/rtt.html
https://openocd.org/doc/html/General-Commands.html#Real-Time-Transfer-_0028RTT_0029

Would be interested to hear your thoughts on stability of any of these, if you've tried them.

[bson]

set *(int*)0x200000 = 0x123
p/x *(int*)0x200000

[incf]

set *(int*)0x200000 = 0x123
p/x *(int*)0x200000

I 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: [Select]

(gdb) set (int*)0x2000000 = 0x123
unexpected token
(gdb) set *(int*)0x2000000 = 0x123
unexpected token
(gdb) p/x *(int*)0x2000000
unexpected token
(gdb)

[wek]

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

[incf]

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

I've tried several different builds. I don't think many people use features like the set command.