Possible issue with LPM calls in generated code for STM32WB?

[crwper]

I've found something curious in the code generated by CubeMX for a BLE application on STM32WB. In APP_BLE_Init we have this:

/**
 * Do not allow standby in the application
 */
UTIL_LPM_SetOffMode(1 << CFG_LPM_APP_BLE, UTIL_LPM_DISABLE);

My understanding is that this prevents CPU1 from going into standby while CPU2 is booting. Then, in APPE_SysUserEvtRx, we have this:

UTIL_LPM_SetOffMode(1U << CFG_LPM_APP, UTIL_LPM_ENABLE);

Again, my understanding is that this is in response to a message from CPU2 indicating that it has finished booting, so standby mode can once again be enabled.

However, what I've just noticed is that these two calls use different IDs (the first disables standby mode for CFG_LPM_APP_BLE, and the second enables it for CFG_LPM_APP). The effect is that standby mode is never re-enabled when CPU2 finishes booting.

These are the only two calls to UTIL_LPM_SetOffMode in the generated code, so it seems unlikely that the change in ID is intentional--why would we see exactly one disable and one enable, but for different IDs?

Is this intentional, or a bug in the generated code? If it's intentional, can someone explain to me in a little more detail where the missing enable/disable for each ID should go?

Thanks!

Michael

[crwper]

I may have found a partial answer to my own question. In the BLE_HeartRate application, we have this additional call in APPE_Init:

/**
 * The Standby mode should not be entered before the initialization is over
 * The default state of the Low Power Manager is to allow the Standby Mode so an request is needed here
 */
UTIL_LPM_SetOffMode(1 << CFG_LPM_APP, UTIL_LPM_DISABLE);

So it appears the CFG_LPM_APP ID is controlled by the application in order to prevent the CPU from going into standby while initialization is in progress.

In addition, then, we have CFG_LPM_APP_BLE which is intended to prevent the CPU from going into standby starting just before CPU2 is booted.

In principle, we could allow standby as soon as CPU2 has finished booting (i.e., in response to APPE_SysUserEvtRx), but in this particular application we don't want the CPU to go into standby because the BLE application is still active (i.e., it is still advertising). A complete BLE application might enable standby, e.g., when it knows it's not going to be used for a long time.

Does that sound right?

Michael

[Christophe Arnal]

​Hello,

The idea is that standby is not supported while BLE is running on CPU2. In the case when you decide to no start the CPU2 so you are not using BLE, you may enter standby.

So roughly the concept is to say that standby is supported by the system but not by any BLE application.

CFG_LPM_APP refers to the system App. In order to make sure the standby is not entered while the system initialization is ongoing ( which I believe is likely not possible but ...), it is disabled at startup and enabled once the initialization is over as from a system point ov view, standby could be supported.

CFG_LPM_APP_BLE refers to the BLE Application. As soon as the BLE Application starts, it informs the low power manager that it does not allow the standby mode.

So at the end, as long as a BLE application is running, standby will never be entered because CFG_LPM_APP_BLE disabled it

Regards.

[crwper]

Hi Christophe--

Thanks for clarifying. My application will use BLE, but if it hasn't seen a connection for a long time (e.g., 18 hours), I thought I would have it drop into standby to conserve battery power. Once CPU2 has started, is it possible to signal it to shut down so we can go into standby mode? How would CPU2 be restarted in this case?

Michael

[Christophe Arnal]

​Hello,

The standby/shutdown mode is not supported when BLE is active.

The correct way to do this is that once you decided the standby/shutdown mode should be entered because of long RF inactivity, you need to stop all RF activity ( eg you shall stop all adversting, scanning activity you may have started and disconnect all link)

When this is done, you could just program your CPU1 to enter standby/shutdown mode ( CPU2 will not prevent this as it has nothing to do).

In that case, the way to wakeup is like all our STM32. (Wakeup pin, RTC, etc...).

On exit from, standby/shutdown, you shall restart CPU2 in the same way this is done out of power ON. There is no retention of any context on CPU2. From CPU2  point of view, standby/shudown shall be handled in the same way as Power ON.

Regards.

[crwper]

Thanks, Christophe!

Michael