cancel
Showing results for 
Search instead for 
Did you mean: 

SWO only works at 16MHz with STLINK-V3PWR

NateS
Associate III

SWV 16MHz, SYSCLK 16Mhz = logging works
SWV 16MHz, SYSCLK 25Mhz = logs gibberish (expected)
SWV 25MHz, SYSCLK 25Mhz = logs nothing at all
SWV 48MHz, SYSCLK 48Mhz = logs nothing at all

Why would this be?

It works with HSI 16MHz, so my wiring and configuration must be correct. I'd expect gibberish from a mismatch, seems odd to see nothing at all.

Maybe the V3PWR is at fault? I've ordered a V3SET and V3MINIE to compare.

HSI isn't accurate enough for my needs. My HSE is 25MHz and PLLP output must be >= 24MHz, so I can't try HSE 16MHz.

1 ACCEPTED SOLUTION

Accepted Solutions
NateS
Associate III

CubeIDE version: 1.13.2 (18220_20230914_1601, latest as of yesterday)
V3PWR firmware: V4.J3.B1.P4 (latest as of yesterday)
Target: STM32F411CEU6

SWD is working, so I can pause execution and check eg SystemCoreClock. It's 16000000 before SystemClock_Config() and 25000000 after. My code continues to run at 25MHz so I think my HSE is working correctly. I will drag out the scope to be sure... oh wow my HSE is actually 10MHz. Just wow. Aaaaand SWO works correctly now that I specified the right speed. What an idiot moment! Thank you for taking a look and prodding me to find the error.

I think it'd be an improvement if the UI would report invalid data on SWO. The differentiation between "there is nothing" and "there is something but it's invalid, are your speeds correct?" would surely help many people.

View solution in original post

5 REPLIES 5
CYANG.1
ST Employee

I think such issue maybe caused by time sequence issue of the SWV.

S C
ST Employee

Hello,

According to the STLINK-V3PWR user manual (https://www.st.com/resource/en/user_manual/um3097-source-measurement-unit-smu-and-debuggerprogrammer-for-stm32-microcontrollers-stmicroelectronics.pdf) the maximum frequency for SWV is 12MHz at 3.3V and 10MHz at 1.8V. Higher frequencies may generate too many data loss in a continuous flow to consider it functional. Gibberish data are not always present, they require the STLINK-V3PWR UART to at least detect a start bit and to face no other error afterwards. At 25MHz and 48MHz the signal is probably too much degraded at STLINK-V3PWR UART input, this has even not been measured (clearly out of specifications)

NateS
Associate III

Thanks, but the speeds I mentioned for SWV is the core clock speed as entered into the debug configuration in STM32CubeIDE:

I have tried limiting (down to 200kHz) and not limiting the SWO clock, but it doesn't change the result. Here are my numbers showing the SWO clock:

SWV 16MHz / 8 = 2000kHz, SYSCLK 16Mhz = logging works
SWV 16MHz / 8 = 2000kHz, SYSCLK 25Mhz = logs gibberish (expected)
SWV 25MHz / 13 = 1920kHz, SYSCLK 25Mhz = logs nothing at all
SWV 48MHz / 16 = 2000kHz, SYSCLK 48Mhz = logs nothing at all

With SYSCLK 48Mhz, the SWO clock is the same 2000kHz as it is with SYSCLK 16Mhz, yet it does not work.

It makes sense about the start bit, though I still don't understand why the only configuration that works is SWV 16MHz / 8 = 2000kHz. It seems if I set any other frequency, I get nothing.

OK so the issue seems rather at CubeIDE or application level, not at probe level (in your cases, the parameter given to the probe by CubeIDE should be 2000kHz or 1920kHz, the probe has no knowledge of the real core clock). You have to ensure that the core clock value specified in CubeIDE for trace configuration is really matching the runtime value of your application (get rid of any possible build configuration issue, ...). What is your CubeIDE version ? On which target do you see the issue ? Do you have the possibility to either monitor signals (to check UART frequency) or to add a blinking LED in your application to double check the runtime frequency between configurations ?

NateS
Associate III

CubeIDE version: 1.13.2 (18220_20230914_1601, latest as of yesterday)
V3PWR firmware: V4.J3.B1.P4 (latest as of yesterday)
Target: STM32F411CEU6

SWD is working, so I can pause execution and check eg SystemCoreClock. It's 16000000 before SystemClock_Config() and 25000000 after. My code continues to run at 25MHz so I think my HSE is working correctly. I will drag out the scope to be sure... oh wow my HSE is actually 10MHz. Just wow. Aaaaand SWO works correctly now that I specified the right speed. What an idiot moment! Thank you for taking a look and prodding me to find the error.

I think it'd be an improvement if the UI would report invalid data on SWO. The differentiation between "there is nothing" and "there is something but it's invalid, are your speeds correct?" would surely help many people.