<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
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>
<br>
On the second app-flashing, this happened:<br>
<blockquote><tt>…<br>
Wrote 2399584 bytes (1382879 compressed) at 0x00010000 in 26.1
seconds (effective 736.0 kbit/s)...</tt><br>
<tt>Hash of data verified.</tt><br>
<br>
<tt>Leaving...</tt><br>
<tt>Hard resetting via RTS pin...</tt><br>
<tt>…</tt><br>
<tt>I (452) ovms_main: Mounting CONFIG...</tt><br>
<tt>W (722) vfs_fat_spiflash: f_mount failed (13)</tt><br>
<tt>I (722) vfs_fat_spiflash: Formatting FATFS partition,
allocation unit size=4096</tt><br>
<tt>I (1152) vfs_fat_spiflash: Mounting again</tt><br>
<tt>Initialising OVMS CONFIG within STORE</tt><br>
</blockquote>
:-(<br>
<br>
The first flash was perfectly OK and I haven't been able to
reproduce this afterwards.<br>
<br>
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>
<br>
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>
<br>
Regards,<br>
Michael<br>
<br>
<pre class="moz-signature" cols="160">--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
</pre>
</body>
</html>