cancel
Showing results for 
Search instead for 
Did you mean: 

STM32H7B3IL-DK - Trace & Profiling is not working correctly.

Garnett.Robert
Senior III

Hi All,

I tried to profile my latest creation using the STM32H73BIL, but the Trace Log and Profiling Window aren't working correctly.

I thought maybe it was my CubeIDE Install, so I tried profiling on a Nucleo F411RE. It worked fine:

0693W00000KcBfLQAV.pngThe STM32H73BIL gave:

0693W00000KcBfGQAV.pngFrom the trace log of the STM32H73BIL-DK it would appear that instead of sampling the program counter, the trace system is sampling at least two of the address comparitors although none of the address comparitors is enabled. The Nucleo on the other hand is sampling the program counter.

The setup for the STM32H73BIL-DK is:

Debug -

0693W00000KcBfVQAV.pngThe Trace Settings:

0693W00000KcBfuQAF.png 

I tried to examine the Cortex-M7 data watch-point and trace unit (DWT) registers, but they don't seem to be included in the SFR list. I have a suspicion that the Trace Settings dialog isn't setting these correctly.

I tried making a simple project for the STM32H73BIL-DK using the latest CubeMX (6.5) and Cube IDE (1.9) as my other project was created about six months ago, but I got the same result for the trace log and profile.

I have attached this project (cleaned) as a zip.

It's a bit of a pain because I quite like the Profiling tool as it is a quick and easy way of getting a feel for overall system performance. It's also good for picking up silly mistakes in loops which bog the processor down.

Has anyone any ideas on this?

Regards

Rob

 **** Moderator note: Internal name removed

7 REPLIES 7
mattias norlander
ST Employee

Perhaps a bit late on the ball, but had a similar request which linked to this forum post...

Did you solve this one?

I can re-produce the behavior of trying to get PC samples but packets coming over SWO pin interpreted as DATA_TRACE packets.

In my case this happens if I set an incorrect Core clock in the debug configuration. It I make sure it is aligned with the HCLK on target, then the H7B3I-DK works well for me with SWV profiling.

Could you check?

mattias norlander
ST Employee

I changed the name of the topic, I think you are referring to "STM32H7B3I-DK"

Garnett.Robert
Senior III

Yes

Thats Ok

Rob

Hi Mattias,

They are the same if HCLK is the same variable as SystemCoreClock at 280 MHz

0693W00000NpYu2QAF.png0693W00000NpYuCQAV.png 

If HCLK is a different variable from SystemCoreClock how can I work out what the value is?

Here is my code (from CubeMX) for my clock setup:

