The new Nucleo boards have a full ST-Link V2, which have the SWO connected. Why not use SWO for printf instead of UART?

SWO is automatically FIFO'ed, it's faster than most UART adapters, it's available on all the other ARM Cortex M microcontrollers, why not?

Granted, it is only TX and not RX but most people just use printf for tracing anyways. The UART can be used for communication with other devices such as XBee/GSM/Bluetooth/WiFi

I can write a library for this myself (I use SWO all the time on my own standalone projects) but it'll be great if it was default.

Hello Frank,

the idea behind UART using as a default console output is that on most target is connected to interface which then sends those data to usb. So swo can be used just for nucleo boards, not for the rest of them (not including option to use external debugger). Correct me if I am wrong.

How do you use that SWO for printing? ST does have any viewer like it's for Jlink created by segger? I would like to know, so share some details.

Regards,
0xc0170

ST Link Utility includes Serial Wire Viewer, which is what you are looking for

Yes, SWO can be used just for Nucleo boards. But all ARM Cortex M chips have SWO, The LPC flavored mbed can probably also use SWO after a firmware update to the magic mbed interface (maybe). The Freedom board cannot because they didn't connect the SWO pin to anything.

If you have a USB serial adapter, you can also use it as a SWO viewer, SWO is actually very similar to UART except using a much faster speed, for example, with JLink, I can push it to 6MHz, which most USB serial adapters do not support. The speed is incredibly important in timing critical debugging.

But I guess without firmware update it cannot be viewed on a regular serial terminal? And imo it is really a downside it is once way communication. Sure alot of printf is used for debugging, but the connection is also used extensively for getting data from a PC. Of course that you could also do specifically with a Serial object.

But especially since you want to keep it the same for all mbeds imo, I don't know if it would be good to change the default. I do think it is a nice option to have, so a library for it would definately be nice. Let it redirect stdio and just by including it you let all printf statements be redirected via SWO.

+1 for this request.

Remember, SWO is not just an application software printf style debugging, it is tied to ITM (instrumentation trace macrocell) which enables software & hardware trace with timestamp. i.e it allows you to debug OS and application events.

I wouldn't mind the 'one-way communication', so is Linux console. We don't have to change this to the default but an app-note on how to enable this would be very helpful for advanced developers.

Thanks

Hi, Just wanted to revive this thread and see if anyone attempted this.

Thanks

Here you go: http://developer.mbed.org/components/SWO-viewer/

Sweet! You might want to convert your library to a class which extends Stream. Once you do that you can do swo.printf() the same way you would do pc.printf().

Is there a equivalent viewer for the LPC1768?

Yes, extending Stream is a good idea. Will take a look at that when I find some time.

The LPC1768 mbed module interface chip firmware does not support the SWO pin (Pin is wired) and the SWD/SWO port is not directly accessible. It should work on hardware that provides external access to SWD/SWO. You could use the Segger J-Link hardware and SWO viewer.

OK, the lib now provides a Class SWO_Channel that implements Stream. Your code can use putc() and printf(). See here.

Great!