Too long hard coded delay in SUBGHZ_CheckDeviceReady()

[pieterconradie]

Hi there!

I'm referring to stm32wlxx_hal_subghz.c SUBGHZ_CheckDeviceReady(): https://github.com/STMicroelectronics/STM32CubeWL/blob/main/Drivers/STM32WLxx_HAL_Driver/Src/stm32wlxx_hal_subghz.c#L1743-L1766

The SUBGHZ_NSS_LOOP_TIME constant is defined here: https://github.com/STMicroelectronics/STM32CubeWL/blob/main/Drivers/STM32WLxx_HAL_Driver/Src/stm32wlxx_hal_subghz.c#L156-L159

If the SX126x is put to sleep with SUBGRF_SetSleep() then a hard coded delay loop is used to wake it up before proceeding.

How does the SUBGHZ_NSS_LOOP_TIME constant relate to actual delay time? I measured the time and it was way too long (2ms - 3 ms).

I searched the SX1261/2 datasheet for proper timing values, but could only find that the max "reaction time" for the BUSY line to go high is 600 ns: 8.8.1 BUSY Control Line page 53: "The max value for TSW from NSS rising edge to the BUSY rising edge is, in all cases, 600 ns." Table 8-2: Switching Time page 54: "SLEEP to STBY_RC warm start (with data retention) 340 us"

Here is my pseudo code to avoid the unnecessary long delay:

void rf_modem_wake(void)
{
    LL_PWR_SelectSUBGHZSPI_NSS();
    delay_us(10);
    LL_PWR_UnselectSUBGHZSPI_NSS();
    delay_us(10);
    while(LL_PWR_IsActiveFlag_RFBUSYMS() & LL_PWR_IsActiveFlag_RFBUSYS()) {;}

    hsubghz.DeepSleep = 0;
}

I recommend that these delays that are dependent on compiler optimization (?) be fixed to improve the impact on battery life.

Best regards, Pieter https://piconomix.com

[RJMSTM]

Hello @pieterconradie,

Thank you for this report. We will get back to you as soon as we analyze it further. This may take some time. Thank you for your comprehension.

With regards, Rania

[MartinBP]

Any update on this one?

[KRASTM]

hello @pieterconradie,

Sorry for the very late response and thank you for the report.

Regarding your issue, the wake up is indeed long it's around 3.5 ms, but it's mentioned in the RM0453 page 175.

Below an extract for the switching time,

Also, I checked with our team; we must wait the typical time to ensure proper wakeup. But for your case, if it works with lower time, you can make the change that suit your application.

Please, allow me to close this thread.

With regards.