cancel
Showing results for 
Search instead for 
Did you mean: 

Why HAL_SUBGHZ_ERROR_TIMEOUT error occurs in the function SUBGHZSPI_Transmit in Lora e5 mini?

MN.6
Associate

I am trying to make communication between two Lora E5 mini modules. So, I am using SubGhz Ping pong example. I flashed program in two lora e5 modules. In one module, I am always getting HAL_SUBGHZ_ERROR_TIMEOUT in the function SUBGHZSPI_Transmit. Please help me resolve this issue.

6 REPLIES 6
Hugo_VOLA
Associate II

Hello,

I'm facing the same problem.

I tried to compare to the end node program gived by seeds for the LoRa E5 mini to get the correct hardware configuration. But I still have the issue...

Did you find a solution ?

Thanks

tixorebel
Associate

I'm also facing the same problem, did you ever find a solution?

Related thread https://community.st.com/t5/stm32-mcus-wireless/subghzspi-transmit-return-hal-subghz-error-timeout-when-using/td-p/102503

Watch the debugger and peripheral view interfering with the live registers. Get a workable timebase, and use that to scope the loop

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
EP.2
Associate III

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.

natruffles
Associate

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 III

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.