<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    OK, I've got a new idea: CAN timing.<br>
    <br>
    Comparing our esp32can bit timing to the esp-idf driver's, there
    seem to be some differences:<br>
<a class="moz-txt-link-freetext" href="https://github.com/espressif/esp-idf/blob/master/components/hal/include/hal/twai_types_deprecated.h#L75">https://github.com/espressif/esp-idf/blob/master/components/hal/include/hal/twai_types_deprecated.h#L75</a><br>
    <br>
    Transceivers are normally tolerant to small timing offsets. Maybe
    being off a little bit has no effect under normal conditions, but it
    has when the transceiver has to cope with a filled RX queue. That
    could be causing the transceiver to slide just out of sync. If the
    timing gets garbled, the transceiver would signal errors in the
    packets to the bus, possibly so many the vehicle ECUs decide to
    raise an error condition.<br>
    <br>
    Is that plausible?<br>
    <br>
    On why the new poller could be causing this (in combination with too
    slow processing by the vehicle): as mentioned, the standard CAN
    listener mechanism doesn't care about queue overflows. The poller
    does. `OvmsPollers::Queue_PollerFrame()` does a log call when Tx/Rx
    tracing is enabled, that could even block, but tracing is optional
    and only meant for debugging. Not optional is the overflow counting
    using an atomic uint32.<br>
    <br>
    The atomic types are said to be fast, but I never checked their
    actual implementation on the ESP32. Maybe they can block as well?<br>
    <br>
    @Simon: it would be an option to try commenting out the overflow
    counting, to see if that's causing the issue.<br>
    <br>
    Regards,<br>
    Michael<br>
    <br>
    <br>
    <div class="moz-cite-prefix">Am 17.01.25 um 15:37 schrieb Chris Box
      via OvmsDev:<br>
    </div>
    <blockquote type="cite"
cite="mid:010b019474b30c0d-45366923-5cdc-4a4b-a59d-cedf24ac5d5d-000000@eu-west-2.amazonses.com">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      <p>Yes, I can confirm I've had one experience of the Leaf
        switching to Neutral while driving, with a yellow warning symbol
        on the dash. It refused to reselect Drive until I had switched
        the car off and back on. Derek wasn't so lucky and he need to
        clear fault codes before the car would work.</p>
      <p>On returning home, I found OVMS was not accessible over a
        network. I didn't try a USB cable. Unplugging and reinserting
        the OBD cable caused OVMS to rejoin Wi-Fi. However the SD logs
        showed nothing from the time of the event. CAN writes are
        enabled, so it can perform SOC limiting.</p>
      <p>My car has been using this firmware since 21st November, based
        on the git master of that day. As a relatively new user of OVMS
        (only since October) I don't have much experience of older
        firmware.</p>
      <p>Perhaps a safeguard should be implemented before releasing a
        new stable firmware that will be automatically downloaded by
        Leaf owners. But I don't have the expertise to know what that
        safeguard should be. Derek's suggestion of 'only CAN write when
        parked' appears to be a good idea.</p>
      <p>Chris</p>
      <p><br>
      </p>
      <p id="reply-intro">On 2025-01-15 18:18, Derek Caudwell via
        OvmsDev wrote:</p>
      <blockquote type="cite"
style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0">
        <div id="replybody1">
          <div dir="auto">Since the following email I have high
            confidence the issue on the Leaf is related/caused by the
            poller as there has been no further occurrence and Chris has
            also experienced the car going to neutral on the new poller
            firmware. 
            <div dir="auto"><br>
              <div dir="auto">....</div>
              <div dir="auto">I haven't ruled out it being a fault with
                my car yet. Shortly after it faulted the car was run
                into so has been off the road for sometime, my first
                step was to replace 12V battery. The ovms unit is now
                unplugged and if it does not fault over the next month
                while driving I'll be reasonably confident it's ovms
                related.</div>
              <div dir="auto"> </div>
              <div dir="auto">Not sure which firmware version the poller
                updates were included in but it was only after upgrading
                to it that the errors occurred (which could be
                coincidental however it has faulted twice more both on
                version 3.3.004-141-gf729d82c). For periods where I
                reverted to 3.3.003 it was fine.</div>
              <div dir="auto"> </div>
              <div dir="auto">It might be useful to have an extra option
                on the enable can write to only enable it when the car
                is parked/charging.</div>
            </div>
          </div>
          <br>
          <div class="v1gmail_quote v1gmail_quote_container"> </div>
        </div>
      </blockquote>
      <p><br>
      </p>
      <br>
      <fieldset class="moz-mime-attachment-header"></fieldset>
      <pre wrap="" class="moz-quote-pre">_______________________________________________
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 * Am Rahmen 5 * D-58313 Herdecke
Fon 02330 9104094 * Handy 0176 20698926</pre>
  </body>
</html>