BLE, sleep mode and HSE

That low-power mode code is broken, because it doesn't disable interrupts on a CPU, when it goes into low-power mode. As a result after wake-up before the clock configuration is complete any interrupt can run it's service routine and do things that probably should not be done in that MCU state. A proper example is there:

https://community.st.com/t5/stm32-mcus-motor-control/mc-sdk-not-work-with-mcu-stop-mode/m-p/94522

https://community.st.com/t5/stm32-mcus-embedded-software/how-to-enter-standby-or-shutdown-mode-on-stm32/m-p/145849

Yes, all (HAL library, CubeMX generated and examples) of ST's low-power related (and most of other) code is broken. It is explained in the links I gave. Read those!

And you are talking about "sleep mode", but most likely are using a Stop mode. Anyway all of the modes, including what exactly they do, are explained in the reference manual.

Hello,

On STM32WB in BLE example, depending on low power mode used, HSE clock is disable or not. In sleep mode, HSE clock still enable and in stop mode and deeper mode, HSE clock is disable. 

During advertising, CPU1 has nothing to do, CPU1 is in CSTOP, only CPU2 wakes up to manage the advertising.

When debugger is enabled, DBG_SLEEP and DBG_STOP bits of DBGMCU_CR register are set. When DBG_STOP bit is set: "Automatic clock stop disabled. All active clocks and oscillators continue to run during STOP mode, allowing full CPU1 debug capability. On exit from STOP mode, the clock settings are set to the STOP mode exit state."

In your case, you can disable the debugger and output HSE clock on MCO to see the right behavior.

Best Regards

Ok, I did some more testing.

I think I observed that the HSE is activated before CPU1 wakes up from sleep mode.

CPU1 does wake up from sleep mode after advertising.

I set a test pin (LED_FLASH) high and low directly after _WFI(), so I can see when the microcontroller wakes up.

void PWR_EnterStopMode(void)
{
/* USER CODE BEGIN PWR_EnterStopMode_1 */

/* USER CODE END PWR_EnterStopMode_1 */
 /**
 * When HAL_DBGMCU_EnableDBGStopMode() is called to keep the debugger active in Stop Mode,
 * the systick shall be disabled otherwise the cpu may crash when moving out from stop mode
 *
 * When in production, the HAL_DBGMCU_EnableDBGStopMode() is not called so that the device can reach best power consumption
 * However, the systick should be disabled anyway to avoid the case when it is about to expire at the same time the device enters
 * stop mode (this will abort the Stop Mode entry).
 */
 HAL_SuspendTick();

 /**
 * This function is called from CRITICAL SECTION
 */
 EnterLowPower();

 /************************************************************************************
 * ENTER STOP MODE
 ***********************************************************************************/
 LL_PWR_SetPowerMode(LL_PWR_MODE_STOP2);

 LL_LPM_EnableDeepSleep(); /**< Set SLEEPDEEP bit of Cortex System Control Register */

 /**
 * This option is used to ensure that store operations are completed
 */
#if defined (__CC_ARM)
 __force_stores();
#endif
// LED_FLASH_GPIO_Port->BRR = (uint32_t)LED_FLASH_Pin;
 __WFI();

/* USER CODE BEGIN PWR_EnterStopMode_2 */
 LED_FLASH_GPIO_Port->BSRR = (uint32_t)LED_FLASH_Pin;
 	 for(uint32_t i; i<32; i++)
 	 {
 		 __asm__("nop");
 	 }
 LED_FLASH_GPIO_Port->BRR = (uint32_t)LED_FLASH_Pin;
/* USER CODE END PWR_EnterStopMode_2 */
 return;
}

I also measured the current consumption, so I can see when the microcontroller is advertising.

Interesting to see is that the microcontroller seems to stars advertising before CPU1 wakes up.

I also connected CH1 to the MCO to observe the clock change:

How does it do that? I thought the HSE is "actuated" by the CPU1? Here we clearly see, that the HSE is running before CPU1 wakes up, which confirms my findings from previous posts.

If I wake up the microcontroller with a timer task, then it first wakes up and then starts the HSE:

Would someone please confirm my findings?

Why is the wake up handler for CPU1 triggered after all, when CPU2 can do the advertising (and activation of HSE) by itself?

Does that mean that I cannot use an external clock (like the ECS-3225MV) if I want to turn it on and off during sleep? I thought about: When entering low power and switching to HSI, I turn off the external clock, go to sleep, when advertising is triggered, I activate the external clock again, wait till it is ready, then advertise.

With regard to my observation this does not seem to be possible. So is the Bypass function for OSC_IN just in case you want to connect an external clock and keep it turned on?

In the datasheet of the STM32WBXX you find the different sleep modes and what peripherals are active during these sleep modes. Usually, if you are using the low power manager (from CubeIDE), the HSE is deactivated in STOP1 mode I think.
But how do you want to use UART during sleep? To send something, you would have to wake up, activate HSE, do your stuff like:

static void ExitLowPower(void)
{
 /* Release ENTRY_STOP_MODE semaphore */
 LL_HSEM_ReleaseLock(HSEM, CFG_HW_ENTRY_STOP_MODE_SEMID, 0);

 while(LL_HSEM_1StepLock(HSEM, CFG_HW_RCC_SEMID));

 if(LL_RCC_GetSysClkSource() == LL_RCC_SYS_CLKSOURCE_STATUS_HSI)
 {
/* Restore the clock configuration of the application in this user section */
/* USER CODE BEGIN ExitLowPower_1 */

	 LL_RCC_HSE_Enable( );
	 __HAL_FLASH_SET_LATENCY(FLASH_LATENCY_1);
	 while(!LL_RCC_HSE_IsReady( ));
	 LL_RCC_SetSysClkSource(LL_RCC_SYS_CLKSOURCE_HSE);
 //LL_RCC_SetSMPSClockSource(LL_RCC_SMPS_CLKSOURCE_HSE);
	 //LL_RCC_SetADCClockSource(LL_RCC_ADC_CLKSOURCE_SYSCLK);
	 while (LL_RCC_GetSysClkSource( ) != LL_RCC_SYS_CLKSOURCE_STATUS_HSE);

/* USER CODE END ExitLowPower_1 */
 }
 else
 {
/* If the application is not running on HSE restore the clock configuration in this user section */
/* USER CODE BEGIN ExitLowPower_2 */

/* USER CODE END ExitLowPower_2 */
 }

 /* Release RCC semaphore */
 LL_HSEM_ReleaseLock(HSEM, CFG_HW_RCC_SEMID, 0);

 return;
}