STM32F4 stops running at temperature

[Rob Ashworth]

Posted on March 29, 2018 at 17:23

I am using a STM32F429IG, but I am having some difficulties at elevated temperatures.  Much above 70 DegC the program just seems to stop.  I have decoded the internal temperature as well as using an external one, so I an happy the temperature is correct.  Any ideas, anyone, as I'm starting to run out.

[Tesla DeLorean]

Posted on March 29, 2018 at 18:29

>>the program just seems to stop.

What does that actually mean? Is it spinning in a while(1) loop in the Hard Fault Handler, or do you have that outputting some diagnostic data?

Have you increased the FLASH wait state settings? Turned off PREFETCH?

>>Any ideas, anyone, as I'm starting to run out.

This doesn't help me understand what you've done or tried already.

Check also behaviour of other system components and supplies at temperature. The F4 is going to get flaky if the VCAP voltage or capacitors become unstable.

[Rob Ashworth]

Posted on March 29, 2018 at 18:41

Hi Clive,

To be honest, I'm not exactly sure what it is doing.  The micro controller is now hooked up to a CAN transceiver and everything else has been turned off so it can't interfere.  All capacitors are X7R, so good to 125C, power supply has been tested to 125C and not a flicker.  Unfortunately I have no external simple IO to check anything, and I'm not conversant with a debugger.  I just wondered if there's anything obvious thats going to put the thing into reset etc.  Oscillator is a ceramic one, but good to 125C, and I have used that before on other STM32F1xx boards without issue.  What course of action would you recommend so I can see what is happening?  I use Eclipse  GCC as my toolchain.

[waclawek.jan]

Posted on March 30, 2018 at 00:11

https://community.st.com/0D50X00009XkWZdSAN

's 'any idea' too.

JW

[Rob Ashworth]

Posted on March 30, 2018 at 10:41

I am adding my schematic for info, could this be something to do with the internal regulator..?

[Rob Ashworth]

Posted on March 30, 2018 at 12:21

I have tested 3 pieces of hardware all exhibiting the same fault - 2 have been professionally fitted, and 1 by me!  The resonator is specified to 125C, at 0.1%, so I don't suspect that - and I have used it in the past on STM32F103's without issue.  I'm currently playing around with :

__HAL_PWR_VOLTAGESCALING_CONFIG(PWR_REGULATOR_VOLTAGE_SCALE1);

//settings,

Clive also mentioned FLASH LATANCY settings, but not sure what impact this will have on temperature...

Here is my full config...

void SystemClock_Config(void)

{

  RCC_OscInitTypeDef RCC_OscInitStruct;

  RCC_ClkInitTypeDef RCC_ClkInitStruct;

    /**Configure the main internal regulator output voltage 

    */

  __HAL_RCC_PWR_CLK_ENABLE();

  __HAL_PWR_VOLTAGESCALING_CONFIG(PWR_REGULATOR_VOLTAGE_SCALE1);

    /**Initializes the CPU, AHB and APB busses clocks 

    */

  RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSE;

  RCC_OscInitStruct.HSEState = RCC_HSE_ON;

  RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON;

  RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSE;

  RCC_OscInitStruct.PLL.PLLM = 4;

  RCC_OscInitStruct.PLL.PLLN = 160;//was 100

  RCC_OscInitStruct.PLL.PLLP = RCC_PLLP_DIV2;

  RCC_OscInitStruct.PLL.PLLQ = 8;

  if (HAL_RCC_OscConfig(&RCC_OscInitStruct) != HAL_OK)

  {

    _Error_Handler(__FILE__, __LINE__);

  }

    /**Initializes the CPU, AHB and APB busses clocks 

    */

  RCC_ClkInitStruct.ClockType = RCC_CLOCKTYPE_HCLK|RCC_CLOCKTYPE_SYSCLK

                              |RCC_CLOCKTYPE_PCLK1|RCC_CLOCKTYPE_PCLK2;

  RCC_ClkInitStruct.SYSCLKSource = RCC_SYSCLKSOURCE_PLLCLK;

  RCC_ClkInitStruct.AHBCLKDivider = RCC_SYSCLK_DIV1;//was 1

  RCC_ClkInitStruct.APB1CLKDivider = RCC_HCLK_DIV4;

  RCC_ClkInitStruct.APB2CLKDivider = RCC_HCLK_DIV2;

  if (HAL_RCC_ClockConfig(&RCC_ClkInitStruct, FLASH_LATENCY_3) != HAL_OK)

  {

    _Error_Handler(__FILE__, __LINE__);

  }

    /**Configure the

Systick

interrupt time 

    */

  HAL_SYSTICK_Config(HAL_RCC_GetHCLKFreq()/1000);

    /**Configure the

Systick

 

    */

  HAL_SYSTICK_CLKSourceConfig(SYSTICK_CLKSOURCE_HCLK);

  /* SysTick_IRQn interrupt configuration */

  HAL_NVIC_SetPriority(SysTick_IRQn, 0, 0);

}

