6 years, 4 months ago.

STM32L152RE deepsleep issues


I have issues with my custom board coming out of deepsleep(). I have an interrupt tied to a user button. The interrupt will execute but it will not jump back into my main code after the deepsleep() line. It also seems like the clocks are not getting setup correctly after waking up because I had a wait statement in my interrupt to turn on and off an LED for 2 seconds, and when executing it took around 8 seconds to flash the LED. Things seem to work correctly when using sleep() instead of deepsleep().

Has anyone seen this before?

Also I am also having problems with the low power mode current consumption. Basically I get 500-600uA in deepsleep, 4mA in sleep, and 10mA in run.

I commented here with more detail on the current consumption: https://developer.mbed.org/forum/mbed/topic/5863/?page=1#comment-38573 Thanks


1 Answer

6 years, 4 months ago.

The interrupt when waking from deepsleep is handled by the MCUs default clock, so thats generally an internal oscillator with no PLL engaged. This means your wait statements can take alot longer than they normally do, and is normal behavior.

That it does not start functioning the line after deepsleep() is a problem. Since it does wake up, it means the second part of the deepsleep() function, which sets the clock back to its normal value (which is why your interrupt runs with clock on different settings, only after the interrupt it is set correctly), apparantly locks up your code.

You can try an older version of the mbed lib (or if you already got that, the latest one). Due to some questionable values in the latest version it can take up to 10 seconds to enable the clock, but it should not completely lock up. Although when testing something I had it with the F401 take up to a minute, not a clue why it took that long.

Thanks for the suggestions. That makes sense about the waits in my interrupt taking longer because its using the MSI. I double checked older mbed libraries and it looks like Rev 89 is the last one that worked waking up from deepsleep. According to the comments Rev 90 they switched to the STMCube driver for the L152RE.

posted by Kevin Holland 29 May 2015

So thats not an easy to see change why it doesnt work anymore. I don't have the L152 myself, so I can't look into it directly. For now your best bet is probably to stick to rev 89, but if you run into other problems they might be solved in newer revisions.

posted by Erik - 29 May 2015

The main problem is that I am using an external Xtal instead of the Clock coming from the debug chip on my custom board. I fixed the clock startup issue by issuing this function instead of SetsysClock() when it wakes up from deep sleep...

static void SystemClockConfig_STOP(void)
  RCC_ClkInitTypeDef RCC_ClkInitStruct = {0};
  RCC_OscInitTypeDef RCC_OscInitStruct = {0};
  /* Enable Power Control clock */

  /* The voltage scaling allows optimizing the power consumption when the device is 
     clocked below the maximum system frequency, to update the voltage scaling value 
     regarding system frequency refer to product datasheet.  */

  /* Poll VOSF bit of in PWR_CSR. Wait until it is reset to 0 */

  /* Get the Oscillators configuration according to the internal RCC registers */

  /* After wake-up from STOP reconfigure the system clock: Enable HSI and PLL */
  RCC_OscInitStruct.OscillatorType      = RCC_OSCILLATORTYPE_HSE;
  RCC_OscInitStruct.HSEState            = RCC_HSE_ON;
  RCC_OscInitStruct.HSIState            = RCC_HSI_OFF;
  RCC_OscInitStruct.PLL.PLLState        = RCC_PLL_ON;
  RCC_OscInitStruct.PLL.PLLSource       = RCC_PLLSOURCE_HSE;
  //RCC_OscInitStruct.HSICalibrationValue = RCC_HSICALIBRATION_DEFAULT;
  RCC_OscInitStruct.PLL.PLLMUL          = RCC_PLL_MUL6;
  RCC_OscInitStruct.PLL.PLLDIV          = RCC_PLL_DIV2;
  if(HAL_RCC_OscConfig(&RCC_OscInitStruct) != HAL_OK)

  /* Select PLL as system clock source and configure the HCLK, PCLK1 and PCLK2
     clocks dividers */
  RCC_ClkInitStruct.ClockType = RCC_CLOCKTYPE_SYSCLK;
  if(HAL_RCC_ClockConfig(&RCC_ClkInitStruct, FLASH_LATENCY_1) != HAL_OK)
posted by Kevin Holland 12 Jun 2015