<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">I just updated my test box, and the same thing happened. It had been rock-solid for months.<div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><div class=""><font face="Andale Mono" class=""><span style="font-size: 18px;" class="">I (562) ovms_main: Mounting CONFIG...</span></font></div><div class=""><font face="Andale Mono" class=""><span style="font-size: 18px;" class="">Initialising OVMS CONFIG within STORE</span></font></div><div class=""><font face="Andale Mono" class=""><span style="font-size: 18px;" class="">E (822) config: Error: Cannot open config store directory</span></font></div></div></blockquote><div class=""><div class=""><br class=""></div><div class="">Downgraded to 3.1.009, but still can’t mount store.</div><div class=""><br class=""></div><div class="">I’m pretty sure there is something in the new IDF that is corrupting FAT filesystems on flash.</div><div class=""><br class=""></div><div class="">We need to roll-back. I’ve disabled nightly builds until we can resolve this.</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div text="#000000" bgcolor="#FFFFFF" class="">I wonder if there could be a better strategy than immediately formatting the config filesystem on a mount error. Is there any chance the mount fails due to some race condition, i.e. would it make sense to first retry mounting after a short delay?</div></blockquote><br class=""></div><div class="">I’m not seeing a reformat of the flash, just a failure to mount. The reformat option is part of the fat mount option. We can certainly turn it off, or delay/retry it, but it is required for initial boot of a new device.</div><div class=""><br class=""></div><div class="">Regards, Mark.<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 19 Aug 2018, at 7:23 PM, Michael Balzer <<a href="mailto:dexter@expeedo.de" class="">dexter@expeedo.de</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="content-type" content="text/html; charset=utf-8" class="">
<div text="#000000" bgcolor="#FFFFFF" class="">
I've pulled the latest esp-idf updates, merges, builds and runs
without issues. Btw, the idf now includes a CAN driver, may be worth
a look.<br class="">
<br class="">
On the second app-flashing, this happened:<br class="">
<blockquote class=""><tt class="">…<br class="">
Wrote 2399584 bytes (1382879 compressed) at 0x00010000 in 26.1
seconds (effective 736.0 kbit/s)...</tt><br class="">
<tt class="">Hash of data verified.</tt><br class="">
<br class="">
<tt class="">Leaving...</tt><br class="">
<tt class="">Hard resetting via RTS pin...</tt><br class="">
<tt class="">…</tt><br class="">
<tt class="">I (452) ovms_main: Mounting CONFIG...</tt><br class="">
<tt class="">W (722) vfs_fat_spiflash: f_mount failed (13)</tt><br class="">
<tt class="">I (722) vfs_fat_spiflash: Formatting FATFS partition,
allocation unit size=4096</tt><br class="">
<tt class="">I (1152) vfs_fat_spiflash: Mounting again</tt><br class="">
<tt class="">Initialising OVMS CONFIG within STORE</tt><br class="">
</blockquote>
:-(<br class="">
<br class="">
The first flash was perfectly OK and I haven't been able to
reproduce this afterwards.<br class="">
<br class="">
I don't think this is related to idf changes, as we had some reports
on lost configs before. Issue #145 also seems to be solved by the
new idf, I had no more crashes during reboots.<br class="">
<br class="">
I wonder if there could be a better strategy than immediately
formatting the config filesystem on a mount error. Is there any
chance the mount fails due to some race condition, i.e. would it
make sense to first retry mounting after a short delay?<br class="">
<br class="">
Regards,<br class="">
Michael<br class="">
<br class="">
<pre class="moz-signature" cols="160">--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
</pre>
</div>
_______________________________________________<br class="">OvmsDev mailing list<br class=""><a href="mailto:OvmsDev@lists.openvehicles.com" class="">OvmsDev@lists.openvehicles.com</a><br class="">http://lists.openvehicles.com/mailman/listinfo/ovmsdev<br class=""></div></blockquote></div><br class=""></div></div></body></html>