Having issues enabling the SubGhzSPI on STM32WLE5JC

Kurt28 · ‎2022-12-31

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.

And this is what I see with identical firmware on the working board after MX_SUBGHZ_Init():

All 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

MCurry_VA · ‎2023-02-22

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.

Kurt28 · ‎2023-02-22

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.

MCurry_VA · ‎2023-03-02

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.

firmwareguru · ‎2023-06-28

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).

MCurry_VA · ‎2023-06-29

Glad it helped!

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

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)
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)
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.

Jens R · ‎2023-07-11

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: , 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).

firmwareguru · ‎2024-05-14

Glad I was able to help.

I am revisiting this again because I'm getting ready to deploy my bootloaders with RDP Level 2, and I don't want SPI3 to get locked out when RDP 2 is set by the bootloader (bootloader is doing this instead of, say, STM32CubeProgrammer, to mitigate "RDP Regression" attacks). I would like to get a root cause identified here... I have found an errata note that says option bytes are not loaded correctly if MSI clock is higher than 16 MHz. Again, not sure if this is responsible for the SPI3 issue, but in my configuration I am using MSI at 48 MHz when the HAL_FLASH_OB_Launch() function is called. There is also a prior HAL_FLASHEx_OBProgram call where presumably the RDP Level X setting is committed. The MSI clock issue may also be present with HAL_FLASHEx_OBProgram as well, or the SPI3 bit flip is actually happening at the time of HAL_FLASH_OB_Launch().

Anyways, thought I'd add this information. I will update with results after programming a few boards with this updated bootloader config (MSI down to 16 MHz before RDP Level 2 programming).

MCurry_VA · ‎2024-05-15

Something else I forgot to mention previously with our Option Byte issues was that we never managed to get HAL_FLASH_OB_Launch to work (for the second core's vector table on the WL54) and always has to power-cycle the chip for the new settings to take effect (we're also running >16MHz).

We've also noticed the STCubeProgrammer sometimes prompts needing to do this for some operations as well.

Until the chip is power-cycled, HAL_FLASHEx_OBGetConfig will always return the previous values, presumably from a shadow register.

EP.2 · ‎2024-07-18

@MCurry_VA wrote:
Something else I forgot to mention previously with our Option Byte issues was that we never managed to get HAL_FLASH_OB_Launch to work (for the second core's vector table on the WL54) and always has to power-cycle the chip for the new settings to take effect (we're also running >16MHz).

That's normal, depending on the bits being programmed, it's documented if you do a bit of a search you will find that only power reset will actually reload the OB, even a reset using the NRST is not enough. And for devices that have permanent batteries that can't power cycle, there's a workaround by putting the device into deep sleep and using the RTC alarm to wakeup to simulate the POR, achieving the same thing apparently (I've never tried it, but it's documented so hopefully that works for you).