Skip to main content
Hugo_VOLA
Associate II
July 8, 2022
Question

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

  • July 8, 2022
  • 9 replies
  • 7278 views

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

9 replies

Denis Krasutski
Associate III
August 23, 2022

Hi! Did you figureout? I have the same behavor.

Hugo_VOLA
Hugo_VOLAAuthor
Associate II
August 25, 2022

Hi !

I'm not sure about what happened but I tried with another board and it works.

I tried also to change the LoRa E5 on the LoRa e5 mini and It also works.

I think that I make some misstake on my first board while trying to erase the IT firmware.

Hope it helps

Hugo

Denis Krasutski
Associate III
August 30, 2022

Thank you for reply, second device works fine! Firtst one stuck on line:

} while (READ_BIT(SUBGHZSPI->SR, SPI_SR_TXE) != (SPI_SR_TXE));} 

Looks like SUBGHZSPI doesn't have domain clock but it enabled.

Aleksei Polyakov
Visitor II
August 29, 2022

Any update anyone? I'm having similiar issue, timeout waiting for RXNE flag. The transceiver seems to be somehow off.

Hugo_VOLA
Hugo_VOLAAuthor
Associate II
August 29, 2022

For me, it seems like I messed up the board while I first try to erase the IT firmware...

With a new board, I only connect the LoRa E5 mini to my stmink, I open STM32CubeProgreammer, click on connect and change OB of the read protection from BB to AA . Then I flash or debug my code using STM32Cube IDE.

Check this issue request on github : https://github.com/Seeed-Studio/LoRaWan-E5-Node/issues/10

The same firmware work on the new board but not on the older one that I make serverals change on the OB while discovering the board...

Today I still don't find how to make work my older board...

Aleksei Polyakov
Visitor II
August 29, 2022

I have a custom project on a custom board in my case, but the problem seems totally same, SUBGHZSPI_Transmit returns timeout. I've broken several chips and feeling hesitant to flash another one.

Tesla DeLorean
Guru
October 23, 2023

One of the problems here is that the loop is bound by iterations, not time.

The release version can probably loop quickly, needs to be bounded by TIME, or have a delay so iterations have some expected elapsed time.

Would suggest insuring that SysTick is working and use that, or find TIM you can clock at 1 MHz or so.

Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..
EP.2
Associate II
December 17, 2023

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
Associate II
December 17, 2023

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
Associate III
December 20, 2023

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
Associate II
December 20, 2023

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
Associate III
December 20, 2023

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

 

Graduate
July 18, 2024

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
Associate II
July 18, 2024

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.