Low Power on STM32WB without 32KHz Crystal

[MSing.1713]

Greetings,

From what I've read of the Cube code and guidance in AN5289, we enter STM32WB low power states by putting the M4 into the low power state we want. If we need the M0 to continue to advertise, for example, we would configure it to do so and then put the M4 into low power.

I have two questions, related, to this use case.

1) Is this a correct understanding how how we are supposed to put the STM32WB into a low power state, e.g. stop2? Can we put the M4 into stop2 while waiting for a BLE connect event. When the event generates an interrupt, the M4 awakens and can handle to event. Does the M0 always go into low-power states? What triggers it?

Or, do we need to also send an explicit message to the M0 telling it we plan to go into low power? I haven't found any code doing this, but there is an SHCI opcode SHCI_OCF_C2_RADIO_ALLOW_LOW_POWER which is 0x6d. There doesn't seem to be an example that uses this code.

2) What will the M0 do when we are configured to use HSE for RF wakeup instead of LSE and put the M4 into a low-power state? I haven't found anything that explains this particular case. Will we get any power advantage from putting the M4 into STOP2 even if the M0 needs to keep somewhat active? What kind of power consumption should we expect?

Cheers

[Remi QUINTIN]

First of all, STOP2 mode is a system state meaning that both CPUs (M4 and M0+ cores) are in CSTOP (CPU stop) mode.

The application can control the power modes of the M4 (CRUN, CSLEEP or CSTOP) core but cannot do the same for the M0+ core. Those low power modes are managed by the RF stack depending on the RF activity.

When the application sends a command to the M0+ core, this core awaken if it was in allow power mode. In the same way, the M4 core is awaken if the M0+ core generates an event with an interrupt.

The M0+ core manages the RF block. At the end of any RF activity, the M0+ core automatically enters CTOP mode. If at the same time the M4 core is already in CTOP mode, then the system is considered as in CTOP2 mode.

Please have a look at the register manual, chapter 6. You’ll find the transition in between the power states of the system depending on the various power modes of both cores.

In one sentence, the application (M4 core) cannot control the power mode of the RF stack (M0+ core).

[MSing.1713]

Remi,

Thanks for the response.

How does the use HSE for RFWKPSEL change the available low power states for the M0+?

Cheers

[MSing.1713]

BTW, according to the RM, the M4 explicitly selects STOP0, STOP1, or STOP2. We don't select a generic CSTOP mode. What I think you are explaining is that the processor as a whole will not necessarily enter STOP2 if the M0+ or RF subsystem is active and not in CSTOP. I also take this to mean that the BLE stack is designed to go into STOP mode when idle.

[Remi QUINTIN]

Selecting HSE as clock source at wakeup does not have any impact on the selected power mode.

Note that for any RF activity, the HSE clock is mandatory. Shortly after wakeup, the HSI clock is used to let some time for the HSE clock to start properly and stabilize with an accuracy below 50ppm which is the requirement for the RF block to correctly work.

[Remi QUINTIN]

>the M4 explicitly selects STOP0, STOP1, or STOP2. We don't select a generic CSTOP mode

Please have look at the register manual

figure 12 : low power modes transitions.

This figure shows the underlying relation of all 3 STOP modes with the CSTOP mode of the 2 cores and the RF block.

Your understanding is correct.

[MSing.1713]

Yes, I have reviewed figure 12 and I see what you mean. This chart lumps all of the STOP types (1,2,3) into a single transition, C1STOP vis a vis LPMS in PWR_CR1.

I suspect that the detail of managing HSE is absent from these charts. I tried code that worked on a previous design where we enter STOP with the BLE stack advertising. In this current design, I believe because no LSE is available, when the M4 enters STOP it shuts down the HSE which means the BLE stack cannot continue to advertise because the rfwakeup source is powered down. My hunch is that the best I'll be able to do is LP SLEEP with this particular design. From the status registers, I can tell that the M0+ is in the SHUTDOWN state.

When we were qualifying this design, ST engineers mentioned that we would not be able to use the best low-power states without an LSE. This was not originally a concern for us. Yet, none of the engineers was explicit in what they meant. I had hoped that the WB would manage this particular detail and keep HSE active when the M4 chooses STOP with RFWKUP selecting HSE, but that appears to not be the case. It would be fine for our purpose to shutdown everything except HSE in this state. I can imagine that the /plan/ was to depend on one of the LSI RC oscillators in this situation. It didn't pan out in the silicon.

[Remi QUINTIN]

I would not expect the HSE clock to be switched off if it was still used by the M0+ or the RF block.

The management of the HSE is centralized. It would only by really switched off if no HW component is using it.

So, the BLE stack should not be stopped due to the loss of this HSE clock. The reason is somewhere else.

Note that if the LSE is stopped, this can greatly disturb the RF activity as it is based on precise timings managed by the RTC whose source clock is indeed the LSE.

So I would recommend you better have a look on this side.

[MSing.1713]

According to other technical staff at ST, my hunch is correct:

If you're not using an LSE, you can only go down to SLEEP mode, if you want to keep the BLE link active. This is because in STOP mode, the HSE oscillator is disabled, leaving you with no clock feed, but in SLEEP mode, the HSE remains enabled, so you can enter this mode during your idle periods.

As previously discussed, the radio and M0 enter a low power state automatically. If we also let the M4 enter STOP, we will also induce the HSE to shutdown which leaves the M0 without a wakeup clock. Only the LSE can be used to wakeup the M0 when both processors are in STOP.

Cheers

[Remi QUINTIN]

Maybe I misunderstood your question.

Indeed, the LSE clock is mandatory for the RTC which gives the time base for all timers in the system and especially those used to wake up the M0+ and the RF block.