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

[out0f0rder]

Timing is definetely not the case.

I have about 120 custom boards based on STM32WLE5CC and about 20 of them have this issue. The MCU fails the very first call to SUBGHZSPI_Transmit() with HAL_SUBGHZ_ERROR_TIMEOUT due to the same line of HAL code and SPI_SR_TXE flag not being set.

The very same binary code works perfectly on the rest 100pcs.

I even took two brand new STM32WLE5CC chips from the tray an soldered them in place of broken.

Guess what? They are not working too! There is something with the PCB maybe.

No idea what to check further. I'm stuck for now :(

[Tesla DeLorean]

TXE not going high is suggestive of a clocking issue, does it work a few time then stop or does it never work?

Is there some error or other status reflected by SPI->SR? Some DMA or IRQ servicing it? Are other SPI registers all zero?

[Tesla DeLorean]

Dump RCC and SPI registers, and any other salient registers, in the failing cases, but also how they look in the working ones.

Provide some way to compare and contrast, or bisected the issue.

Look for failure earlier, the cause may be in initialization of clocks, pins or peripheral. Work the symptoms back to a cause, or other observable diversion of behaviour.

[out0f0rder]

Thank you for your reply!

Seems I have to sacrifice another chip to check if it works at least once before death. I've never tried to debug from the clean MCU.

Regarding registers. I've dig a bit deeper and found out that the issue starts with SUBGHZ SPI clock enable.

RCC->APB3ENR->SUBGHZSPIEN is always zero even after writing 1 and hence the SPI3 not working.

Looks like SUBGHZ is the only peripheral on APB3. I've double checked the clock configuration of APB3 and it seems perfectly ok and equal to HCLK3 (48Mhz).

However not tried replacing the crystal. Doubt that may be the case, but may be an explanation why the issue is tied to a PCB and not a MCU.

Update:

I've tripple checked everything update HAL and cortex debugger and found my error. Actually there is clock on SPI and RCC->APB3ENR->SUBGHZSPIEN does become 1. It's OK here.

But enable bit on SUBGHZ SPI->CR1->SPE is staying zero after explicit enable.

This is in HAL function SUBGHZSPI_Init:

This line has no effect:

SET_BIT(SUBGHZSPI->CR1, SPI_CR1_SPE);

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

[out0f0rder]

As I wrote in another thread my assumption is that there possible VDD spikes are over the limit.

What I do now if I encounter a dead radio is:

desoldering MCU, checking VDD, replacing DC-DC or it's resitor divider if there is any sign of possible voltage over 3.6V and soldering another STM32WLE5 in place.
This procedure had no failures yet.

[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 ???