Standalone SWO

SWO (Single Wire Output) in ARM cores is probably one of the most under-used features. Which is surprising, because SWO can be very useful. In a nut shell: SWO is a single wire output pin/signal channel which can provide lots of different data, like PC sampling for coverage information, interrupt tracing data or ‘uart-like’ text packets.

SWO output from application

Using SWO

Despite its usefulness, using SWO can be challenging: it requires a physical pin, support in the debugger, plus despite it is a standard ARM feature, using it might be different for each MCU because of clocking. Tool vendors try to make things easier with ‘automatic’ setup of all the SWO hardware registers. That’s OK if that works, but unfortunately this is not always the case. In addition to that it conflicts with SWO configuration and settings done in the application. One might argue that the application should not touch SWO: but handling SWO in the application is my preferred way as that way I know what is going on. And I don’t have to rely on some ‘magic code’ from the tool vendors. Handling SWO in the application and to rely on the tool vendor ‘black box’ configuration allows me to use SWO without any external tools involved: so I can use the Saleae or Sigrok tools to capture the data and process it, without the interference of other tools.

Standalone SWO Viewer

After some debates and discussions, I’m very happy to report that SEGGER has added a ‘standalone’ SWO functionality to their SWO viewer V7.22 and later. From the release notes:

[SWOViewer]: Added command line option “-swoattach <OnOff>” that disables all J-Link side initialization of SWO and relies on the target application to perform SWO init.

SEGGER V6.22 Release Note

πŸ’‘ Note that I have to use the V6.22b, as at least in the actual V7.50b (both 32bit and 64bit) the feature seems not to work any more.

With this, the SEGGER SWOViewer can be used in combination with application level SWO setup and configuration. How this configuration works: check SWO with ARM Cortex-M33 which describes the McuSWO module which gives you access and configuration of the SWO feature across ARM cores.

LPC55S16-EVK Board with Saleae logic analyzer


Here is how to use it, using the example presented in SWO with ARM Cortex-M33.

Start the SWO viewer with the following command line (see for the list of options):

JLinkSWOViewerCL -swoattach on -swofreq 64000 -device LPC55S16 -itmport 0x1

This starts the JLinkSWOViewer in standalone mode:

Standalond SWO Viewer

This example above uses the stimulus port 0x1. Note that for SWO ‘printf’ this goes to the stimulus port 0.

The application can now use SWO. I’m using for example the McuSWO:

McuSWO help

The application has configured SWO with a baud of 64k baud for testing purposes:

For sending text I’m going to use the stimulus port 0x0:

JLinkSWOViewerCL -swoattach on -swofreq 64000 -device LPC55S16 -itmport 0x0

Using the console I can send data over the SWO pin:

Sending Data over SWO


It is fine if tools configure SWO. I wish that the settings and changed applied by the tools would be more transparent. For the case where the application needs to set up SWO, SEGGER has now added an ‘attach’ option which does not tamper with the application SWO configuration. With this a ‘standalone’ SWO usage can be realized.

πŸ’‘ Update: the MCUXpresso IDE 11.5.0 has now added standalone SWO functionality too :-).

Happy wiring πŸ™‚

7 thoughts on “Standalone SWO

  1. Interesting. One of the first reasons I came across your blog was reading how to setup SWO within mcuxpresso a couple years ago. I think it was using a 1064evk board.

    In any case, you are absolutely right, it has not been an easy thing to get going and relying on the tools to automagically set it up hasnt been great either.

    I no longer have issues now that I use SES but I occasionally use other tools with my Segger so this will be good to know.

    many thanks.

    Liked by 1 person

    • Hi John,
      you might run into issues with any tool which wants to setup SWO directly, especially for newer devices. Vendors do not have all the devices at hand, and it is likely that there are always some hidden changes in newer devices e.g. for the clocking, resulting in ‘blind’ implementation not working: my experience is that if it has not been verified non actual hardware, it might not work or is just luck. Even with SES as I don’t think they have the bandwidth to test things with the number of devices out there. The good thing is that they are usually pretty fast in fixing things fast.

      Liked by 1 person

      • Yeah and I think that was the case for me initially, it was not reliable! but since I’m only concerned with the IMXRT10xx family, Segger seems to have good support for it now. They have addressed several issues for me., I know for a fact they have EVK boards so as to replicate issues and recently they made changes to their software and firmware to better (aka reliably) support mcu’s like the imxRT which have complex boot requirements complicated by internal 1st stage bootoaders (bootrom) and of course security. SWO setup is easy now and trace and profiling works reliably.

        Liked by 1 person

What do you think?

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.