<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="">Great Michael! I’ll test that as soon as I have the time.<div class=""><br class=""></div><div class=""><div class="">The previous version made me come a little bit further, however it will still stop, but for another reason. Maybe the last change will fix that?</div><div class=""><br class=""></div>I seems my problem now has to do with the queue. The queue is shared between both CAN-busses: Can1 (500kbit) and can2 (100kbit).<div class="">The <span style="font-family: Monaco;" class="">RxCallback </span>sometimes handles multiple can-frames from can2 in one «queue»-entry. Which means it can take quite a long time to finish. At that time the much faster can1 fills the rest of the queue. At the next interrupt, the queue is full and the RxCallback on can2 won’t be called.</div><div class="">The flags on mcp2515 won’t be cleared and no more interrupts will occur.</div><div class=""><br class=""></div><div class="">I wonder if we should have one queue per can and in <span style="font-family: Monaco;" class="">CAN_rxtask </span>we could check <span style="font-family: Monaco;" class="">m_rxqueue1, </span><span style="font-family: Monaco;" class="">m_rxqueue2 and </span><span style="font-family: Monaco;" class="">m_rxqueue</span> in a round robin fashion. </div><div class="">I think it is quick to test, so if your latest changes won’t fix this, I will try with separate queues.</div><div class=""><br class=""></div><div class="">Geir </div></div><div class=""><br class=""></div><div class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">31. des. 2017 kl. 21:38 skrev Michael Balzer <<a href="mailto:dexter@expeedo.de" class="">dexter@expeedo.de</a>>:</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="">
Turned out this was no hardware issue but a scheduler problem: the
CAN rx and vehicle rx tasks were not scheduled often & fast
enough to consistently keep up with the 10 ms period.<br class="">
<br class="">
After assigning the CAN RX task to core 0 and raising the vehicle
task priority to 10, there are no more TX overflows, and my charge
control override works perfectly.<br class="">
<br class="">
Geir, I don't know if that helps with your can2 issue, but it's
worth a try.<br class="">
<br class="">
Regards,<br class="">
Michael<br class="">
<br class="">
<br class="">
<div class="moz-cite-prefix">Am 31.12.2017 um 19:59 schrieb Michael
Balzer:<br class="">
</div>
<blockquote type="cite" cite="mid:12149dec-80b2-c879-cd0c-ec93a08097f5@expeedo.de" class=""><br class="">
And TX overflows actually do occur quite often, without a
plausible cause:<br class="">
<br class="">
<tt class="">OVMS > can can1 status </tt><tt class=""><br class="">
</tt><tt class="">CAN: can1</tt><tt class=""><br class="">
</tt><tt class="">Mode: Active</tt><tt class=""><br class="">
</tt><tt class="">Speed: 500000</tt><tt class=""><br class="">
</tt><tt class="">Rx pkt: 133146</tt><tt class=""><br class="">
</tt><tt class="">Rx err: 0</tt><tt class=""><br class="">
</tt><tt class="">Rx ovrflw: 0</tt><tt class=""><br class="">
</tt><tt class="">Tx pkt: 53238</tt><tt class=""><br class="">
</tt><tt class="">Tx err: 95</tt><tt class=""><br class="">
</tt><tt class="">Tx ovrflw: <b class="">498</b></tt><tt class=""><br class="">
</tt><tt class="">Err flags: 0x12c00</tt><tt class=""><br class="">
</tt><br class="">
In this case, a TX occurs every 10 ms on a 500 kbit bus -- plenty
of time for the buffer to get sent. I'm looking into that.</blockquote>
<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.teslaclub.hk" class="">OvmsDev@lists.teslaclub.hk</a><br class="">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev<br class=""></div></blockquote></div><br class=""></div></body></html>