Trace SWO output in non-debug mode

[VMuth.3]

I've successfully configured the SWO trace output and read the prints in STM32CUBE IDE -> SWV ITM Data Console. I see these prints are working in debug mode. Do STM32 chip (ARM Core) prints the same in non-debug mode (application mode)? If yes, how to do it?

I've not routed UART pins to any test points for debug print. So, thinking if SWO will help to get the debug message both in debug and production

[KnarfB]

> Do STM32 chip (ARM Core) prints the same in non-debug mode (application mode)?

Yes. You can check it by building a release config in STM32CUBE IDE.

So you can instument your production code with SWO tracing.

The STM32 ST-LINK utility (STSW-LINK004) can read the output without starting a debug session.

[Nikita91]

I have always believed that the SWO should be initialized from outside the MCU, most often by a debugger. If it is possible to use it by initializing it by the MCU itself I am very interested.

On the other hand how to use ST-LINK utility to receive and display the characters emitted on SWO?

[Tesla DeLorean]

Posted codes on doing this in the past, and for the H7 where it gets a little more complex as the pin funnels data from multiple core. Will dig up an example.

The real gotcha here is making sure the bit rate divider properly matches the Core Clock vs the SWD Debugger's Clock. The old ST-LINK/V2 this was assumed to be 2 MHz, where as the V3 can be 15 or 24 MHz

Also note that on several L0 parts the SWCLK/SWDIO can be a USART (LPUART1 as a I recall), which can be helpful for monitor/console diagnostics if these pins are exposed to test/probe point in the design and available fixturing.

Segger has debug scripts, and I've seen others, showing the SWV/SWO setup registers/sequences

[Tesla DeLorean]

The H7 one, bottom of thread

https://community.st.com/s/question/0D50X00009XkWZQSA3/no-traceswo-output-on-stm32h7xx

Need to dig up the L4 (CM4 variant)

[Tesla DeLorean]

About 1/4 way down this blog is an example I quickly fished out of Google, you'll need to set the baud rate higher as ST-LINK's are up in the MHz

https://mcuoneclipse.com/2016/10/17/tutorial-using-single-wire-output-swo-with-arm-cortex-m-and-eclipse/

[Nikita91]

It seems to me that this does not answer about the post which is to use the SWO functionality without a connected debugger. In other words being able to send characters on SWO after a power-up when there is no debugger connected to the MCU.

After reading multiple reference manuals it appears that:

- SWO and TDO use the same pin

- On power-up the SWJ-DP is in JTAG mode.

- To use SWO, you must switch the SWJ-DP to SWD mode

- You can switch to SWD only from the outside by shaking the SWD and SWC pins (There is no register to do this from inside the MCU).

One solution mentioned somewhere is to connect 2 GPIOs of the MCU to SWD and SWC and to toggle these GPIOs to switch to SWD mode.

Who knows what to send on SWD and SWC to change the mode of the SWJ-DP to SWD (at least on M3 / M4)?

Has anyone tried:

https://developer.arm.com/documentation/ddi0316/d/functional-description/swj-dp/swd-and-jtag-selection-mechanism

[Tesla DeLorean]

I attempted to answer the "If it is possible to use it by initializing it by the MCU itself I am very interested.", from the perspective of what the debuggers usually set up, it can access the MCU side registers, registers on the scan chain probably less accessible. The register side is usually scripted in the debugger software, and often hidden from view/inspection.

The old ST-LINK Utilities had a SWV-Viewer, and that in some circumstances needed MCU side configuration.

For SWD level mechanics you might be better off to looking at Open OCD, Black Tragic (with an M), CMSIS-DAP or other open source materials, companies like Segger have access to "For Debugger Developers" type documentation from ARM

You seem to want to be "A Debug Pod", and I'm not sure of the "value" of doing that over just using COTS hardware that achieves the same ends.

[Nikita91]

I don't want to build a "debug pod", i want not to have to use a probe and an external software to be able to emit traces on SWO.

For debugging with a probe, no problem: a cheap FTDI cable on SWO allows you to have low intrusive traces at 12 Mbits/s (there is a small FIFO in ITM). Its different from SWV.

But on site I cannot connect my FTDI cable and record the traces: not allowed to connect a probe and reset the MPU.

So without a "debug pod" it would be necessary to systematically have the SWO emission validated (no variation of timing in the application when the probe is present / absent).

The traditional answer is to use a UART, but it is slower and more intrusive on the timings of the application. In addition it uses a device which is not always available while the SWO pin is always. What is regrettable is that ARM has restricted the use of ITM and SWO at debug ...

You are right, I am going to have to reverse engineer the applications you indicate to see how to do this.

[ArnoutDekimo]

Hi Nikita91,

I'm also looking into this (enabling SWO without an external debugger, instead of falling back to UART)
Did you manage to figure it out how to do this?

Kind regards,

Arnout