cancel
Showing results for 
Search instead for 
Did you mean: 

How to enter SLEEP/STOP mode on STM32WB device ?

JGUIT.1
Associate III

Hello,

I wonder how the STM32WB device should be entered in SLEEP or STOP mode. Any specific actions to reduce the total consumption to the minimum, particularly thinking to the radio? When is it good to enter SLEEP or STOP mode ?

If anyone can point a working example, it will be great :)

Context : I have Thread (and in near future BLE+Thread) running on my device. I would like to put the total consumption to the minimum because the board is supplied with a small battery. Then periodically the device is wake-up, processing, sending data to the Thread network and finally goes to STOP mode again.

Thanks,

Joel

16 REPLIES 16

​Hello Scott,

 I understand you are referring to that code before entering Stop Mode 2

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( ) )
    {
      /* Release ENTRY_STOP_MODE semaphore */
      LL_HSEM_ReleaseLock( HSEM, CFG_HW_ENTRY_STOP_MODE_SEMID, 0 );
 
      /**
       * The switch on HSI before entering Stop Mode is required 
       */
      Switch_On_HSI( );
    }
  }
  else
  {
    /**
     * The switch on HSI before entering Stop Mode is required 
     */
    Switch_On_HSI( );
  }

The purpose of this code is not to decide if we are allowed to enter Stop Mode or not. Whatever we are doing there, the decision has already been taken to enter Stop Mode.

The purpose of this code is to understand if we can switch on HSI or not before entering Stop Mode.

There are two points to check :

1/ We are checking C2DS because we dont want to switch on HSI if CPU2 is running as it requires a 32Mhz Clock.

2/ As both CPU are almost running the same algorithm, if each of them checks at the same time the CxDS bit, none of them will switch on HSI whereas they are both on the way to enter Stop Mode. The "Strange" use of CFG_HW_ENTRY_STOP_MODE_SEMID semaphore is there to handle this corner cases.

Now the only point is the reason why to switch on HSI before entering Stop Mode 2. This was mandatory on Cut2.0 and the bug is fixed on Cut2.1. Unless you get some board at mass market launch during some workshop, you should have a Cut2.1 board.

The workaround has been kept for Cut2.1 because it does not hurt and all our validation have been executed with the workaround. Therefor, it is recommended to keep it for safety.

Regards.

​Hello Scott,

If you decide to not switch on HSI before entering Stop Mode, then it is fine to skip all the code I have listed above.

Just take care that the code is running in critical section and I am affraid  sysClkCfg() is quite long.

Most of the time, there is just a couple of things to do to recover the clock so I would not go with the generic API to speed up the code in critical section but just use the required LL.

Regards.

Christophe Arnal
ST Employee

​Hello Scott,

Here is the way it works :

As described in chapter 6.4 Low-power modes of the reference manual (Fig12), there is the concept of CSTOP and STOP.

The concept of CSTOP is basically the Stop Mode of one CPU subsystem when the DEEEPSLEEP bit of this CPU has been set and the CPU is in WFI ( in cour case). In that case, for the CPU in CSTOP, the CPU is not running and its clock tree is gated.

The concept of STOP applies to the whole system. When both CPUs are in CSTOP ( and there is no RF activity). In that case, both CPU are not running, both clock tree are gated and in addition, the system clock is switched OFF - this is basically the Stop Mode well known on any STM32 device.

According to the reference manual, the  IWDG  depends on the STOP Mode so in between BLE connection interval, the IWDG is not clocked because the full device is in Stop Mode but during Radio Activity, IWDG will receive a clock during the radio event because the system is not is STOP mode.

In order to check this, the timeout should depend on the BLE interval. You may try with a very short BLE interval versus a very long interval and you should see a significant change in the Timeout.

Regards.

Scott Löhr
Senior II

@Christophe Arnal​ thank you for the valuable details which enable a great understanding of this system - a virtual white paper is being written among the posts in this group thanks to expert input from folks like you!

Scott Löhr
Senior II

@JGUIT.1​ don't you think that this question should be marked as "Answered"?

​Hello @Scott L�hr​ ,

I have just been told that the WWDG should behave as you expect. It is only linked to CPU1 activity

Regards.

RPowe.1
Associate II

I am going through the same pain. I have created an empty project for Nucleo ST32WB55. I have removed JP2 to monitor the current.

The current is around 1mA at start and drops to 0.84mA when I drop MSI to 1MHz.

I set all GPIO to analog input and turn off all peripheral clocks. Power doesn't drop which is not surprising as the code has just started so it's around 0.84mA.

I then do the following:

HAL_SuspendTick();

DBGMCU->CR = 0; // Disable debug and trace in low-power modes

LL_PWR_SetPowerMode(LL_PWR_MODE_STOP2);

LL_C2_PWR_SetPowerMode(LL_PWR_MODE_SHUTDOWN);

HAL_PWR_EnterSTOPMode(PWR_LOWPOWERREGULATOR_ON, PWR_STOPENTRY_WFI);

I lose debug which is what I expect.

The power drops to 0.666mA! 

From this I conclude that it's not entering stop mode.

What am I doing wrong?

I've tried turning on HSI before going to sleep and that makes no difference.

Thanks, Rich