Replies: 2 comments
-
Hi |
Beta Was this translation helpful? Give feedback.
0 replies
-
Any solution for this problem ? |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Introduction
Hi,
I am developing firmware for a device with LoRaWAN based communication on the STM32WL55CCU6 microcontroller. So far everything seemed fine, without any major problems until I've left the device working for several days straight. After long operation for several days there were situation in which the device stopped sending periodic uplink messages, and also there was no reaction to the transmitted downlink messages. However, the device was not completely dead, it was "partially" working. What I mean by that is some threads seemed to be operational. For example the device status LED, which was implemented in a separate UI thread was blinking continuously. After some debugging, I suspect that the problem is related to the radio driver, but as I am not sure, instead of creating Bug Issue I decided to put it here as discussion first. Perhaps it is due to some incorrect use of LoRaWAN API by my application. As for my application, it collects some data from sensors and then sends it from a separate thread (not from System Work Queue). Downlink messages and the Join procedure are also performed in a separate threads. Uplink messages are sent periodically, most of them are sent without acknowledgment, and after 5 unacknowledged messages, 1 acknowledgment message is sent to make sure that they are correctly delivered to the server. In case of no response from the server or if no downlink message has been received for a long time, the Join Request in transmitted as a last resort to restore communication.
Describe the (potential?) bug
From what I've discovered so far, the device gets stuck in the
SX126xWaitOnBusy
function, in a loop where it's waiting for theRFBUSY
flag to disappear. The function definition is indrivers/lora/sx126x.c
. For STM32WL,SX126xWaitOnBusy
callssx126x_is_busy
, which reads theRFBUSYS
bit directly fromPWRSR2
register using the ST LL driver.I've attached debugger to the device and left it running while waiting for the moment when this situation would occur again. After more than 2 days I managed to catch this with debug session active. Below is the backtrace from GDB (there might be some differences with the line numbers as I might have added logs in some places during the debug process):
Looking at the backtrace, the device got stuck while it was performing the Join procedure. This procedure was caused by problem with gateway we had in our office and as there was no acknowledges received by the device for a long time it issued a Join Request. In the active GDB session, I've also checked the fields of the
dev_data
structure and as you can see, the radio is inMODE_SLEEP
mode, which may explain why theRFBUSY
status does not change.In the
sx126x_spi_transceive
function, before sending the SPI command, theSX126xCheckDeviceReady
function is called, in which the radio operating mode is checked and if the radio is inMODE_SLEEP
mode, it is woken up, and only then the RFBUSY flag is checked. After completing the transaction, if it was not actually a command for setting the radio to sleep mode (req_tx[0] != RADIO_SET_SLEEP
), the RFBUSY is checked and this is where the device gets stuck. It seems to me that after the transaction is done, the radio is somehow put intoMODE_SLEEP
somewhere.That's all I've got for the moment, I will certainly continue with this issue, but if someone has any suggestions how should I approach this problem or what it might be related to I would really appreciate any help.
To reproduce
For now I’m not really sure how to reproduce this as it happens rarely (sometimes after few days after continuous device operation) which makes it harder to debug or find a way to reproduce this on demand.
Logs and console output
GDB backtrace:
dev_data
:SX126xWaitOnBusy
definiction:Environment
Beta Was this translation helpful? Give feedback.
All reactions