STM32L47 Stuck During Reset

[hlanden]

Hi all,

I am currently experiencing some weird reset behavior for my STM32L47 chip. Due to a non-optimal combination of HW the chip resets from time to time, and I am assuming an ESD issue being the reason for this. As long as the resets are recoverable, it does not really matter.

This is where the trouble arises: Some of the resets are not recoverable, and the chip get stuck in a weird state and will not power on correctly. We see that the watchdog triggers, but it does not enter its mainloop. If you spam the pin-reset it can in some cases reset correctly, but pressing it once does not get it out of this freezed state. So the easiest way to get out of this state is to cut the power and turn it on again. Checking the control status registers during resets we have found the following:

• Some resets report pin- and IWWG-resets. This is fine and then the chip resets correctly.
• When the reset reports pin-, IWWG- and Brownout-resets, it get stuck in the "freezed" state.

So the common denominator for resets that causes the chip to freeze is brownout. If this indicates an actual brownout, or simply a "bug" due to some strange ESD behavior I can't really tell. We have tried measuring during resets as well, but we have not found any obvious bugs in the HW. We have also simulated a brownout, but did not manage to get it into the freezed state.

We tried to increase the brownout level from 1.7 V (default) to 2.5 V, but this had no effect and we still experienced the "freezed" behavior.

Does anyone have any tips on what this freezed behavior can be caused by? Is there some obvious configuration to look into when experience these types of bugs? FYI: the chip are currently running RUST code.

[SoniV]

We actually don't enable  backup domain access before starting the LSE, is this something could potentially cause problems? Is it necessary to do that?

[waclawek.jan]

Without enabling backup domain access you wouldn't be able to enable LSE at all. If you have enabled LSE, maybe some of the drivers you are using enabled DBP for you.

JW

[SoniV]

Not exactly sure how we do that, but i will check and come back to you. But is this the same sequence if we would like to use HSE?

[waclawek.jan]

Use HSE for what? It has a different primary purpose (alhtough HSE/32 is one of the possible inputs to RTC, if that's what you intend it for).

No, HSE is not in the backup domain, so there is no need to enable access to it.

I'm not sure what is your hardware and what do you want to accomplish, but in some cases it's a good idea to perform initial proof-of-concept experiments on some "known-good" hardware such as Nucleo or Disco boards.

JW

[SoniV]

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

  /** Configure the main internal regulator output voltage
  */
  if (HAL_PWREx_ControlVoltageScaling(PWR_REGULATOR_VOLTAGE_SCALE1) != HAL_OK)
  {
    Error_Handler();
  }

  /** Initializes the RCC Oscillators according to the specified parameters
  * in the RCC_OscInitTypeDef structure.
  */
  RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_LSI|RCC_OSCILLATORTYPE_HSE;
  RCC_OscInitStruct.HSEState = RCC_HSE_ON;
  RCC_OscInitStruct.LSIState = RCC_LSI_ON;
  RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON;
  RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSE;
  RCC_OscInitStruct.PLL.PLLM = 2;
  RCC_OscInitStruct.PLL.PLLN = 16;
  RCC_OscInitStruct.PLL.PLLP = RCC_PLLP_DIV7;
  RCC_OscInitStruct.PLL.PLLQ = RCC_PLLQ_DIV2;
  RCC_OscInitStruct.PLL.PLLR = RCC_PLLR_DIV2;
  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_ClkInitStruct.SYSCLKSource = RCC_SYSCLKSOURCE_PLLCLK;
  RCC_ClkInitStruct.AHBCLKDivider = RCC_SYSCLK_DIV1;
  RCC_ClkInitStruct.APB1CLKDivider = RCC_HCLK_DIV1;
  RCC_ClkInitStruct.APB2CLKDivider = RCC_HCLK_DIV1;

  if (HAL_RCC_ClockConfig(&RCC_ClkInitStruct, FLASH_LATENCY_4) != HAL_OK)
  {
    Error_Handler();
  }
}


This is how the clock setup is done by the CubeMX generated code. First it sets up power, then the clocks. Is this the sequence you described earlier?  

[waclawek.jan]

> This is how the clock setup is done by the CubeMX generated code.
> First it sets up power, then the clocks. Is this the sequence you described earlier?

I'm not sure what to answer to this.

I believe I've recommended to:

• make sure power supply is correct during powerdown - negative VDD may cause the mcu to behave unpredictably;
• by bisection and toggling a pin/observing find the point where the mcu stucks upon startup
• add backup domain reset before anything else in startup, to prevent the backup-domain-brownout problem

JW