flipperzero-firmware icon indicating copy to clipboard operation
flipperzero-firmware copied to clipboard

Flipperzero crashes when GPS is attached to GPIO

Open dariusan opened this issue 11 months ago • 3 comments

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

  1. plug a GPS board
  2. don't run the GPS app
  3. wait for Flipper to crash

Target

No response

Logs


Anything else?

No response

dariusan avatar Jan 25 '25 14:01 dariusan

@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 avatar Feb 03 '25 18:02 hedger

@hedger This setting actually works. When I set it to "None" it does not crash anymore. What is the drawback of this setting?

dariusan avatar Feb 03 '25 20:02 dariusan

It is responsible for plug-and-play compatibility of external modules by implementing a special protocol. Anyway, looks like a bug.

hedger avatar Feb 04 '25 11:02 hedger

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: Image

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?

aaronjamt avatar Jul 01 '25 20:07 aaronjamt

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)

WillyJL avatar Jul 02 '25 07:07 WillyJL