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

[pieterconradie]

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(?):

But this is what I measured with a logic analyzer:

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

[TOUNSTM]

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,