SUBGRF_SetTx() & SUBGRF_SetRx(): SUBGHZ_WaitOnBusy() long blocking delay in HAL_SUBGHZ_ExecSetCmd()

Hi there!

I have identified the issue in STM32CubeWL V1.3.0. See here: https://github.com/STMicroelectronics/STM32CubeWL/blob/main/Drivers/STM32WLxx_HAL_Driver/Src/stm32wlxx_hal_subghz.c#L1000

When SUBGRF_SetTx() or SUBGRF_SetRx() is called, it blocks for a long time (~1.2 ms) until the BUSY line goes low. The blocking delay is in HAL_SUBGHZ_ExecSetCmd() where SUBGHZ_WaitOnBusy() is called after the SET_TX (0x83) or SET_RX (0x82).

The long blocking delay prevents other code from executing or the processor core from going to sleep which wastes battery power. The consequence is even worse when SUBGRF_SetTx() or SUBGRF_SetRx() is called inside an interrupt.

I recommend that the blocking delay be removed and a separate polling function added to find out when the command has finished or that the blocking delay be moved to the start so that subsequent commands will wait until the previous one has finished. In most cases this will eliminate the unnecessary delay. I see that there is a HAL_SUBGHZ_STATE_BUSY but it does not look like it was properly implemented with this in mind (?).

UPDATE: I am developing on a NUCLEO-WL55JC1 board. According to the SX1261/2 datasheet the delay is not supposed to be that long(?):

table_8 2_switching_time

But this is what I measured with a logic analyzer:

set_rx_delay

Is there an explanation for the longer than expected blocking delay? Could it have to do with the DC-DC + TCXO as opposed to the LDO + Crystal option?

Thanks in advance, Pieter https://piconomix.com

STMicroelectronics / STM32CubeWL

SUBGRF_SetTx() & SUBGRF_SetRx(): SUBGHZ_WaitOnBusy() long blocking delay in HAL_SUBGHZ_ExecSetCmd() #70