Skip to main content
Maxim Blinov
Maxim Blinov
Associate
March 14, 2019
Question

TrueSTUDIO SWV console frequently drops printf logs

  • March 14, 2019
  • 1 reply
  • 935 views

Hi everyone,

I recently read a lot of articles on the subject of SWD, SWO, and using SWV for debugging purposes. I configured my TrueSTUDIO project as stated by the article[1][2], however I have the following problem:

When I send strings over SWD by re-implementing "_write" over printf[2], the SWV Viewer console sometimes corrupts the message, and sometimes fails to receive it.

However, when I use the ST-LINK Utility to read the SWV output, I notice that everything is transmitted perfectly, with no glitch characters, and no dropped strings.

Unfortunately I am not sure as to what could be misconfigured, or the problem. I've attached some pictures to show the pertinent information (the test code, SWV log, and so on).

I have checked that the frequency is set correctly (64MHz).

Other information:

Device: Nucleo-64 F103RB

TrueSTUDIO: Version 9.2.0

ST-Link utility: V4.2.0.0

Firmware version: V2.J33.M25 STM32 Debug+Mass storage

[1]: http://blog.atollic.com/cortex-m-debugging-introduction-to-serial-wire-viewer-swv-event-and-data-tracing

[2]: http://blog.atollic.com/cortex-m-debugging-printf-redirection-to-a-debugger-console-using-swv/itm-part-1

Images:

https://imgur.com/a/8SbCdq3

This topic has been closed for replies.

1 reply

Maxim Blinov
Maxim BlinovAuthor
Associate
March 14, 2019

I've been testing around with some of the options, and discovered that by disabling the "EXETRC: Trace exceptions" checkbox (found under the SWV Viewer options window) drastically improves the logging behaviour: With a delay of 10ms, only the very occasional printf statement is lost, and it is quite rare. At 100ms delay, not a single printf statement is lost.

I think that the channel was simply overflowing with data due to having to both send exception trace information and printf data at the same time.

Still, I'm not sure that I'm satisfied with a 10ms delay occasionally overflowing the channel (SWD runs at 2MHz, after all). But its better than what was before.

Terms & ConditionsAccessibility statement