STM32CubeWL icon indicating copy to clipboard operation
STM32CubeWL copied to clipboard

Too long hard coded delay in SUBGHZ_CheckDeviceReady()

Open pieterconradie opened this issue 1 year ago • 2 comments

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

pieterconradie avatar Mar 28 '23 06:03 pieterconradie

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

RJMSTM avatar Mar 29 '23 11:03 RJMSTM

Any update on this one?

MartinBP avatar Mar 08 '24 09:03 MartinBP