2024-04-18 07:39 AM - edited 2024-04-18 07:56 AM
We use ITM, locally configured by the embedded code at startup, for our trace output. We have code for this that works with STM32F4 (see below), as advised by Segger; this advice doesn't seem to have changed since we adopted it. Using the same code with STM32U5 we end up in a hard fault after a few calls to ITM_SendChar(). What do we need to add to this code for the STM32U5 case? I have seen a post on this topic here but that person did not succeed, hence asking this narrower question.
Working ITM set-up code for STM32F4 (where U_CFG_HW_SWO_CLOCK_HZ is 125000 to guarantee reliability):
uint32_t stimulusRegs;
// Enable access to SWO registers
DEMCR |= (1 << 24);
ITM_LSR = 0xC5ACCE55;
// Initially disable ITM and stimulus port
// To make sure that nothing is transferred via SWO
// when changing the SWO prescaler etc.
stimulusRegs = ITM_ENA;
stimulusRegs &= ~(1 << 0); // Disable stimulus port 0
ITM_ENA = stimulusRegs;
ITM_TCR = 0; // Disable ITM
// Initialize SWO (prescaler, etc.)
TPIU_SPPR = 0x00000002; // Select NRZ mode
TPIU_ACPR = (SystemCoreClock / U_CFG_HW_SWO_CLOCK_HZ) - 1;
ITM_TPR = 0x00000000;
DWT_CTRL = 0x400003FE;
FFCR = 0x00000100;
// Enable ITM and stimulus port
ITM_TCR = 0x1000D; // Enable ITM
ITM_ENA = stimulusRegs | (1 << 0); // Enable stimulus port 0
In case it matters, I am testing this on a Nucleo 575ZI board with OpenOCD.
Solved! Go to Solution.
2024-04-18 12:06 PM
Answering my own question: absolutely nothing needs to change! Having fixed my hard fault (I was calling a iprint() before I should have) the code above works fine for STM32U5, no AF0 of PB3 required, I just had to get the clock frequencies correct; building for the target with SystemCoreClock = 4000000, my OpenOCD stm32u5.cfg file had to be:
# OpenOCD config for STM32U5x
source [find interface/stlink.cfg]
transport select hla_swd
source [find target/stm32u5x.cfg]
reset_config srst_only
# Target specific frequencies
set _TARGET_SYSTEM_FREQUENCY 160000000
set _TARGET_SWO_FREQUENCY 125000
...then I could obtain SWV logging from OpenOCD on port 40404 by calling it with:
source [find interface/stlink.cfg]
source [find target/stm32u5x.cfg]
init
stm32u5x.tpiu configure -protocol uart -traceclk 160000000 -pin-freq 125000 -output :40404 -formatter off
stm32u5x.tpiu enable
itm port 0 on
reset init
resume
2024-04-18 08:10 AM
No sooner do I post that but the hard fault goes away. However, I still don't get any SWO output from OpenOCD: there is talk of enabling AF0 on PB3: is it correct that I must do that to get SWO output from STM32U575 on the Nucleo board?
2024-04-18 08:32 AM
Hard fault is back, I must have just been lucky.
2024-04-18 12:06 PM
Answering my own question: absolutely nothing needs to change! Having fixed my hard fault (I was calling a iprint() before I should have) the code above works fine for STM32U5, no AF0 of PB3 required, I just had to get the clock frequencies correct; building for the target with SystemCoreClock = 4000000, my OpenOCD stm32u5.cfg file had to be:
# OpenOCD config for STM32U5x
source [find interface/stlink.cfg]
transport select hla_swd
source [find target/stm32u5x.cfg]
reset_config srst_only
# Target specific frequencies
set _TARGET_SYSTEM_FREQUENCY 160000000
set _TARGET_SWO_FREQUENCY 125000
...then I could obtain SWV logging from OpenOCD on port 40404 by calling it with:
source [find interface/stlink.cfg]
source [find target/stm32u5x.cfg]
init
stm32u5x.tpiu configure -protocol uart -traceclk 160000000 -pin-freq 125000 -output :40404 -formatter off
stm32u5x.tpiu enable
itm port 0 on
reset init
resume
2024-04-18 12:27 PM
Would have hoped the SWO rates could be a bit higher than that. The ST-LINK/V2 defaulted to 2 MHz, and the ST-LINK/V3 (USD-HS) a lot higher. Suppose it depends a lot on the pod firmware, how it buffers, and how it off-loads.
On the Hard Fault side I tend to use something like this, so the field support team can get me some actionable data, over "It Died!"
https://github.com/cturvey/RandomNinjaChef/blob/main/KeilHardFault.c
-Clive
2024-04-18 12:33 PM
Hi Clive: you do get around :-).
Yes, 125kHz is very conservative indeed; we found we had to use that for STM32F407 discovery boards to lose nothing over a 1 hour test run and, since it is enough for us, we have just kinda stuck with it.
Thanks for pointing to the register dump code: we have a back-trace-dumper for STM32F4, I have yet to test whether it does anything useful for CM33, I guess probably not.