Showing results for 
Search instead for 
Did you mean: 

Having issues enabling the SubGhzSPI on STM32WLE5JC


I have five identical development boards that I am attempting to bring up. One of the boards works without issues. The other four all fail during MX_LoRaWAN_Init(), After digging a little deeper I found that the SubGhzSPI peripheral is never getting enabled.

For non-working boards:

After calling MX_SUBGHZ_Init() all of SPI3/SubGhzSPI registers show 0x0 and I unable to change the values by writing to them.

0693W00000Y7A7qQAF.pngAnd this is what I see with identical firmware on the working board after MX_SUBGHZ_Init():

0693W00000Y7A7vQAF.pngAll of the other peripherals seem to be working correctly (I2C, ADC, SPI) but I cannot configure or enabled the SubGhzSPI (SPI3). I noticed the SubGhz SPI is the only peripheral on APB3. Is there any way to reset, reconfigure or test APB3?

Note: I am using the Seeed Wio-E5 STM32WLE5JC

Associate II

Did you ever get anywhere with this or was it put down to a fault chip?

I believe we're seeing the same symptoms - all SUBGHZSPI/SPI3 registers showing zero despite SUBGHZSPIEN flag being enabled in RCC.


I was never able to recover any of the units that had this issue. I was able to trace the issue down to one of two things that I may have been doing incorrect. First, when I was programming these chips for the first time I was using Hot Plug instead of Under Reset. Second, the power supply I was using to power the board was very cheap and low quality. Since switching to a better power supply and not using Hot Plug I have not had another unit fail. I am not sure which of the two was causing the issue for me.

Associate II

For other people finding this later, I've managed to resolve the issue on some boards by ensuring the SUBGHSPISD bit is SET in the option bytes to disable security on SPI3.

I've found what option bytes do on this chip (especially if self programming, e.g. for CPU2 vector table SBRV) very hit and miss as to whether something unintentional happens at the same time.

Associate II

Thanks for the post, I would have not come across this solution otherwise.  I'm working with the stm32wle5 and have a board exhibiting this exact issue.  This option byte (bit?) SUBGHSPISD is not documented nor normally accessible when device is viewed as a wle5.  However I found a way using STM32CubeProgrammer and register access mode to view the device as a wl5x and the bit shows up in the FLASH SFR register.  Setting this bit to 1 will grant access to SPI3 and the LoRa radio works again. 

As to why this happens...  I have a bootloader that is checking and setting RDP Level 1 using the standard HAL_Flash option byte APIs.  I'm wondering if this is related (only one board out of a few using this bootloader experienced this issue so far).



Associate II

Glad it helped!

For reference, the issues I had on the WL5x with option bytes were:

  1. When including option bytes in the hex file, ST-Link + STM32Cube Programmer would completely mess up what was programmed, often resulting in write protected regions being set and security options that required an Unlock Chip to resolve it.
    Programming the same hex file with a Segger J-Link and J-Flash Lite works perfectly.
    (For reference, we need to programme the option bytes on our target to ensure the BOOT0 pin is ignored)
  2. When self-updating from within the code, we were executing HAL_FLASHEx_OBGetConfig, making the changes (if an update was required) and then executing HAL_FLASHEx_OBProgram.
    The problem was that all the flags were set in FLASH_OBProgramInitTypeDef.OptionType - this needed updating to only have the flags set for elements that wanted changing (in our case C2SecureBootVectAddr, C2BootRegion and SUBGHZSPISecureAccess)
  3. When updating the C2SecureBootVectAddr, the only method found to work was to power-cycle the chip - using HAL_FLASH_OB_Launch or setting a wakeup timer and going in to STANDBY did nothing (old option bytes continued to be read and used).

I daresay a lot (if not all) of this behaviour present on the WL5x is also on the WLE5.

Hey, I can confirm that @firmwareguru 's approach is fixing our bricked STM32WLE5 modules with a blocked SPI towards the Radio.

So first and foremost: BIG THANKS for sharing the info how to revive the WLE5 SoC's!


I can add a few details we collected/checked after reading that post, since we had a couple "bricked ones" and coud "repair" each one of them:

In flash readback with segger j-flash (using "mem <start address> <amount of bytes to be read>" command) and reading more bytes than documented (we used J-Link> "mem 0x1FFF7800 128" in segger command line tool) for option bytes of the stm32wle5) in memory row indexed 0x1FFF 7870 the Bit 31 of this row (which is "SUBGHSPISD" as per STM32WL5x documentation and not used as per STM32WLE5 documentation) can be seen '1' if the module works, and can be seen '0' if it is bricked on the STM32WLE5 SoC/module.

Here a readback from the bricked module: JensR_1-1689076342453.png, the red marked area on a working module is 0x80 (i.e. bit 31 w.r.t 0x1FFF7870 as base address is '1')

However from our side we cannot explain why not every module has this problem because only some develop the problem during the first reboot after flashing (with segger j-flash), we never saw that issue happen later (i.e. on a second boot or even later).