[Rob Ashworth · Accepted solution]

Posted on March 30, 2018 at 13:12

All sorted.  I set 

__HAL_PWR_VOLTAGESCALING_CONFIG(PWR_REGULATOR_VOLTAGE_SCALE1);

instead of:

__HAL_PWR_VOLTAGESCALING_CONFIG(PWR_REGULATOR_VOLTAGE_SCALE3);

And it runs all the way up to 125C now.  

I'm guessing when I used the CUBEmX tool to generate the code automatically, I originally had a lower HCLK (100MHz) and it set the internal VREF to too low a value...

Thank you for your assistance.

For future reference the HCLK is running at 160MHz, and the HAL libraries have this note in them:

#define PWR_REGULATOR_VOLTAGE_SCALE1         PWR_CR_VOS             /* Scale 1 mode(default value at reset): the maximum value of fHCLK is 168 MHz. It can be extended to

                                                                       180 MHz by activating the over-drive mode. */

#define PWR_REGULATOR_VOLTAGE_SCALE2         PWR_CR_VOS_1           /* Scale 2 mode: the maximum value of fHCLK is 144 MHz. It can be extended to

                                                                       168 MHz by activating the over-drive mode. */

#define PWR_REGULATOR_VOLTAGE_SCALE3         PWR_CR_VOS_0           /* Scale 3 mode: the maximum value of fHCLK is 120 MHz. */

[waclawek.jan]

Posted on March 30, 2018 at 11:47

Ah so it's BGA? Can't this simply be a case of bad joints on some of the supply/ground pins? Do you have multiple pieces of hardware exhibiting the same symptom?

Also, can't the 'resonator' be a source of temperature-dependent issues?

To be honest, I'm not exactly sure what it is doing.

So how does it fail short of expectations and what those expectations were? In other words, how do you know it 'stops running'?

In cases like these you should devise simple tests, run them and observe the results.

JW

[waclawek.jan]

Posted on March 30, 2018 at 12:42

The resonator

The oscillator circuit is an analog thing, it may go awry with temperature-induced changes in its parameters - including the amplifier internal in STM32. In other words, the component may be good to 125deg.C but the oscillator as a whole system may fail.

What's it frequency? What's the system frequency? How do you use the Q tap of the PLL?

And you still haven't answered the main question, what are symptoms exactly and why do you think it's a failure?

JW

[Tesla DeLorean]

Posted on March 30, 2018 at 18:17

>>Clive also mentioned FLASH LATENCY settings, but not sure what impact this will have on temperature...

The flash and the ART cache are critical paths in the design, and transistor speed is impacted by voltage/temperature

At 160 MHz I'd have

FLASH_LATENCY_

5, might work at

FLASH_LATENCY_4 but I like to round up fractions and most of the performance here is hidden by ART caching and prefetch paths.

A failure here results in deliver of bad data/instructions, the latter usually in a Hard Fault due to how tightly coupled things are.

>>What course of action would you recommend so I can see what is happening?

I have devices output telemetry via a USART, and use GPIO/LED to identify failure paths, it likely doesn't 'STOP' it rather goes somewhere and dies there because you have a while(1) loop going nowhere.

I put a proper Hard Fault Handler in the things I build

https://community.st.com/thread/15197?commentID=8003#comment

Things might get so broken this won't execute successfully, but most times enough of the message comes out to know it died here, or step one is illuminating an LED or writing a POST code to a latch.

Identify all other potential infinite loops and instrument them, and idle tasks (toggle signs of life LED/GPIO)