STM32H7 - SWV print not working when using PLL to generate sysclock

[ping_pong]

Hello folks,

I've been having a weird issue and haven't found anyone else with the same problem, so I figured I'd post here.

I have a project for the STM32H735 BLANK. The PCB has an 25 MHz external oscillator (ABM8W-25.0000MHZ-8-D1X-T3) used as the HSE.

When I use the 64 MHz HSI or the 25 MHz HSE without the PLL to generate the sysclock, SWV printing works great. When I run them through the PLL (I'd like to run this with a sysclk at at around 450 MHz), even if I set up the PLL to output the same clock it is given, SWV printing fails. I do not change any other aspects of the code. aside from the sysclock source. I am not forgetting to swap the sysclock on the IDE debug settings side when changing clock settings, and I know I've correctly set up ITM otherwise because I can see it when not using the PLL. Using the debugger and breakpoints, I've verified the code runs correctly for all test cases below (or at least does to the best my knowledge).

Clearly, I'm missing something.

My four test cases and results are:

1. HSE as PLL source, PLL generates same output as input, PLL is SYSCLK source: no SWV
2. HSI as PLL source, PLL generates same output as input, PLL is SYSCLK source: no SWV
3. HSE as SYSCLK source: SWV works fine
4. HSI as SYSCLK source: SWV works fine

void SystemClock_Config(void)
{
RCC_OscInitTypeDef RCC_OscInitStruct = {0};
RCC_ClkInitTypeDef RCC_ClkInitStruct = {0};
RCC_PeriphCLKInitTypeDef PeriphClkInitStruct = {0};

/** Supply configuration update enable
*/
HAL_PWREx_ConfigSupply(PWR_LDO_SUPPLY);

// VOS0 (Voltage scale 0) allows the highest clock values (page 337 in the datasheet)
__HAL_PWR_VOLTAGESCALING_CONFIG(PWR_REGULATOR_VOLTAGE_SCALE0);

// wait until the voltage scaling has taken effect (cannot change the clock before this)
while(!__HAL_PWR_GET_FLAG(PWR_FLAG_VOSRDY)) {}

// configure clocks
// we use the HSI for peripherals and the HSE (External crystal for the system/cpu clock)
RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSI|RCC_OSCILLATORTYPE_HSE;
RCC_OscInitStruct.HSEState = RCC_HSE_ON;
RCC_OscInitStruct.HSIState = RCC_HSI_DIV1;
RCC_OscInitStruct.HSICalibrationValue = 64;
RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON;

// SWAP SECTION
// 1) HSE as PLL source
// RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSE;
// 2) HSI as PLL source
// RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSI;

// SWAP SECTION
// 1) PLL settings to output the same as the input HSE
// RCC_OscInitStruct.PLL.PLLM = 5;
// RCC_OscInitStruct.PLL.PLLN = 100;
// RCC_OscInitStruct.PLL.PLLP = 20;
// 2) PLL settings to output the same as the input HSI
// RCC_OscInitStruct.PLL.PLLM = 4;
// RCC_OscInitStruct.PLL.PLLN = 20;
// RCC_OscInitStruct.PLL.PLLP = 5;

RCC_OscInitStruct.PLL.PLLQ = 2;
RCC_OscInitStruct.PLL.PLLR = 2;
RCC_OscInitStruct.PLL.PLLRGE = RCC_PLL1VCIRANGE_2;
RCC_OscInitStruct.PLL.PLLVCOSEL = RCC_PLL1VCOWIDE;
RCC_OscInitStruct.PLL.PLLFRACN = 0;
if (HAL_RCC_OscConfig(&RCC_OscInitStruct) != HAL_OK)
{
Error_Handler();
}

/** Initializes the CPU, AHB and APB buses clocks
*/
RCC_ClkInitStruct.ClockType = RCC_CLOCKTYPE_HCLK|RCC_CLOCKTYPE_SYSCLK
|RCC_CLOCKTYPE_PCLK1|RCC_CLOCKTYPE_PCLK2
|RCC_CLOCKTYPE_D3PCLK1|RCC_CLOCKTYPE_D1PCLK1;
// SWAP SECTION
// 1 & 2) PLLCLK as SYSCLK source
RCC_ClkInitStruct.SYSCLKSource = RCC_SYSCLKSOURCE_PLLCLK;
// 3) HSE as SYSCLK source
RCC_ClkInitStruct.SYSCLKSource = RCC_SYSCLKSOURCE_HSE;
// 4) HSI as SYSCLK source
RCC_ClkInitStruct.SYSCLKSource = RCC_SYSCLKSOURCE_HSI;

RCC_ClkInitStruct.SYSCLKDivider = RCC_SYSCLK_DIV1;
RCC_ClkInitStruct.AHBCLKDivider = RCC_HCLK_DIV2;
RCC_ClkInitStruct.APB3CLKDivider = RCC_APB3_DIV2;
RCC_ClkInitStruct.APB1CLKDivider = RCC_APB1_DIV2;
RCC_ClkInitStruct.APB2CLKDivider = RCC_APB2_DIV2;
RCC_ClkInitStruct.APB4CLKDivider = RCC_APB4_DIV2;
if (HAL_RCC_ClockConfig(&RCC_ClkInitStruct, FLASH_LATENCY_3) != HAL_OK)
{
Error_Handler();
}
}

[AlvyneZ]

Hi, did you get a solution to this? I'm having the same problem.

SWV works perfectly with HSI and HSE directly, but not through the PLL. Trying to start the Trace errors out with the following error.

[Pavel A.]

Where do you see this message? Which IDE or debugger?

[Tesla DeLorean]

HSIState setting looks to be nonsense in the top post.

Present YOUR settings, and DETAILS of YOUR board, and YOUR code.

SWV need physical connectivity of PB3/SWO and the core frequency needs to be understood by the DEBUGGER to relate the SWCLK of the pod connection, and the dividers for the SWV UART

The clocks and PLLs need to come up properly, and not fail. Perhaps print settings the STM32 thinks it's running at, so APB, AHB and MCU, etc.

[AlvyneZ]

I found that I was disabling PLL1's R output and it is the input clock for the TPIU, from the datasheet:

Enabling this fixed the "Failed to enable SWV configuration" error.

In the Debug Configuration, I've found that setting the Core Clock of the SWV config to the PLL output is what works when PLL1P and PLL1R are equal. When PLL1Rclk < PLL1Pclk, the Core Clock configuration in the IDE should equal the D1 domain clock used by the core.

I believe on other STM32 mcus (F & L series), the IDE's SWV core clock should equal the AHB clock.

[ping_pong · Accepted solution]

My solution was pretty simple. The output from DIVR1 must match the SYSCLOCK. If not, it breaks. Doesn't matter what combination of divisors and prescalers are used, as long as DIVR1 matches the SYSCLOCK.

As a general solution, ensure that the clock source for the SWV is enabled, and that it matches the PLL (or other clock as required by the datasheet.)

[bramble]

I have this working, i.e. printf() and variable trace views in CubeIDE for STM32H755, but it wasn't exactly easy.

Here's an explanation of how I made it work, including some things that didn't work when following standard advice that I found in this community.

My setup is:

• STM32H755 Nucleo with default hardware configuration - i.e. no changes to any solder bridges or to anything else.
• IDE = CubeIDE (and opening the .ico within it to make MX config changes).
• CM7 configured for 400 MHz using PLL, i.e. max possible frequency using switched-mode power supply (SMPS).
• PLL1R clock set to 200 MHz - this is important
• Debug mode set in MX to "Asynchronous Trace SW"
• Added _write() function to my code as per normal instructions.

Working clock config as below:

After editing the Debugger config in CubeIDE to enable SWV and setting the CPU clock speed there (alongside SWV settings) to 400 MHz, I found that printf() produces no output and variables added to the SWV Data Trace Timeline Graphs are NOT logged.

After lots of experiments I found that if I set the CPU clock in the debugger settings for SWV to 64 MHz, then I see some garbled data coming out printf() on the SWV ITM Data Console view, and occasionally some invalid data variable trace values - clearly there's something wrong in that setup.

When I changed my core clock in MX to 200 MHz I noticed a warning from MX that the PLL1R clock was too high at 400 MHz, so I changed its divisor so that PLL1R clock is 200 MHz, then with the Cube IDE debugger config now set to 64 MHz core clock setting I have printf and data trace logging working perfectly. This is strange because standard advice is that SWV's configured CPU freq is supposed to match the true CPU clock.

I then changed my core clock in MX back to 400 MHz, and despite there being no warning this time that the PLL1R clock was too high, I used the modified divisor setting to ensure that it was again 200 MHz. With that configured, and the CM7 CPU at 400 MHz, along with my debugger settings set to 64 MHz core clock, I have SWV working perfectly. Once again, that shouldn't be the case, but it works so I'm going with it until somebody gives me another solution.

I have used the debugger to confirm that global variable SystemCoreClock is indeed 64 MHz *before* SystemClockConfig() is called, and that it's 400 MHz after the clocks have been configured. So there's no mistake in my understanding of the clock config.

One other thing to mention about the official documentation. The H755 Nucleo User Manual UM2408 clearly states that the solder bridge config to enable SWO should be SB49 = OFF and SB50=ON, as below:

My board has both of these ON. I have not tried removing SB49 since I already have a working solution. Nor have I checked the schematic but I'm guessing that SB49=ON is enabling a pull-up/down resistor while SB50 is the important one that connects PB3 to SWO on the debugger interface.

I hope this might be helpful to other people struggling with SWV on their H75x.

Any corrections or additional insight into this would be much appreciated.