LoRaWAN ESP32 (Heltec WSL V3) reboot with stack error #1049
Assignees
Comments
|
Thanks for this - can you show the log BEFORE the crash, what happens after the reboot is useful but not quite as important as what happens leading up to the stack smash. |
|
before is the same as in the end of the log - next will be the same reboot (after the delay) ... No more information available... |
So it's not happening anymore to recreate the log? Version numbering at library level is making tracing the test logs rather messy - so we'll improve our process to help with that - I'll create a clean development folder to look at this one - I wouldn't normally do a LinkCheck just after a join as it's a bit redundant and means the gateway has gone deaf twice in short order. Consequently the reference shows the API calls but isn't really best practise. Watch this space -> [ ] |
|
I had to reflash my test device - it was running with your sleeping example (btw: running fine and stable .. ;) ...)
yes, right, of course. But time request make sense... Here is a "fresh" log (after reset) with the requested detail: |
|
This is complete log with Looks like it works without problem (reboot) - will not touch it for some time ... ;) |
|
Thanks for the troubleshooting! Behaviour replicated, got some logs - I like big logs, I cannot lie. To be continued. |
StevenCellist
added
bug
StevenCellist
added a commit
that referenced
this issue
Apr 2, 2024
|
This issue is fixed with the referenced commit. Thank you for reporting! If you would want to use DeviceTimeReq or LinkCheckReq, make sure to use the latest version on GitHub; be aware that |
StevenCellist
added
the
resolved
|
Sorry to say,... but I have got again a reboot after some time... Hewre is the "long debug" - maybe you can see here anything or have an idea... |
|
@michapr I'm not sure what the issue could be; the crash happens during a hexdump of the uplink message which does not appear related to something particular in the LW stack. However it could be the case that a memory leak occurs somewhere. That is however difficult to investigate and definitely no priority for me. You could help by printing the free memory before and after each up/downlink / sendReceive to see if anything strikes the eye, which could help. I will only have time in two or three weeks to investigate further. Lots of other deadlines upcoming... |
Yes, of course. This has no priority, I think so. |
|
@michapr, the debug log leading up to the crash is far more important than after as after the crash it is a clean slate. Only 500 uplinks and a crash is less than idea. I've only 1 WSL v3 but I can let it run on a tighter uplink period on TTI to soak test this with reasonably frequent link checks & other pokey bits and full debug because we all know how much @StevenCellist loves big logs, he can not lie. |
yes, that's why I have added 2 cycles before reboot, I thought it is ok. I do not see any changes in memory in this time after about 400 uplinks - hope I made the right requests...(?) |
To me it looks like a partial log starting at 20:06:43.377 and a crash at 20:09:49.686 followed by a pile of uplinks. Is there another one to see? |
Right, was only ONE full cycle before, sorry. Can give you more lines before, but I'm not sure, will you see more here... BTW: my FcntUp is now at 965 (without any crash) and memory have still the same values... |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
I'm using for test the "LoRaWAN_Reference.ino" with the only modification node.setADR(true);
When call these two command requests: link_check and device_time the ESP32 will reboot after delay()
Debug log:
To Reproduce
use for test the "LoRaWAN_Reference.ino" with the only modification node.setADR(true);
Additional info (please complete):
The text was updated successfully, but these errors were encountered: