-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Lead Scout crashes/hangs with Wi-Fi debug output enabled #5
Comments
Good to know it also happens with DUMP_LINES, I've mostly tested with SPI_BYTES also enabled.
Yes, this is data that precedes the asynchronous "now associated" response, but when reading it there is no way to actually know that async response is coming. This is the same stuff you get before the "OK" when manually (synchronously) connecting, but for asynchronous they also just randomly print that data. This is one of those weird parts of the serial interface...
I've seen the unexpected number part before, often just after a (re)boot. Hadn't really payed attention to it before. I wonder if it's because there is not a real reset, so perhaps something is not properly initialized? |
If I comment out |
Would it make sense to enable the watchdog timer in case of a hung board? This was discussed before and agreed it would be a good idea, but we didn't actually implement it. Would this be a good extra protection around hung boards? Not sure it'd actually solve the bad resets though unless we check the last-reset-cause via the bootloader work, and always WDT reset on "unknown cause" resets. |
A did a quick review of all Wrt the WDT - that would only solve lockups if the main loop actually stops running, which I'm not sure of yet (just thought of a way to test this, though, put a |
Agreed. The blocking part of NCM makes this an iffy proposition. Unless we did something like 30 seconds or more |
I also see strange behavior, including hangs, when I have this as a bitlash startup function and I have GS_DUMP_LINES defined:
My hypothesis is that when led state changes, it fires off a report, and it is a) bitlash's handling of the report data destined to HQ getting hosed up with the Wifi loop, or b) the Wifi loop is blocking too long and bitlash gets corrupted or loses information. When I remove this startup function and still have GS_DUMP_LINES defined, it runs without crashing. |
This is with the following defines set:
Specifically, it looks like Bitlash is experiencing an overflow or something?, there's an
overflow
and then anunexpected number
and then the board resets.Also, is
Discarding non-escaped byte, no synchronous response expected
expected, when it's returning valid data like IP address/subnet/etc?At the end of this second run, the board is locked up and requires a reset.
The text was updated successfully, but these errors were encountered: