SUBGHZSPI_Transmit return HAL_SUBGHZ_ERROR_TIMEOUT when using the LoRa-E5 board with a STM32WLE5

[Hugo_VOLA]

Hello,

After prototyping with a Nucleo STM32WLJC, I start to use LoRa-E5 board from Seedstudio with a STM32WLE5 MCU.

I want to make a P2P communication, so I'm trying to make a ping pong project on this board.

I tried starting from seeds LoRaWan exemple, from ST pingpong exemple and also from this repo project and .ioc file(https://github.com/danak6jq/Seeed-LoRa-E5).

But It's not working...

After debuging I find out that in SUBGHZSPI_Transmit function, a timout error occured while waiting for TXE flag to be set.

I can't find any others exemples to compare the configuration...

Does anyone have a idea about whats happenning ? Or a tips that can make me move forward ?

Thanks

Hugo

[EP.2]

I also have the same timeout problem. Did anyone find a solution? WIO E5 was working fine, now it just stopped working and always just gets the SUBGHZSPI_Transmit() HAL_SUBGHZ_ERROR_TIMEOUT errors. I have a 2nd module, it's still working fine with the same code.

[EP.2]

Ok thanks for getting back to me, sounds like there's no way to fix it after it has gone bad. What's strange is that in the debugger, the SUBGHZ SPI registers all show up as 0 and never change when writing to them, and they always read back as 0. Writing anything to SPI registers in APB3 (0x58010000 region) does nothing. So it's an issue on the APB3/PCLK3 bus, before it even gets to the radio. I'm way under the 16Mhz max limit, so it shouldn't be an overclocked issue that has damaged it.

[Xynium]

My storie...
First for unknown reason the stlink can't erase the flash and can't reprog the STM32WL (MI error ...) the core appear to be locked. With the stmprogrammer i had to unlock the device (which came after 4 attempts...) I finaly can reprogram the stm32WL but on the second attempt i had this error and the TX was inopperent. Soon after the STM32WL does not accept anything anymore the STLink report that the device stay in reset -> i undertand it is dead.
The only reason i found is the vicinity of a 5W RF source sending short burst for testing.

JP

Correction :

The chip is not dead it is locked option byte RDP read FF

After unlock still have the error   HAL_SUBGHZ_ERROR_TIMEOUT reported after SUBGHZSPI_Transmit ??

[EP.2]

If your RDP is FF and seems like it's dead and can't remove RDP or change user option bytes, try check this thread:

https://community.st.com/t5/stm32-mcus-security/stm32wle5-write-locked-not-in-read-after-passing-rdp-from-level/td-p/157014

Try set RDP to AA, then BB, then AA but you need to power cycle between each one (a reset is not enough, must completely remove power between each change). And at the end you might need to set all the user options back to their defaults "on" (except the last one) after you get it going again.

I wonder if the issues are related? The chip I have with the HAL_SUBGHZ_ERROR_TIMEOUT error is the same one I had with the RDP issue. But I didn't take notice if the HAL_SUBGHZ_ERROR_TIMEOUT error started before or after the RDP issue, so I'm not sure.

[Xynium]

Hi,

I have successfully unlock the chip but second question is why it is locking.

I have made many debug session,may be 100 or 200, on 3 differents projects whitout problem.

Those 2 errors arrive at the same time, may they are related may be not ???

[natruffles]

I have had this same issue for months. Turns out that the internet has found a solution(!), even if a root cause has still not been established:
Re: Having issues enabling the SubGhzSPI on STM32W... - STMicroelectronics Community

The solution involves changing a bit in a register that is not officially supposed to exist on the STM32WLE5 but still does.

[EP.2]

Thanks very much for the link! I don't have the faulty device anymore to investigate further, but most likely that was the cause for us too, as we were using custom OB, and setting RDP within the app etc... So looks like maybe there's a glitch somewhere with that secret hidden "SUBGHSPISD" bit in the Flash SFR register either in the MX driver/programmer or possibly even silicon. Or possibly when changing back from RDP 1 to 0 it's not reverting properly? But at least it looks like someone found an explanation of what to look for and a solution. Thanks for sharing.