<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    Derek,<br>
    <br>
    I've currently got two candidates for this:<br>
    <br>
    a) the yet again broken PSRAM toolchain fix: <a
href="https://github.com/espressif/esp-idf/issues/2892#issuecomment-667099130">https://github.com/espressif/esp-idf/issues/2892#issuecomment-667099130</a><br>
    <br>
    b) the recently discovered concurrency issue in the OBD poller: <a
href="https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/405#issuecomment-674499551">https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/405#issuecomment-674499551</a><br>
    <br>
    I didn't get a response to a), and b) is currently being worked on
    by Soko & Thomas.<br>
    <br>
    On a)… it may be worth trying the pre-release toolchain from that
    issue, we've been using before. I switched to the "final" release
    before fixing the mutex WDT bug, so maybe the mutex bug cloaked a
    new issue from the new toolchain bug.<br>
    <br>
    On b)… as you're using the Leaf, and the Leaf code uses the poller
    to retrieve battery cell data (= lots of frames), you may be
    experiencing this.<br>
    <br>
    A quick local fix without adding Sokos polling extension would be:<br>
    <ol>
      <li>In vehicle.cpp, line 2040 (in PollerSend), change "<tt>if
          (m_poll_ml_remain > 7)</tt>" to "<tt>if (m_poll_ml_remain
          > 0)</tt>"</li>
      <li>Insert before line 2128 (in PollerReceive): "<tt>OvmsMutexLock
          lock(&m_poll_mutex);</tt>"<br>
      </li>
    </ol>
    This wouldn't fix all found issues with the current poller, but
    should avoid the potential reply handler runaway situation.<br>
    <br>
    I'd give b) a try first.<br>
    <br>
    Regards,<br>
    Michael<br>
    <br>
    <br>
    <div class="moz-cite-prefix">Am 18.08.20 um 04:04 schrieb Derek
      Caudwell:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAKUcfWEOLtL9-mQ9YrvjUm7g-7XLXh89qXVdnB5BayFw-RX15w@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">With DukTape disabled and Mcp2515 overflow logging
        turned off the module has run and been stable for 5 days or so
        however I had it crash today with the following log entry.
        <div>
          <div><br>
          </div>
          <div><span style="color:rgb(0,0,0);white-space:pre-wrap">2020-08-18 13:16:55 NZST I (12067) ovms-server-v3: Tx notify ovms/nismo/notify/data/debug.crash/1/0=*-OVM-DebugCrash,0,2592000,3.2.014-45-g390b4759-dirty/ota_0/edge (build idf v3.3.2-881-g22d636b7b-dirty Aug 13 2020 19:05:42),13,Crash,12,12,1,0,abort(),0,,0x4008e96b 0x4008ec05 0x400e6aec 0x40084122 ,6,Task watchdog,ticker.1,esp32wifi,0,IDLE1</span> <br>
          </div>
        </div>
        <div><br>
        </div>
        <div>It appears the issue remains (note this is with OVMS Events
          set to priority 19), however the likelihood of it causing the
          module to crash is reduced. </div>
        <div> <br>
        </div>
        <div>Let me know if you have other suggestions to debug it,
          otherwise I will re-enable DukTape and see if anything
          changes.</div>
        <div><br>
        </div>
        <div>Cheers</div>
        <div>Derek</div>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <pre class="moz-quote-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>
    <pre class="moz-signature" cols="72">-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
</pre>
  </body>
</html>