<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">I just wanted to report the same,
      except on my unit it hasn't happened during flashing but on (I
      assume) a reboot after a crash somewhere yesterday evening.<br>
      <br>
      I'll do the rollback on our esp-idf repository this evening.<br>
      <br>
      <br>
      Am 22.08.2018 um 05:06 schrieb Mark Webb-Johnson:<br>
    </div>
    <blockquote type="cite"
      cite="mid:17EF7C98-FC18-40AB-935D-4657C510A997@webb-johnson.net">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      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 class="" face="Andale Mono"><span
                style="font-size: 18px;" class="">I (562) ovms_main:
                Mounting CONFIG...</span></font></div>
          <div class=""><font class="" face="Andale Mono"><span
                style="font-size: 18px;" class="">Initialising OVMS
                CONFIG within STORE</span></font></div>
          <div class=""><font class="" face="Andale Mono"><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>
    </blockquote>
    <br>
    <blockquote type="cite"
      cite="mid:17EF7C98-FC18-40AB-935D-4657C510A997@webb-johnson.net">
      <div class="">
        <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=""
                  moz-do-not-send="true">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=""
                  moz-do-not-send="true">OvmsDev@lists.openvehicles.com</a><br
                  class="">
                <a class="moz-txt-link-freetext" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br
                  class="">
              </div>
            </blockquote>
          </div>
          <br class="">
        </div>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
OvmsDev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.openvehicles.com">OvmsDev@lists.openvehicles.com</a>
<a class="moz-txt-link-freetext" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
    </blockquote>
    <br>
    <br>
    <pre class="moz-signature" cols="144">-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
</pre>
  </body>
</html>