STM32WL: Radio BUSY Stays High; RADIO_GET_ERROR Can't Be Executed

[wanac_emb]

Hi Everyone,

We are developing a Sub-GHz/LoRa device based on STM32WLE5CCU6 and have encountered an issue related
to the Sub-GHz Radio BUSY state. We would like to ask for possible root causes and the recommended
recovery procedure.

The observed behavior is as follows:

1. After MCU peripheral initialization, we call MX_SubGHz_Phy_Init() and then Radio.Init() /
Radio.Sleep().
2. We then try to execute HAL_SUBGHZ_ExecGetCmd(&hsubghz, RADIO_GET_ERROR, ...).
3. The command keeps returning HAL_ERROR, and HAL_SUBGHZ_GetError(&hsubghz) returns 0x00000002, which
corresponds to HAL_SUBGHZ_ERROR_RF_BUSY.
4. We poll this command once per second for 10 seconds, and all attempts fail with the same error.
5. We also checked the PWR flags before. PWR_FLAG_RFBUSYS remains active, which indicates that the
current RF BUSY signal stays high.
6. PWR_FLAG_WRFBUSY can be cleared, but RFBUSYS remains high. Therefore, this does not look like a
pending wakeup/event flag issue, but rather the actual RF BUSY hardware status staying high.

Example log:

[RF_ERR] 1/10 Get_Error read failed | ret=1 hal_err=0x00000002
[RF_ERR] Meaning: command was not accepted; if hal_err has 0x00000002, RF BUSY is still active.
...
[RF_ERR] 10/10 Get_Error read failed | ret=1 hal_err=0x00000002

We would like to ask:

1. What are the typical causes for the Sub-GHz Radio BUSY signal on STM32WLE5CCU6 staying high?
2. Is there an ST-recommended software recovery sequence for this condition?
For example: HAL_SUBGHZ_DeInit() / HAL_SUBGHZ_Init(), RF reset, system reset, or any specific
initialization order.
3. If BUSY remains high, is there any way to read RADIO_GET_ERROR or other diagnostic information?
4. Is there any known errata, power/clock condition, or low-power wakeup condition that may cause the
Sub-GHz Radio BUSY line to get stuck?
5. Are there any mandatory timing requirements when using Radio.Sleep(), Stop2/Standby, or RF wakeup
related PWR settings?

Environment:

- MCU: STM32WLE5CCU6
- Radio: Embedded Sub-GHz Radio, LoRa mode, 470 MHz
- Software: STM32CubeWL / HAL SUBGHZ / SubGHz_Phy radio driver
- Issue: RF BUSY remains high, and all radio commands fail with HAL_SUBGHZ_ERROR_RF_BUSY

Please help us identify the possible causes and the recommended solution.
We can provide initialization code, full logs, and the relevant schematic section if needed.

Best regards,

[Saket_Om]

Hello @wanac_emb 

One important point in your sequence is that `RADIO_GET_ERROR` is executed after Radio.Sleep().  On STM32WL, once the Sub-GHz radio has entered Sleep mode, the command interface is typically not accessible until the radio is woken up using the proper wake-up procedure. Because of this, HAL_SUBGHZ_ExecGetCmd(..., RADIO_GET_ERROR, ...) may return HAL_ERROR with HAL_SUBGHZ_ERROR_RF_BUSY, and PWR_FLAG_RFBUSYS may remain asserted, even though the radio is not necessarily in a fault condition.  As a first check, we recommend testing the same sequence without calling Radio.Sleep() before RADIO_GET_ERROR. If the command works in that case, then the root cause is most likely the command being issued while the radio is still in Sleep mode or before the wake-up sequence has completed. 

[wanac_emb]

Hi @Saket_Om 

Thank you for the reply.

We understand that issuing RADIO_GET_ERROR after Radio.Sleep() may be invalid if the radio has not been woken up correctly.

However, we have now reproduced the issue without calling Radio.Sleep().

Our minimal test sequence is:

1. HAL_Init()
2. SystemClock_Config()
3. MX_USART1_UART_Init()
4. MX_GPIO_Init()
5. Disable SUBGHZ_Radio_IRQn
6. Disable radio busy/IRQ wake triggers
7. Clear WRFBUSY
8. Force and release SUBGHZ radio reset
9. Toggle SUBGHZSPI NSS low/high as a wake-up pulse
10. Wait several milliseconds
11. HAL_SUBGHZ_Init(&hsubghz) returns HAL_OK
12. Immediately execute RADIO_SET_STANDBY or RADIO_GET_STATUS

At step 12, the first radio command still fails with:

HAL_SUBGHZ_ERROR_RF_BUSY = 0x00000002

The observed status is:

- PWR_FLAG_RFBUSYS remains asserted
- PWR_FLAG_RFBUSYMS remains asserted
- PWR_FLAG_WRFBUSY can be cleared, but RFBUSYS stays asserted
- Software reset or RF reset does not recover this condition
- Powering the board completely off and then powering it on again can recover the condition

Example log:

[RF_MIN] radio reset release | RFBUSYS=2 RFBUSYMS=4
[RF_MIN] nss wake pulse done | RFBUSYS=2 RFBUSYMS=4
[RF_MIN] HAL_SUBGHZ_Init | ret=0 state=1 err=0x00000000
[RF_MIN] before SetStandby | RFBUSYS=2 RFBUSYMS=4
[RF_MIN] after SetStandby | ret=1 err=0x00000002

So the issue is not only related to executing a command after Radio.Sleep().
In this reproduced case, the radio is not intentionally put into Sleep before the first command.

Could you please advise the recommended handling when RFBUSYS remains asserted after RF reset and HAL_SUBGHZ_Init, while only a full power cycle can recover it?