Use st-trace to collect ITM traces

[0xyd]

Dear all,

I was trying to collect ITM traces by st-trace command. However, I couldn't find a complete document about how to do so. I use ST-LINK/v2 debugger on a STM32F303RC6 chip. I have the code that can write char to an ITM port but I couldn't see any output from st-trace. What config should I make for the st-trace? Does it automatically read result from SWO pin?

Thank you very much!

[simplerobot]

Hi @0xyd,
The only documentation that current exists is the "--help" contents and the troubleshooting message that pops up after 10 seconds if no information is read or we receive bad data. I've included these messages below. The st-trace command reads ITM data through the SWO pin on channel 0 and outputs it to stdout. The most common problem we've seen are due to the clock frequency on the test board not matching the frequency specified to st-trace with the "--clock=XX" parameter. Tell me more. What speeds/configurations are you using in your setup?

st-trace - usage:
-h, --help Print this help
-V, --version Print this version
-vXX, --verbose=XX Specify a specific verbosity level (0..99)
-v, --verbose Specify a generally verbose logging
-cXX, --clock=XX Specify the core frequency in MHz
-tXX, --trace=XX Specify the trace frequency in Hz
-n, --no-reset Do not reset board on connection
-sXX, --serial=XX Use a specific serial number
-f, --force Ignore most initialization errors

2022-05-18T17:09:20 INFO common.c: F42x/F43x: 256 KiB SRAM, 2048 KiB flash in at least 16 KiB pages.
2022-05-18T17:09:20 INFO trace.c: Trace Port Interface configured to expect a 1240 MHz system clock.
2022-05-18T17:09:20 INFO trace.c: Trace frequency set to 2000000 Hz.
2022-05-18T17:09:20 INFO trace.c: Reading Trace
2022-05-18T17:09:30 WARN trace.c: ****
2022-05-18T17:09:30 WARN trace.c: We do not appear to be retrieving data from the stlink correctly.
2022-05-18T17:09:30 WARN trace.c: Verify the system clock is running at 180 MHz.
2022-05-18T17:09:30 WARN trace.c: Try specifying the system clock with the --clock=XX command line option.
2022-05-18T17:09:30 WARN trace.c: Try setting the trace speed in your device's clock initialization routine:
2022-05-18T17:09:30 WARN trace.c: TPI->ACPR = HAL_RCC_GetHCLKFreq() / 2000000 - 1;
2022-05-18T17:09:30 WARN trace.c: Diagnostic Information:
2022-05-18T17:09:30 WARN trace.c: Raw Bytes: 204
2022-05-18T17:09:30 WARN trace.c: Target Data: 0
2022-05-18T17:09:30 WARN trace.c: Time Packets: 0
2022-05-18T17:09:30 WARN trace.c: Hardware Overflow Count: 0
2022-05-18T17:09:30 WARN trace.c: Software Overflow Count: 0
2022-05-18T17:09:30 WARN trace.c: Errors: 0
2022-05-18T17:09:30 WARN trace.c: Unknown Opcodes:
2022-05-18T17:09:30 WARN trace.c: Unknown Sources:
2022-05-18T17:09:30 WARN trace.c: Chip ID: 0x0419
2022-05-18T17:09:30 WARN trace.c: ****

[simplerobot]

Your trace message appears to show that st-trace is getting garbled data from the mcu. I think the problem is that st-trace currently only supports integer MHz clock speeds and 7 MHz is not close enough to 7.38462 MHz. I can look at this in some detail this weekend. In the meantime, it would be really helpful to verify this is the problem. Are you able to try running the mcu near an integer MHz clock speed?

Thanks,
John

[0xyd]

Hi,
At the moment I don't know how to adjust the clock speed. I will check it out tomorrow. (It's at night in central Europe now.)
But before adjusting the clock speed, I also want to clarify one thing:
Except set up ITM, is Trace Port Interface necessary for this function too?
Thank you!

[simplerobot]

Hi @0xyd,
Sorry for missing your question: On startup, st-trace should initialize TPI as needed. However, your program can overwrite this, such as by setting up the Asynchronous Clock Prescaler Register:
TPI->ACPR = HAL_RCC_GetHCLKFreq() / 64000 - 1

I dug into this issue over the weekend and was able to recreate it using single digit fractional MHz clock speeds. The synchronization seems to work better if you set the clock too high, rather than too low. You may be able to receive data by setting "--clock=8" to st-trace. If not, st-trace will need an integer MHz clock speed until this is fixed.

Here are the things I think should be fixed that are directly related to your problem:

1. We need to be able to set the clock speed exactly.

Here are some other clock related issues that I think should be fixed:
2. There is a cosmetic bug that reads the TPI prescaler from the wrong register, causing us to print out the wrong clock speed configuration on startup.
3. The STM32 chips appear to support a maximum trace speed of 1/8 of the system clock. There should be an error if the trace speed is set too high.

I'm going to create an issue to track this, and hope to have a code review out next week, but it is likely to take a bit before these changes are available in a release.

Thanks for finding these issues!
John

[simplerobot]

Hi @0xyd,
I've got one more potential fix for you. Try manually setting the asynchronous clock prescaler register after your clock setup routine as below and do not include the "--clock" argument to st-trace.

TPI->ACPR = HAL_RCC_GetHCLKFreq() / 2000000 - 1;

Thanks,
John

[0xyd]

Hi,
Sorry for the late reply. After digging out other solutions, it seems like OpenOCD provides the most reliable solution I can get so far. I set up the clock speed to 8MHz and then set up the following setting on OpenOCD as below:

tpiu create stm32f3x.cpu.tpiu -dap stm32f3x.dap -ap-num 0
stm32f3x.cpu.tpiu configure -protocol uart -output itm.fifo -traceclk 8000000 -pin-freq 2000000 -formatter 0
stm32f3x.cpu.tpiu enable
itm port 0 on

As what I did in OpenOCD is actually the same suggestion you made in the previous thread, maybe the OpenOCD implementation can help you to figure out the bugs? I would like to help you to test the code once the fix is issued. :D

Many Thanks!

[Nightwalker-87]

@simplerobot: What is the actual state here? Can you contribute to this topic?

[simplerobot]

I believe this was resolved with #1252.

[Nightwalker-87]

Fixed in #1252.