Flipperzero crashes when GPS is attached to GPIO
Describe the bug.
It looks like since the last firmware flipper zero crashes when a GPS is plugged to the GPIO connectors and no application reads the NMEA data which is send to UART. One has to reset the flipper all the time.
Reproduction
- plug a GPS board
- don't run the GPS app
- wait for Flipper to crash
Target
No response
Logs
Anything else?
No response
@dariusan Try disabling expansion protocol detection on that UART: settings > expansion modules > listen UART. Set to None. Check if the issue could still be reproduced.
@hedger This setting actually works. When I set it to "None" it does not crash anymore. What is the drawback of this setting?
It is responsible for plug-and-play compatibility of external modules by implementing a special protocol. Anyway, looks like a bug.
I was able to trigger this bug once. It doesn't appear to be a total crash, since I unplugged the power cable and the RGB LED turned off, even after the crash. However, I do see a bunch of the following error in the logs, maybe it's just a matter of following its directions and increasing the stack size?
225383 [E][ExpansionSrvWorker] Stack watermark is too low 204 < THREAD_STACK_WATERMARK_MIN. Increase stack size.
Edit to add: I crashed it again by exiting an application that uses the serial port (the UART Terminal app). The last information logged over UART was:
1304494 [E][ExpansionSrvWorker] Stack watermark is too low 212 < THREAD_STACK_WATERMARK_MIN. Increase stack size.
1304790 [E][ExpansionSrvWorker] Stack watermark is too low 244 < THREAD_STACK_WATERMARK_MIN. Increase stack size.
1305014 [E][Ex_
I also had my WiFi Devboard connected and was able to capture this traceback:
Looking at what called furi_crash, the exception was: "MPU fault, possibly stack overflow". Does this also point to it being a stack size issue?
i think i managed to fix it, been stress testing it with the noisiest uart device i have (esp32 flashed with incorrect firmware, crashing and bootlooping with tons of error logs) and its been going strong for more than an hour (usually, it froze within 2-10 seconds of plugging in)