Deep sleep is never achieved with SUBGRF_SetRxDutyCycle

[vrAntoine]

I was trying to use SUBGRF_SetRxDutyCycle, and I noticed that my current consumption in the radio sleep phase is higher than when I call the sleep through SUBGRF_SetSleep. I measure 77.55uA in the sleep phase of the Rx duty cycle, and 2.10uA if I call SUBGRF_SetSleep.

After some investigation, I have found that the difference is the Radio RF switch set to RBI_SWITCH_RX in SUBGRF_SetRxDutyCycle, while it is set to RBI_SWITCH_OFF in SUBGRF_SetSleep. In the paper, everything seems all right because in the RX duty cycle process, we want the RF switch set to RBI_SWITCH_RX during the awaken phase. However, by doing a workaround, I was able to set the sleep phase consumption to 2.82uA and still have my listen window working fine.

My workaround:

In HAL_SUBGHZ_ExecSetCmd I force back the switch to RADIO_SWITCH_OFF if a sleep status is set. https://github.com/STMicroelectronics/stm32wlxx-hal-driver/blob/a496d1eebd7394fb880ebfdd56fdcb5f2cce687b/Src/stm32wlxx_hal_subghz.c#L978

if ((Command == RADIO_SET_SLEEP) || (Command == RADIO_SET_RXDUTYCYCLE))
    {
      HAL_RADIO_SetSwitchConfig (RADIO_SWITCH_OFF);
      hsubghz->DeepSleep = SUBGHZ_DEEP_SLEEP_ENABLE;
    }

This seems to continue to work fine because, from the SX1261/2 datasheet p77 (datasheet link):

When this command [SetRxDutyCycle] is sent in STDBY_RC mode, the context (device configuration) is saved and the chip enters in a loop ...

At the end of the SLEEP window, the chip automatically restarts the process of restoring context en enters the RX mode, and so on.

I guess the initial RF switch status is saved when the Rx duty cycle is set and restored every time the Rx window is entered again.

Can somebody try to reproduce this workaround and validate that the listening window continues to work as expected ? If everything is working without issue, is it possible to add the workaround in the next version ?

[vrAntoine]

I have conducted some testing with the proposed workaround, and there is one major issue: a significant amount of reception sensitivity is lost.

In fact, the communication is working on the working desk, but it's not the same case outside. The communication range is reduced by 4 in my use case.

I attempted to enhance the workaround by utilizing the busy signal from the SX126x as an interrupt to change the RF switch, but I was still consuming too much current in the process.

To summarize:

The proposed workaround should not be implemented, but the consumption issue still exists. Is it possible to change the RF switch without waking up the STM32? Or if a solution with a quick wake-up is proposed, the global current consumption shall be below the current driver version without changes in the RF switch.

[vrAntoine]

Last update on this issue for me. I have implemented a change on the RF switch through the BUSY signal from the SX126x. The BUSY signal is high when the RF module is in sleep and low when it is ready to receive RF data (chapter 8.3.1 from SX126x datasheet). It seems that the BUSY signal is well commanded during the Rx duty cycle phase. I had to use the busy IRQ on the falling edge, because the rising one was making consume my board 1mA passively.

While the switch command seems coherent with what was expected, my radio range tests in the field were not convincing. Indeed, I had similar results after this workaround as with the previous one, where the RF switch was kept at OFF status.

Here is a consumption graph of the STM32WL5 I used

To estimate the RF switch status, I mimicked its command to another GPIO and sampled it with a power profiler kit. I commanded the reception to be 1.2ms long, and the GPIO switch came after 420µs.

I have no other solution to propose, so I will wait for an update on the bug.

[MKISTM]

Hello @vrAntoine,

Thank you for your contribution. I have tried to reproduce the issue but was unable to do so. Could you please provide more details about the problem? Specifically, could you share your code modifications and clarify the description of the issue?

BR, Mohamed Chaker.

[vrAntoine]

Hello @MKISTM,

The issue is quite simple to reproduce on my setup. I am using a STM32WL5MOCH6TR, but I am pretty confident that the issue is not MCU-dependent. The SubGHz_Phy_Per example can be used as a starting point. You also need something to read the MCU current consumption. I use the Power Profiler Kit II from Nordic.

First, put the MCU in STOP mode, and read the MCU current consumption (should be around 1µA). I placed these lines as the first instructions of the Per_Process function: Radio.Sleep (); // just to be sure radio module is not active HAL_SuspendTick (); HAL_PWREx_EnterSTOP2Mode (PWR_STOPENTRY_WFI);

Then, change the radio sleep line to have the following instructions: Radio.SetRxDutyCycle (1000, 5000); // values are chosen arbitrarily, it's just for the example HAL_SuspendTick (); HAL_PWREx_EnterSTOP2Mode (PWR_STOPENTRY_WFI);

The current measured in the second case should be around 6mA during 1 second, and around 75µA during 5 seconds. I would expect to have a current consumption during these 5 seconds similar to the 1µA measured previously.

[Prasadh-P]

After some investigation, I have found that the difference is the Radio RF switch set to RBI_SWITCH_RX in SUBGRF_SetRxDutyCycle, while it is set to RBI_SWITCH_OFF in SUBGRF_SetSleep. In the paper, everything seems all right because in the RX duty cycle process, we want the RF switch set to RBI_SWITCH_RX during the awaken phase. However, by doing a workaround, I was able to set the sleep phase consumption to 2.82uA and still have my listen window working fine.

Hello there, Can you let me know how were you able to achieve consumption down to 2.82uA i was only able to get it down to only 40uA using Stop2 Mode. For reference i am using STM32WLE5 MCU and Lora stack for my application i have pulled all the unused gpio pins to analog mode to prevent gpio floating and using stop2 mode for low powersleep. Could you let me know what else were you able to do to achieve the 2.82uA consumption at sleep Thanks in Advance!

[vrAntoine]

Hello @Prasadh-P

My first bet would be that you may not have put the embedded radio module in the STM32WLE5 also in sleep mode. The SX126X chip used to handle the radio is autonomous with the main STM32 chip. This radio module can run in three main modes: sleep, standby, and Rx/Tx. By default, after the init procedure, the radio module is put in standby mode, which makes it consume some current. Put the module in sleep, and you should reach 1µA in order of magnitude.

To do so, you need to call Radio.Sleep (); before putting the STM32 in STOP mode. As long as you don't use the RxDutyCycle feature, you should not face the same consumption issue I explained in this bug.

If you still have a few dozen µA, the cause could be multiple. I would suggest commenting out most of the code in your main.c and uncommenting it step by step to find which part of your project is adding consumption

[MKISTM]

ST Internal Reference: 224476