It is possible to enable SWO output with a command like this:
STM32_Programmer_CLI.exe -c port=SWD -swv freq=160 portnumber=all swv.log -RA
However, this is overwriting some of the ITM_TCR flags such as TSENA and SYNCENA (and TXENA), and as such the logfile does not contain any timestamp or sync packets. It also doesn't appear to be possible to not log to the console, and log to the file only. I'm really just wanting to dump the raw ITM UART byte stream to a file for later decoding. Unfortunately, it looks like the tool is also stripping off the port numbers and mangling the uint32_t integers I'm sending, so that the log is mangled completely.
Would it be possible to add a "raw" mode to enable the ITM output and log it to a file, without any decoding of the trace? And allow enabling of options like timestamps and sync packets (or at the very least, not overwriting the register settings for these and just toggle the ITMENA bit?
I tried to set this up beforehand:
STM32_Programmer_CLI.exe -c port=SWD mode=HOTPLUG -w32 0xE0000E80 0x06
STM32_Programmer_CLI.exe -c port=SWD mode=HOTPLUG -swv freq=160 portnumber=all swv.log -RA
But this doesn't work either. The value is overwritten.
It looks like the -swv option is primarily intended for text logging on port 0. Is there a better option for getting a raw binary log of all ports? I tried OpenOCD like this:
source [find interface/stlink-dap.cfg]
transport select dapdirect_swd
source [find target/stm32u5x.cfg]
reset_config srst_only srst_nogate
stm32u5x.tpiu configure -protocol uart -traceclk 160000000 -pin-freq 12000000
stm32u5x.tpiu configure -output itm.log
stm32u5x.tpiu configure -event post-enable "write_memory 0xE0000E80 32 0x0007"
stm32u5x.tpiu enable
itm ports on
This works properly, with sync and timestamp packets enabled with a manual register write. But I am seeing the odd byte getting dropped. I tried STM32_Programmer_CLI as an alternative in case it was more efficient. I saw a comment in UM2237 "Some SWV bytes can be lost during transfer due to ST-LINK hardware buffer size limitation." Is there any way around this, or any alternative probe which is recommended for reliable capture if the ST-LINK is not capable of this? I'm using an ST-LINK V3SET.
Thanks,
Roger
