How to view execution trace (adresses executed) from SWO/TRACESWO for STM32F4xx?

[reversiverse]

The SWO/TRACESWO with Instrumentation Trace Macro cell should be able to extract information about what instructions or addresses were executed.

However I still can't find the right tool to do it.

It would be enough for now to show the addresses the PC register went through (between two breakpoints for example). Even just counting the number of instructions or execute clock cycles would be helpful.

Which tool should I use for this? (linux preferably)

[Tesla DeLorean]

To measure cycles use the DWT CYCCNT register.​

[reversiverse]

Basically what I would want it the Serial Wire Viewer as shown here in Keil docs (page 2 - http://www.keil.com/appnotes/files/apnt_297_v102.pdf).

I downloaded a package from ST called Serial Wire Viewer, however there are no tools just some examples and I don't know what ST tool (Cube IDE, CumeMX, ...?) to use to configure TRACESWO and decode it.

[KnarfB]

Prepare a Debug session with STM32CubeIDE. In the Debug configuration Debugger tab enable Serial Wire Viewer. Choose the frequencies depending on your board. For my STM324DISCO Core clock: 168 MHz, SWO clock: 2000 (may be changed, but...)

Start debugging, debugger should break at main().

In STM32CubeIDE Window > Show View > Other ... open a SWV Statistical Profiling Viewer. Configure it (buttons in view window top right).

Check that clock freq. are correct.

Enable PC sampling at default rate, press OK.

Start Trace (button in view window top right).

Resume debugging.

PC sampling statistics should show up in viewer.

There is more, like redirecting stdout to ITM port 0 and viewing it.

hth

KnarfB

[Tesla DeLorean]

I use Keil, I use SWV/SWO to get debug channel communication working. With this it is important to have the PB3/TDO/SWO pin wired to the interface, and the correct clock speed the device is running at. Several of the DISCO/NUCLEO boards have solder bridges, you need to double check these are made.

If I want "real" trace I'd use a ULink-Pro or Segger J-Trace, and the full complement of pins.

CubeIDE (Atollic) should support assort trace, look at the debug option pane for trace.

PDQ Logic also has some trace/profile tools. https://www.pdqlogic.com/

[waclawek.jan]

DWT/ITM won't provide you a full trace. What you see there is periodic sampling of PC.

For full trace you'd need to use ETM and a wider trace port than just SWO. I don't think there are free tools out there for that, but I am also not much interested in this.

JW

PS. Change your username to a normal nick.

[reversiverse]

Thanks, this pointed me in the right direction. I had to battle a bit with the clock setting since I am feeding the clock to HSE from external source.

Though now I see it's just sampling instead of precisely measuring. Probably would need to use another tool (modified STLink), that would signal if program is being run by some GPIO pin and just count the clock cycles with a FPGA when the pin is high.

[Tesla DeLorean]

Bit old-school when it comes to trace, like Jan.

Predominantly good for the cases when you need to determine "how the heck did I get *here*"

It is not real trace, in the 1980's sense, but some compressed flow dynamics that allow host-side simulation to recreate exact internal state.

Others like it for profiling, reverse-stepping, and dynamic analysis.

There are some lower cost solutions.

For instruction/code benchmarking the DWT CYCCNT works very well, tend to use SYSTICK for sanity checking where clocks or elapsed time are high and can potential wrap.

[waclawek.jan]

That's what the OP asked for.

As I've said, I don't use trace. Since 1980 (okay, since 1998, or, since I tried it, exactly once - I was too young in 1980 to be interested either =) ). The value/cost is infinitesimally small in the vast majority of cases, IMO. The recreated internal state may be as good as the "real stuff", but that's still the same case.

These tools are usually marketed as the pinnacle of debugging. And I understand the desire of users to have THE single most powerful tool which would resolve all their worst nightmares in a snap. However, this is simply not true - debugging is and remains to be an engineering act, and as such, learning skills and having a repertoire of tools is inevitable.

And IMO the sampled PC's value is even less than that.

JW

[KnarfB]

Wouldn't use an FPGA but a (cheap) USB logic analyzer for monitoring GPIOs.