cancel
Showing results for 
Search instead for 
Did you mean: 

BLE Operation in Low Power Modes on STM32WB

JR2963
Senior II

Hi,

I'm not sure if I fully understand how the low-power mode works with active BLE on the STM32WB. I have an application using FreeRTOS and the BLE stack. I have set up advertising and am able to send and receive data over BLE. This works fine. When CPU1 enters Sleep mode — since it has no tasks to handle — BLE seems to work correctly. However, if it enters STOP2 mode instead of Sleep, it stops working properly. 

Questions:
1) If I have BLE advertising set with a period of around 100 ms, can I put CPU1 into STOP(2) mode? Will CPU2 and the radio handle the operations on their own while CPU1 is in STOP mode? If so, will they wake up CPU1 as well? 

2) If someone has already connected to my device via BLE, can I also put CPU1 into STOP mode?

3) To entering STOP mode I use funcion from example - hope it is correct?

Some of my research:

In RM0434, it is stated that the system will enter low-power mode only when all three subsystems allow it (CPU1, CPU2, Radio Subsystem). A few lines below, it says that these three subsystems can enter and exit low-power mode on their own (page 154).

At the same time, the table here shows that CPU2 cannot run in STOP mode, but the radio can wake up the entire system if needed.

 

JR2963_0-1726493511723.png

In AN5289, it is mentioned that the wireless firmware automatically sets the best low-power mode configuration for CPU2 as soon as CPU2 is started.

In the HeartRate Monitor example, `UTIL_LPM_SetOffMode(1 << CFG_LPM_APP, UTIL_LPM_DISABLE);` is called before initializing BLE, and OffMode is enabled again after the initialization is complete.

 

static void EnterLowPower(void)
{
  /**
   * This function is called from CRITICAL SECTION
   */

  while(LL_HSEM_1StepLock(HSEM, CFG_HW_RCC_SEMID));

  if (! LL_HSEM_1StepLock(HSEM, CFG_HW_ENTRY_STOP_MODE_SEMID))
  {
    if(LL_PWR_IsActiveFlag_C2DS() || LL_PWR_IsActiveFlag_C2SB())
    {
      /* Release ENTRY_STOP_MODE semaphore */
      LL_HSEM_ReleaseLock(HSEM, CFG_HW_ENTRY_STOP_MODE_SEMID, 0);

      Switch_On_HSI();
      __HAL_FLASH_SET_LATENCY(FLASH_LATENCY_0);
    }
  }
  else
  {
    Switch_On_HSI();
    __HAL_FLASH_SET_LATENCY(FLASH_LATENCY_0);
  }

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

  return;
}

 

 

 and finally enter STOP:

 

 

LL_PWR_SetPowerMode(LL_PWR_MODE_STOP2);
LL_LPM_EnableDeepSleep(); 
 __WFI();

 

 

 @STTwo-32  @Piranha @waclawek.jan Thank you very much for help.

3 REPLIES 3
STTwo-32
ST Employee

Hello @JR2963 

1) You can put CPU1 into STOP2 mode while BLE advertising. The CPU2 and the radio will handle the BLE operations on their own. 

2) If someone has already connected to your device via BLE, you can still put CPU1 into STOP2 mode. The CPU2 will manage the BLE connection and will wake up CPU1 when necessary.

3) You can refer to the PWR examples of the STM32CubeWB V1.20.0 for more details.

Best Regards.

STTwo-32

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

Thank you for the response. I probably have a hidden error somewhere, because when I start entering STOP2 mode, BLE starts to malfunction rather than work properly—connecting via BLE becomes nearly impossible. I have advertising set to around 100 ms, but in STOP2 mode, I see the period increase significantly to: 1.5 seconds, 4.56 seconds, and similar values. As far as I know, CPU2 (BLE stack) should handle this timing independently of the state of CPU1? @STTwo-32 

Hello @JR2963 

CPU2 should handle all BLE functions and parameters for the integrated BLE.

Best Regards.

STTwo-32 

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.