Increase the delay when powering up the T1000-E to avoid hangs on boot#1894
Increase the delay when powering up the T1000-E to avoid hangs on boot#1894alexsporn wants to merge 1 commit intomeshcore-dev:devfrom
Conversation
|
RadioLib already handles the startup timings of LR1110. This seems like a workaround for a different problem. Waiting 150ms should not really be necessary. I think it's coincidence/placebo 👀 . |
I tried it on 2 devices and waiting on boot at this point is the only way to get it to boot consistently. I actually found this issue trying to do the same, changing the BLE pin, but found out that the simple reboot already breaks it. Even deploying a new version won't fix it, only a full wipe and restart. I tried to debug this by waiting on the serial to be connected before continuing the boot (so that I could get all the debug logs while booting), but I could not get it to hang due to the implicit delay I added by waiting on a serial connection. The waiting a couple of milliseconds longer (150ms is to be safe) on board init consistently fixed this issue. |
|
Hopefully #1939 fixes this. |
Reimplements meshcore-dev/MeshCore PR meshcore-dev#1894 on top of 467959c for the 1.14.1 maintenance branch. References: PR: meshcore-dev#1894 Seeed SenseCAP T1000 introduction: https://wiki.seeedstudio.com/SenseCAP_T1000_tracker/Introduction/ Rationale: This change increases the board bring-up delay from 10 ms to 150 ms before the radio stack is used on the T1000-E. The patch is a single-line board-specific timing adjustment intended to avoid boot hangs caused by talking to the radio before it is ready. It does not affect protocol logic, shared abstractions, or non-T1000-E targets, which makes it an appropriate maintenance fix.
0118f23 to
4d1ee19
Compare
|
Rebased on latest |
It seems that 10ms is too short to allow the LR1110 to power up and stabilize before we call
radio_init().This increases the delay to 150ms which seems to work fine on my devices.
Fixes #1780