use SWO & Segger RTT for logging.

[hathach]

Feature Description Current logging with uart is only viable within the main task. SWO (on supported board) and RTT is much faster and even can be used within ISR. Which is handy to debug/add new mcu.

Note: both requires swd debugger. RTT is specific to jlink, swo is standard ARM but not all board/mcu support SWO.

• https://www.segger.com/products/debug-probes/j-link/technology/about-real-time-transfer/

[pigrew]

RTT is a really great idea. It seems better than SWO.

It looks like Segger even has a firmware to flash onto STLinks: https://www.segger.com/products/debug-probes/j-link/models/other-j-links/st-link-on-board/

[hathach]

RTT is a really great idea. It seems better than SWO.

It looks like Segger even has a firmware to flash onto STLinks: https://www.segger.com/products/debug-probes/j-link/models/other-j-links/st-link-on-board/

Yeah, right, most stlink/lpclink debugger is compatible with jlink firmware. You could just flash it on those and turn them into jlink

[hathach]

impelented, easier than thought.

[hathach]

with SWO, tested with feather_nrf52840, may not be support by all board (some doesn't route SWO). But it is handy and even faster than RTT with dedicated pin out. I am quite sure it can be used within ISR. Since it is standard ARM debug pin, it can be supported on other debugger than jlink. Maybe stlink and/or openocd adaptor can do swo(swv) without the need to flash jlink firmware as well !!! Text copied from example readme

By default log message is printed via on-board UART which is slow and take lots of CPU time comparing to USB speed. If your board support on-board/external debugger, it would be more efficient to use it for logging. There are 2 protocols: 

- `LOGGER=rtt`: use [Segger RTT protocol](https://www.segger.com/products/debug-probes/j-link/technology/about-real-time-transfer/)   
  - Cons: requires jlink as the debugger.
  - Pros: work with most if not all MCUs
  - Software viewer is JLink RTT Viewer/Client/Logger which is bundled with JLink driver package.
- `LOGGER=swo`: Use dedicated SWO pin of ARM Cortex SWD debug header.
  - Cons: only work with ARM Cortex MCUs minus M0
  - Pros: even faster than RTT, and should be compatible with hardware and software debugger that support SWO.
  - Software viewer is JLink SWO Viewer which is also bundled with JLink driver package.

$ make LOG=2 LOGGER=rtt BOARD=feather_nrf52840_express all
$ make LOG=2 LOGGER=swo BOARD=feather_nrf52840_express all

[hathach]

implemented

[pigrew]

@hathach,

Based on the RTT docs, RTT should be faster than SWO?

(The comment above says the opposite)

(I think SWO is more like a UART, and data is transmitted in a blocking mode?)

[hathach]

@hathach,

Based on the RTT docs, RTT should be faster than SWO?

(The comment above says the opposite)

(I think SWO is more like a UART, and data is transmitted in a blocking mode?)

really, how can a software protocol could run faster than a one with dedicated pin. sigh !!! I will remove that from swo pros then. Shame on it :smile:

[pigrew]

It's brilliant.

The CPU copies the string to a dedicated circular buffer in SRAM, and JTAG is used to read that memory through the debug interface.

SWO is effectivly the same as UART, and loops around a putch() like interface.

(Or at least that's my understanding)

[hathach]

@pigrew Yeah It is like UART, but I think the debug core run the transmission without the need of CPU, and debug core also has its own buffer scheme as well. Jlink RTT viewer will periodically poll for the RTT data while SWO will just pushing it out to the software server. but I am not sure. Let's just remove it just to be safe :D .

Btw swo seems to be routed on the stm32f411 discovery board to pin PB3. It can be useful if st provide some sort of viewer for it, so that user don't have to flash jlink firmware. I will check it out the next time I work with stm32 board.

https://www.st.com/resource/en/user_manual/dm00148985-discovery-kit-with-stm32f411ve-mcu-stmicroelectronics.pdf

[duempel]

@hathach I was just searching on how to use your newest SWO implementation with my ST-Link and found this application note: https://www.st.com/resource/en/application_note/dm00354244-stm32-microcontroller-debug-toolbox-stmicroelectronics.pdf In chapter 7.3 it's explained how to use SWO as printf(). They mention that ST-LINK utility can be used for this, in case the IDE does not use an embedded SWV. (Shown in figure 47) It should be also possible without the use of J-Link firmware.

[pigrew]

It looks like the ITM FIFO size is 10 bytes, so it has to block if sending more than that?

The ETM block world have more than that, but it's only in higher-end MCU.

I tried using semihosting on TI CC2650, but it was stupidly slow.... Or maybe I got something wrong.

[hathach]

@hathach I was just searching on how to use your newest SWO implementation with my ST-Link and found this application note: https://www.st.com/resource/en/application_note/dm00354244-stm32-microcontroller-debug-toolbox-stmicroelectronics.pdf In chapter 7.3 it's explained how to use SWO as printf(). They mention that ST-LINK utility can be used for this, in case the IDE does not use an embedded SWV. (Shown in figure 47) It should be also possible without the use of J-Link firmware.

Ah thanks yeah, there is SWO viewer for stlink, probably for windows only. I didn't have much success with stlink app on linux. It complains about java jre although I install several of them. Maybe it is better now.

It looks like the ITM FIFO size is 10 bytes, so it has to block if sending more than that? The ETM block world have more than that, but it's only in higher-end MCU. I tried using semihosting on TI CC2650, but it was stupidly slow.... Or maybe I got something wrong.

printf with semihost is different than with SWO and yet that one is painfully slow :smile:

Update: @pigrew ah yeah, I just do a bit of googling, seems like RTT is still faster. I learn new thing today. just removed that mention in the latest push.

[hathach]

Update: sadly stlink utilities is windows only, there is also an python to parse and print out swo for linux https://github.com/karlp/swopy with a great article https://false.ekta.is/2013/12/using-swo-swv-console-with-stlink-linux-stm32-part1/

[hathach]

@henrygab may be interested to this issue as well.

[henrygab]

Definitely interested!

I had (_non-merged_) PRs that enabled RTT and SysView in the Adafruit_nRF52_Arduino repo via [PR 423](https://github.com/adafruit/Adafruit_nRF52_Arduino/pull/423) and [PR431](https://github.com/adafruit/Adafruit_nRF52_Arduino/pull/431). I still need the technology, and @hathach just recently approved the PRs to make it relatively easy to at least enable SysView separate from using debug level 3 on those boards via [PR 454](https://github.com/adafruit/Adafruit_nRF52_Arduino/pull/431) and [PR 469](https://github.com/adafruit/Adafruit_nRF52_Arduino/pull/431).

---

I'm surprised that this is going into the 'TinyUSB' library, as it's not really USB-related. I'll take a look ... I'm excited to see RTT (and/or SWO) enabled on multiple boards!

[henrygab]

original post

After review and some thought, I would recommend marking this feature as **_experimental_** within TinyUSB, at least to allow discussion and consideration of if debug output selection should be split into a separate library. Otherwise, you may be causing long-term difficulties and higher maintenance costs.

---

## NICELY DONE! I'm also excited to see the value of SWO and RTT being discovered!

[hathach]

TinyUSB source doesn't change at all, it only calls tu_printf for logging. The logger rtt/swo/uart retarget is handled at application level.

https://github.com/hathach/tinyusb/blob/master/hw/bsp/board.c

[hathach]

Definitely interested! I'm surprised that this is going into the 'TinyUSB' library, as it's not really USB-related.

I'll take a look ... I'm excited to see RTT (and/or SWO) enabled on multiple boards!

IT is not usb related, therefore it is not part of the stack sources, it just make debugging with builtin example easier :)