STM32H7 very hot
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2022-07-21 8:24 AM
Hello dear community,
I've started using STM32H743VGT6 on a custom board I've made.
I'm testing the hardware now and I quickly detected that the temperature is really high (approx. 70°c on the top of the chip package).
I have another board, based on a STM32H743BIT6, quite similar, and the temperature of this one seems normal (approx. 40°C)
- dividing the H7 clock speed by 2 really helps to reduce the temperature, but my original clock config seems right (tested with cubeMX)
- It's not easy for me to measure the current drawn by the H7, as the 3V3 is used by many other devices
Have you ever experienced that kind of issue?
Thanks a lot, have a nice day!
Jean
- Labels:
-
STM32H7 Series
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2022-07-21 8:26 AM
My external crystal is 25MHz
Here is my system clock init :
void System::Init()
{
HAL_Init();
HAL_MspInit();
/* Supply configuration update enable & configure the main internal regulator output voltage*/
HAL_PWREx_ConfigSupply(PWR_LDO_SUPPLY);
__HAL_PWR_VOLTAGESCALING_CONFIG(PWR_REGULATOR_VOLTAGE_SCALE0);
while(!__HAL_PWR_GET_FLAG(PWR_FLAG_VOSRDY)) { }
/* Initializes the RCC Oscillators according to the specified parameters in the RCC_OscInitTypeDef structure */
RCC_OscInitTypeDef RCC_OscInitStruct;
RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSE | RCC_OSCILLATORTYPE_HSI48;
RCC_OscInitStruct.HSEState = RCC_HSE_ON;
RCC_OscInitStruct.HSI48State = RCC_HSI48_ON;
RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON;
RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSE;
RCC_OscInitStruct.PLL.PLLM = 5; // 25MHz / 5 = 5MHz
RCC_OscInitStruct.PLL.PLLN = 192; // 5MHz * 192 = 960MHz
RCC_OscInitStruct.PLL.PLLP = 2; // 960MHz / 2 = 480MHz = SYSCLK
RCC_OscInitStruct.PLL.PLLQ = 20; // 960MHz / 20 = 48MHz = SDCARD
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) __DEBUG_BKPT();
/* Initializes the CPU, AHB and APB buses clocks */
RCC_ClkInitTypeDef RCC_ClkInitStruct;
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_DIV4;
RCC_ClkInitStruct.APB2CLKDivider = RCC_APB2_DIV2;
RCC_ClkInitStruct.APB4CLKDivider = RCC_APB4_DIV2;
if(HAL_RCC_ClockConfig(&RCC_ClkInitStruct, FLASH_LATENCY_4) != HAL_OK) __DEBUG_BKPT();
/* Peripherals Common Clock Configuration */
RCC_PeriphCLKInitTypeDef PeriphClkInitStruct;
PeriphClkInitStruct.PeriphClockSelection = RCC_PERIPHCLK_CKPER;
PeriphClkInitStruct.CkperClockSelection = RCC_CLKPSOURCE_HSI;
if(HAL_RCCEx_PeriphCLKConfig(&PeriphClkInitStruct) != HAL_OK) __DEBUG_BKPT();
/* Systick priority and frequency */
HAL_SYSTICK_CLKSourceConfig(SYSTICK_CLKSOURCE_HCLK);
HAL_SYSTICK_Config(HAL_RCC_GetSysClockFreq() / 8000); // 0.125ms
__HAL_RCC_RNG_CLK_ENABLE();
/* DMA controller clock enable */
__HAL_RCC_DMA1_CLK_ENABLE();
}
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2022-07-21 8:52 AM
Board level issue, stop looking at the SW
Up vote any posts that you find helpful, it shows what's working..
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2022-07-21 10:59 PM
"It's not easy for me to measure the current drawn by the H7...." - can you put the chip in sleep/stop/standby mode and measure the differential current? Can you try building a board with just the micro on it (and the bare essentials for running the micro)?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2022-07-22 12:34 AM
Check that the H7 is not used as a conduction path. Double check power and ground nets in the design. Look for shorts in the construction or assembly of the board.
Check parts and circuit around VCAP pins.
Check you don't have LDO outputs fighting. Check for other output pins which could be driving opposite signal states.​
Up vote any posts that you find helpful, it shows what's working..
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2022-07-26 3:25 AM
Thanks for your ideas!
- check circuit around VCAP : everything fine
- LDO outputs fighting : only PWR_LDO_SUPPLY configured (System::Init)
- output pins which could be driving opposite signal states : everything fine
- no power path are conducted by the H7
- tested all shorts : nothing detected, no low impedances
- power and ground paths are solid (also voltages are proper)
I think it may be not a hardware issue, because the clocking of the H7 really affect the temperature and the current consumption :
By the way I now use a more precise temperature sensor, max temp is 50° (not 70°, sorry for the approximation), and the ambient temperature was 28° during testing.
During normal operation (app is running)
H7 external temp = 51°C
H7 current consumption on 3V3 = 190mA
During normal operation, but with clocking divided (240MHz instead of 480MHz)
H7 external temp = 44°C
H7 current consumption on 3V3 = 100mA
Note : no H7 output pins are used to drive power (eg leds) so the current consumption should correspond to the supply of the internal power of the H7.
... Maybe my results are normal for a LQFP-100 package and I have no issues?
Or maybe I still get a clocking issue? Or a hardware problem...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2022-07-26 3:58 AM
I am quite sure that a damaged part has high current surge independant of **** speed. Have a look at the datasheet and the values given there resemble the values you measure.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2022-07-26 5:50 AM
Well 70C (158F) is burn your finger type hot, it would be uncomfortable to touch
The parts can get warm if doing heavy processing. Perhaps having a NUCLEO doing similar work would be a helpful counter-point.
Up vote any posts that you find helpful, it shows what's working..
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2022-07-27 9:04 AM
Thanks!
To be honest, I had trouble to find the right info in the H743 datasheet https://www.mouser.fr/datasheet/2/389/stm32h743vi-1760857.pdf
Today I've found that indeed, with
- All peripherals enabled (that's closer to my case)
- frcc = 400MHz
- cache ON
The typical current consumption is 165mA and the max is 220mA (Tj = 25°)
That's very close to my testings.
So I guess that everything is normal!
Thanks a lot for your help :)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2022-07-27 10:17 AM
I'm glad you've found your answer. But I have a couple of things that you might consider:
- A solid (or as solid as you can make it) ground plane can help spread the heat and therefore reduce the overall temperature. Or a heat-sink as found on many microprocessors.
- Are you aware of AN5337 "STM32H7 Series lifetime estimates" which states that running for extended periods at high clock speeds will significantly shorten the lifetime of stm32h7. So maybe such high speeds may only be used for short bursts.
