From my experience of crashing MicroPython (and not only) thousands of times, on purpose viewtopic.php?t=375975, I can say if you have a Flash read glitch, it most of the times leads to a double fault ARM core lockup (MP is running from the same Flash), or less likely in a non-functional state (like an endless loop in RAM) before even having the slightest chance to erase or overwrite anything in Flash (which is not so simple).A car is often an electrically noisy environment which could potentially lead to corruption of a read. Perhaps especially if it powers up just as the starter motor is cranked.
...
I think key has to be being able to replicating the issue. Without that it can only be guesswork.
Also from power off tests (while writing in Flash), and brown-outs, and other ugly things, I've never seen a FS wipe-out like described here, corrupted files yes (actually truncated, not flushed data lost etc.), but never a complete FS corruption, or anything to other not involved files, LittleFS is quite solid in this regard.
I wouldn't bet on this unless replicated, but I would look more at human factor.Power-loss resilience - littlefs is designed to handle random power failures. All file operations have strong copy-on-write guarantees and if power is lost the filesystem will fall back to the last known good state.
Statistics: Posted by gmx — Sat Aug 30, 2025 8:11 pm