cancel
Showing results for 
Search instead for 
Did you mean: 

Configuring ITM on STM32U5

Rob Meades
Senior

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.

1 ACCEPTED SOLUTION

Accepted Solutions
Rob Meades
Senior

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

 

View solution in original post

5 REPLIES 5
Rob Meades
Senior

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?

Rob Meades
Senior

Hard fault is back, I must have just been lucky.

Rob Meades
Senior

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

 

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

 

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

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.