ST-Link SWV data stream is not always reliable

[CTapp.1]

I'm using an ST-Link V2 to stream (over ITM) code coverage data from an STM32G4 via GDB Server on a PC.

This works fine most of the time (for many days), but the data stream sometimes drops some of the data. Adding a delay between calls to ITM_SendChar() on the target stops the data loss, so it appears as if the ST-Link and/or its driver are sometimes unable to keep up.

I'm not exactly sure how long the delay needs to be as I am not able to use timers to generate it (as this would invalidate the testing), so I've been using a simple volatile access loop:

for ( volatile unsigned delay=0; delay<500; ++delay );

 Based on timings and data length, that is introducing delays of about 20uS between the calls.

It seems strange to me that it works without the delay most of the time, especially as the target and PC are both running the same software at the time.

Is this a known limitation of the ST-Link that would be fixed with a "professional" trace probe?

 

[Tesla DeLorean]

It's definitely got limited bandwidth and buffering. 

The ST-LINK/V3 will likely be more robust, as would a J-LINK. You might try the J-LINK OB firmware on the V2. Or high baud rate VCP.

 

[CTapp.1]

Thanks for the info.

I am working on a custom board, so I can't use the J-Link OB firmware. I'll see if I have an eval board around that I can try it with though.

I think my best option is to try an ST-Link/V3 as they support a much higher clock rate.

[Tesla DeLorean]

More powerful MCU (F723) and High-Speed USB

I don't recall if the J-Link OB will go onto the stand-alone V2, or only the V2-1's. Nevermind.. seems like just the latter

https://www.segger.com/products/debug-probes/j-link/models/other-j-links/st-link-on-board/

[Pavel A.]

>  Adding a delay between calls to ITM_SendChar() 

By the way, ITM_SendChar writes only 8 bits at once. Writing 32 bits at once may help optimizing things (better utilize the ITM FIFO or whatever) and save on software overhead (loop while ITM is busy).

[CTapp.1]

Thanks, I had considered that, but it's easier to use 8 bit as the stream is basically text.

Even with delays added to stop the data loss, the solution is still about 16 times faster than what was provided by the tool vendor (which works when SWV is not available).