STME32WLE SUBGHZSPI Bit stuck at 0
Hello STM Community,
We are developing a battery-powered iot product using the STM32WLE5 (single-core variant) with LoRaWAN communication.
Problem Description
After an under-voltage event, the SUBGHZSPI bit gets permanently stuck at 0. The radio becomes completely unresponsive.
Key observations:
- The issue **persists across full power cycles** (battery removed for minutes, capacitors fully discharged)
- A **software system reset** (`NVIC_SystemReset()`) does NOT fix it
- **Re-flashing the firmware** does NOT fix it
- The only known fix is using STM32CubeProgrammer
- To Reset the bit ( Done in the picture below ). The error is SUBGHSPISD stuck to 0.
- Once we set the bit to 1 we can resume normal operation.
-
What we have tried (without success):
1.RF subsystem reset via RCC_CSR_RFRST
LL_RCC_RF_EnableReset();
// delay
LL_RCC_RF_DisableReset();
// wait for RFRSTF to clear
2. SUBGHZSPI peripheral reset (APB3 bus):
__HAL_RCC_SUBGHZSPI_FORCE_RESET();
// delay
__HAL_RCC_SUBGHZSPI_RELEASE_RESET();
3. NSS manipulation:
LL_PWR_SetSUBGHZSPI_NSSSource(LL_PWR_SUBGHZSPI_NSS_SRC_SW);
LL_PWR_UnselectSUBGHZSPI_NSS();
4. Clearing RFBUSY flags:
LL_PWR_ClearFlag_RFBUSY();
5. Re-writing option bytes from firmware + OBL_LAUNCH:
HAL_FLASHEx_OBGetConfig(&obConfig);
obConfig.OptionType = OPTIONBYTE_USER;
obConfig.UserType = OB_USER_ALL;
HAL_FLASHEx_OBProgram(&obConfig);
HAL_FLASH_OB_Launch(); // triggers system reset
6. Combinations of all the above
None of these approaches recover the radio from firmware. Only STM32CubeProgrammer's Option Byte "Apply" action resolves it.
Important constraints
- We are using the STM32WLE5, NOT the dual-core STM32WL55. On the dual-core variant, there is the `FLASH_SFR_SUBGHZSPISD` bit and `OPTIONBYTE_SUBGHZSPI_SECURE_ACCESS` which can control Sub-GHz SPI access. These do not exist on the single-core WLE5.
- Once we start industrial production fixing the issue using STM32CubeProgrammer will not be a viable option. We need a solution to either prevent this bit to toggle to 0 or to set it to 1 during runtime.
Questions
1. Is this a known errata for this issue?
2. Is there a HAL function or register sequence that can recover the SUBGHZSPI from this stuck state without external tools?
3. What exactly does STM32CubeProgrammer do differently when applying option bytes that a firmware-based `HAL_FLASH_OB_Launch()` does not achieve?
4. Has anyone encountered this on the single-core variant and found a working solution?
Environment
- MCU: STM32WLE5 (single-core, Cortex-M4)
- Package: STM32WLE5JC
- HAL version: STM32WLxx HAL Driver
- IDE: Keil MDK (uVision)
- Programmer: STM32CubeProgrammer (recovery tool)
Looking forward for this discussion.
I know it is not the first time this question gets asked but nothing solved my problem properly. And to be honest by now i expect an official document from STM.
Thank you.
