<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>