void SystemClock_Config(void)
{
  RCC_OscInitTypeDef RCC_OscInitStruct = {0};
  RCC_ClkInitTypeDef RCC_ClkInitStruct = {0};
 
  /** Supply configuration update enable
  */
  HAL_PWREx_ConfigSupply(PWR_DIRECT_SMPS_SUPPLY);
  /** Configure the main internal regulator output voltage
  */
  __HAL_PWR_VOLTAGESCALING_CONFIG(PWR_REGULATOR_VOLTAGE_SCALE0);
 
  while(!__HAL_PWR_GET_FLAG(PWR_FLAG_VOSRDY)) {}
  /** Configure LSE Drive Capability
  */
  HAL_PWR_EnableBkUpAccess();
  __HAL_RCC_LSEDRIVE_CONFIG(RCC_LSEDRIVE_LOW);
  /** Macro to configure the PLL clock source
  */
  __HAL_RCC_PLL_PLLSOURCE_CONFIG(RCC_PLLSOURCE_HSE);
  /** Initializes the RCC Oscillators according to the specified parameters
  * in the RCC_OscInitTypeDef structure.
  */
  RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSI48 |
  																	 RCC_OSCILLATORTYPE_HSI |
																		 RCC_OSCILLATORTYPE_HSE |
																		 RCC_OSCILLATORTYPE_LSE;
  RCC_OscInitStruct.LSEState = RCC_LSE_BYPASS;
  RCC_OscInitStruct.HSEState = RCC_HSE_ON;
//  RCC_OscInitStruct.LSEState = RCC_LSE_ON;
  RCC_OscInitStruct.HSIState = RCC_HSI_DIV1;
  RCC_OscInitStruct.HSI48State = RCC_HSI48_ON;
  RCC_OscInitStruct.HSICalibrationValue = RCC_HSICALIBRATION_DEFAULT;
  RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON;
  RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSE;
  RCC_OscInitStruct.PLL.PLLM = 12;
  RCC_OscInitStruct.PLL.PLLN = 280;
  RCC_OscInitStruct.PLL.PLLP = 2;
  RCC_OscInitStruct.PLL.PLLQ = 2;
  RCC_OscInitStruct.PLL.PLLR = 4;
  RCC_OscInitStruct.PLL.PLLRGE = RCC_PLL1VCIRANGE_1;
  RCC_OscInitStruct.PLL.PLLVCOSEL = RCC_PLL1VCOWIDE;
  RCC_OscInitStruct.PLL.PLLFRACN = 0;
  if (HAL_RCC_OscConfig(&RCC_OscInitStruct) != HAL_OK)
  {
    __asm("BKPT #0\n") ; /* TODO Break into the debugger */
  }
  /** 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;
  RCC_ClkInitStruct.SYSCLKSource = RCC_SYSCLKSOURCE_PLLCLK;
  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)
  {
    __asm("BKPT #0\n") ; /* TODO Break into the debugger */
  }
  HAL_RCC_MCOConfig(RCC_MCO1, RCC_MCO1SOURCE_HSE, RCC_MCODIV_1);
}

Suspecting you are correct about the clock frequency setting being incorrect I set the Debuh clock setting to 140 MHz and it now seemt to be working.

I am confused however as when I work my way through the CubeMX Clock tree I get 280, SystemCoreClock sys 280 and when I look at the clock initialization code that lines up with t CubeMX and also gives 280.

The problem I fin is that the nomenclature of the CubeMX clock tree does not line up with the clock code. i.e. SystemCoreClock is not shown on the CubeMZ tree and I am assuming its the signal that goes to the CPU Clocks (MHz).

I took a screen shot of the registers:

0693W00000NpYvAQAV.pngSWV Settings:

0693W00000NpYydQAF.png 

I think I've figured out the terminology now, the CubeMX nomenclature refers to RCC register sub fields. But i still reckon the clock is 280 MHz not 140.

Any ideas on what I'm doing wrong. I'm worried now that the CPU clock is 140 not 180.

Best regards Rob

>>Moderator note: Internal name removed

The Tiny Shark reference for the board and MCU is in multiple places, it was in the schematic title for many years, and still at least one reference in the current one.

https://www.st.com/content/ccc/resource/technical/layouts_and_diagrams/schematic_pack/group1/e0/e5/29/92/9d/37/47/91/MB1332-H7B3I-B02_Schematic/files/MB1332-H7B3I-B02_Schematic.PDF/jcr:content/translations/en.MB1332-H7B3I-B02_Schematic.PDF

It was purged from multiple places, but is still in the web link for Farnell/Newark

https://pl.farnell.com/en-PL/stmicroelectronics/stm32h7a3zit6/tiny-shark-mcu/dp/3297728

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

Yes,

That's correct. Its a lot easy to refer to it by it's nickname than the part number which is a pain to remember and write.

I am going to continue to use the nickname for this reason. I will refer to the part no once in any posts just to identify it "officially."

Rob

Hi again,

Resurrecting this thread since I learned from a colleague that the clock tree inside STM32H7 is different vs other MCUs. For H7, the SWO clock is sourced from a separate mux: "Trace Clock Mux".

0693W00000UoC6GQAV.png 

This is a change in the clock tree of STM32H7 vs other STM32 products. In old products the trace clock was sourced from HCLK.

We should update the label in the GUI...

So, on H7 devices - please have a look at the MX clock tree at the bottom right side where you will see the "Trace Clock Mux" to know the value to be used.

Will see if I can dig up some more details...