<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    No luck with all variations. I've switched back to the byte counting
    workaround.<br>
    <br>
    Regards,<br>
    Michael<br>
    <br>
    <br>
    <div class="moz-cite-prefix">Am 07.11.19 um 10:31 schrieb Michael
      Balzer:<br>
    </div>
    <blockquote type="cite"
      cite="mid:95588de0-ab7c-113c-274d-4b634a2199b1@expeedo.de">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      The new implementation doesn't seem to work very well. It seems
      this approach loses a lot of CAN frames. I don't have the means to
      test how many, but I see the effect in my vehicle events &
      status.<br>
      <br>
      The Espressif info given by Darian in the issue was either
      inaccurate or misses some important detail. There's another (non
      Espressif) developer on the issue trying to get the idf driver to
      correctly handle the issue, he hasn't had any luck as well up to
      now.<br>
      <br>
      I'll try another interpretation of the scheme outlined by Darian.
      If that doesn't work I'll revert to my first workaround until we
      get answers or template code from Espressif.<br>
      <br>
      Regards,<br>
      Michael<br>
      <br>
      <br>
      <div class="moz-cite-prefix">Am 03.11.19 um 19:46 schrieb Michael
        Balzer:<br>
      </div>
      <blockquote type="cite"
        cite="mid:76d7e96d-0108-35c4-9c0d-3d7b7dadf14c@expeedo.de">
        <meta http-equiv="Content-Type" content="text/html;
          charset=UTF-8">
        I've pushed the new implementation based on the Espressif info
        and some more experimentation.<br>
        <br>
        I've also enabled the IRAM flag for the GPIO and SPI_noDMA
        handlers, as all handlers here already were in IRAM.<br>
        <br>
        I've been testing this over the weekend, had no issues and
        slightly reduced can1 frame drops.<br>
        <br>
        Mark, maybe you can do some additional high load CAN tests in
        your lab.<br>
        <br>
        Regards,<br>
        Michael<br>
        <br>
        <br>
        <div class="moz-cite-prefix">Am 01.11.19 um 12:35 schrieb
          Michael Balzer:<br>
        </div>
        <blockquote type="cite"
          cite="mid:fd9d5897-5237-7cb8-1e40-a40aee6ba740@expeedo.de">
          <meta http-equiv="Content-Type" content="text/html;
            charset=UTF-8">
          An unusual fast reply from Espressif. They basically declared
          it to be a feature…<br>
          <br>
          <a
href="https://github.com/espressif/esp-idf/issues/4276#issuecomment-548753085"
            moz-do-not-send="true">https://github.com/espressif/esp-idf/issues/4276#issuecomment-548753085</a><br>
          <br>
          Regards,<br>
          Michael<br>
          <br>
          <br>
          <div class="moz-cite-prefix">Am 01.11.19 um 10:34 schrieb
            Michael Balzer:<br>
          </div>
          <blockquote type="cite"
            cite="mid:3fccacb5-bf45-a329-24eb-8d2cd62b6cda@expeedo.de">
            <meta http-equiv="Content-Type" content="text/html;
              charset=UTF-8">
            I've submitted an issue to Espressif on this:<br>
            <br>
            <a href="https://github.com/espressif/esp-idf/issues/4276"
              moz-do-not-send="true">https://github.com/espressif/esp-idf/issues/4276</a><br>
            <br>
            It would be nice if I could reproduce the effect using some
            standard hardware.<br>
            I've ordered some of those combined ESP32 + OLED units, but
            don't have any CAN transceivers I could hook up to them.<br>
            Maybe the info I've provided is sufficient for Espressif to
            investigate.<br>
            <br>
            Regards,<br>
            Michael<br>
            <br>
            <br>
            <div class="moz-cite-prefix">Am 31.10.19 um 22:24 schrieb
              Michael Balzer:<br>
            </div>
            <blockquote type="cite"
              cite="mid:fe537da7-12c1-e0ca-0ac5-7374415628b2@expeedo.de">
              <meta http-equiv="content-type" content="text/html;
                charset=UTF-8">
              Second finding & commit:<br>
              <br>
              TL;DR:<br>
              <ul>
                <li>ESP32 CAN controller is broken, delivers trashed
                  & duplicated RX frames</li>
                <li>we need to optimize interrupt latency</li>
              </ul>
              <br>
              Users have been reporting occasional false BMS readings on
              the Twizy for more than a year.<br>
              The error always trashed the reading of voltage #10 and/or
              temperature #8, so I initially<br>
              thought that must be a variant of the SPIRAM/cache bug.<br>
              <br>
              But the SPIRAM fix didn't help, and the bug still occured
              with all BMS data in internal<br>
              RAM. The issue correlated with high load situations and
              the SIMCOM UART issue. On testing the<br>
              latest changes by Marko, my car module began showing that
              issue regularly, so I could take a<br>
              closer look. It turned out the wrong data came from the
              CAN bus. Checking with a CAN logger<br>
              didn't show any wrong data on the bus.<br>
              <br>
              So I scanned our CAN driver for potential issues, found
              & solved some (even a serious<br>
              race condition) but that didn't fix it. I then added debug
              dumps of all frames read, dug<br>
              into the SJA1000 spec sheet and found this:<br>
              <br>
              The SJA1000 RX FIFO has a capacity of 64 bytes. It's
              supposed to work as a ring buffer,<br>
              with frames wrapping around as necessary. If no space is
              left in the FIFO for a new frame<br>
              coming in, that frame should be discarded completely, not
              counted, just the overflow<br>
              indicator should be set & the according interrupt be
              generated.<br>
              <br>
              Reality differs. The frame causing the overflow is added
              to the FIFO partially. It's also<br>
              counted both in the RMC register and indicated by RBS as a
              valid frame when retrieving<br>
              the FIFO contents. The read buffer delivers the partial
              frame + some trashed bytes up<br>
              to the nominal frame length.<br>
              <br>
              In the BMS frame sequence it would normally trash bytes 7
              & 8 on the sixth frame of length<br>
              8 in a sequence. A standard frame needs a 3 byte header +
              the data bytes in the FIFO, so<br>
              6 frames would add up to 66 bytes => 64 + 2 trash. The
              first trash byte normally is "08",<br>
              the second "84" or "2a" or sometimes "ab", possibly some
              internal SJA1000 data.<br>
              <br>
              Better yet, if you rely on the indicators of the SJA1000
              when reading the FIFO, the<br>
              SJA1000 will repeat the first frame within the FIFO after
              the invalid frame. Mostly<br>
              once or twice, and sometimes 7 times or more:<br>
              <br>
              <tt>inv_msg: framecnt=13, invindex=6</tt><tt><br>
              </tt><tt>inv_msg: 55 01 00 00 07 98 50 54 54 20 00 6e |
                4..?........U.....PTT .n</tt><tt><br>
              </tt><tt>inv_msg: 24 04 00 00 11 40 10 22 37 55 00 37 |
                4..?........$....@."7U.7</tt><tt><br>
              </tt><tt>inv_msg: 25 04 00 00 0a 1b 44 ff fe 4e 01 26 |
                4..?........%.....D..N.&</tt><tt><br>
              </tt><tt>inv_msg: 54 05 00 00 37 37 37 37 37 37 37 00 |
                4..?........T...7777777.</tt><tt><br>
              </tt><tt>inv_msg: 56 05 00 00 31 63 14 31 53 14 31 4a |
                4..?........V...1c.1S.1J</tt><tt><br>
              </tt><tt>inv_msg: 57 05 00 00 31 43 14 31 53 15 <font
                  color="#ff0000"><b>08 2a</b></font> |
                4..?........W...1C.1S..*</tt><tt><br>
              </tt><tt>                                       ^^^^^ <font
                  color="#ff0000">trashed bytes</font></tt><tt><br>
              </tt><tt>… followed by <font color="#ff0000">7
                  repetitions of the first frame</font>:</tt><tt><br>
              </tt><tt>inv_msg: 55 01 00 00 07 98 50 54 54 20 00 6e |
                4..?........U.....PTT .n</tt><tt><br>
              </tt><tt>inv_msg: 55 01 00 00 07 98 50 54 54 20 00 6e |
                4..?........U.....PTT .n</tt><tt><br>
              </tt><tt>inv_msg: 55 01 00 00 07 98 50 54 54 20 00 6e |
                4..?........U.....PTT .n</tt><tt><br>
              </tt><tt>inv_msg: 55 01 00 00 07 98 50 54 54 20 00 6e |
                4..?........U.....PTT .n</tt><tt><br>
              </tt><tt>inv_msg: 55 01 00 00 07 98 50 54 54 20 00 6e |
                4..?........U.....PTT .n</tt><tt><br>
              </tt><tt>inv_msg: 55 01 00 00 07 98 50 54 54 20 00 6e |
                4..?........U.....PTT .n</tt><tt><br>
              </tt><tt>inv_msg: 55 01 00 00 07 98 50 54 54 20 00 6e |
                4..?........U.....PTT .n</tt><br>
              <br>
              If you had occasional strange false readings leading to
              strange effects, this<br>
              may be the explanation. Note: the SJA1000 FIFO bug may
              need specific circumstance<br>
              to occur in addition to the overflow, maybe the overflow
              happening on a specific<br>
              byte position in the FIFO -- I haven't tried to determine
              that.<br>
              <br>
              I've tried clearing the overflow ASAP, looping on the IR
              indicator and looping<br>
              on the RMC, the fault is always the same. The workaround
              I've now done is adding<br>
              up the message lengths read during a FIFO run and discard
              all frames exceeding<br>
              the 64 byte border. Not pretty, but functional.<br>
              <br>
              That keeps the trashed frames from being forwarded to the
              OVMS application level.<br>
              <br>
              As with the SIMCOM UART, these overflows wouldn't happen
              if the interrupt handler<br>
              would react fast enough. It seems we've got a general
              interrupt latency issue.<br>
              <br>
              And just as with the SIMCOM I saw a reduction of overflows
              when allocating the<br>
              CAN IRQ on core #0, another one with raising the IRQ level
              to 3, so that's<br>
              also part of my commit.<br>
              <br>
              The esp-idf CAN driver apparently has the same issue even
              in the latest release,<br>
              I'll contact the author about this or post another issue
              to Espressif.<br>
              <br>
              So our interrupt allocation is now:<br>
              <br>
              <tt>Task           Run#  Lvl  ISR# 
                Usage                    Source</tt><tt><br>
              </tt><tt>----------------------------------------------------------------------------------------</tt><tt><br>
              </tt><tt>-              0     1    0     RTC
                Core                 ETS_RTC_CORE_INTR_SOURCE</tt><tt><br>
              </tt><tt>esp_timer      0     1    0     RTOS
                esp_timer           ETS_TIMER2_INTR_SOURCE</tt><tt><br>
              </tt><tt>ipc0           0     1    0     RTOS Scheduler
                Core0     ETS_FROM_CPU_INTR0_SOURCE</tt><tt><br>
              </tt><tt>ipc1           1     1    1     RTOS Scheduler
                Core1     ETS_FROM_CPU_INTR1_SOURCE</tt><tt><br>
              </tt><tt>main           0     1    0     RTOS
                Watchdog            ETS_TG0_WDT_LEVEL_INTR_SOURCE</tt><tt><br>
              </tt><tt>OVMS Events    1     1    1     Peripherals (GPIO
                ISR)   ETS_GPIO_INTR_SOURCE</tt><tt><br>
              </tt><tt>OVMS Events    1     1    1     MAX7317
                (spi_nodma)      ETS_SPI3_INTR_SOURCE</tt><tt><br>
              </tt><b><tt>esp32can init  0     3    0     ESP32
                  CAN                ETS_CAN_INTR_SOURCE</tt></b><b><tt><br>
                </tt></b><b><tt>OVMS SIMCOM    0     2    0     SIMCOM
                  UART              ETS_UART1_INTR_SOURCE</tt></b><tt><br>
              </tt><tt>OVMS Events    1     1    1     USB console
                (UART)       ETS_UART0_INTR_SOURCE</tt><tt><br>
              </tt><tt>OVMS Events    1     1    1     SD
                card                  ETS_SDIO_HOST_INTR_SOURCE</tt><tt><br>
              </tt><tt>----------------------------------------------------------------------------------------</tt><br>
              <br>
              I think we need to find the source of the interrupt
              latency and/or find some<br>
              better scheme to distribute the tasks & interrupts
              over the cores.<br>
              <br>
              I still don't know why core #1 already got an issue with
              just our 6 interrupts.<br>
              This may be related to the SPIRAM fix adding overhead, but
              I've seen the FIFO<br>
              overflows before applying the fix, and the CAN issue also
              has been present for<br>
              over a year.<br>
              <br>
              My working hypothesis is some task/driver disabling
              interrupts for too often<br>
              / too long, or non-IRAM ISRs getting delayed for too often
              / too long. And it<br>
              seems this is an issue especially on core #1.<br>
              <br>
              Please verify & comment.<br>
              <br>
              Regards,<br>
              Michael<br>
              <br>
              PS: a little side mystery: the netmanager task starts with
              priority 5, then<br>
              gets raised to 22 (probably a mutex priority inheritance),
              but never gets<br>
              lowered back to 5 afterwards. A FreeRTOS bug?<br>
              <br>
              <pre class="moz-signature" cols="160">-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
</pre>
              <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" moz-do-not-send="true">OvmsDev@lists.openvehicles.com</a>
<a class="moz-txt-link-freetext" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" moz-do-not-send="true">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
            </blockquote>
            <br>
            <pre class="moz-signature" cols="160">-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
</pre>
            <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" moz-do-not-send="true">OvmsDev@lists.openvehicles.com</a>
<a class="moz-txt-link-freetext" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" moz-do-not-send="true">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
          </blockquote>
          <br>
          <pre class="moz-signature" cols="160">-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
</pre>
          <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" moz-do-not-send="true">OvmsDev@lists.openvehicles.com</a>
<a class="moz-txt-link-freetext" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" moz-do-not-send="true">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
        </blockquote>
        <br>
        <pre class="moz-signature" cols="160">-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
</pre>
        <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" moz-do-not-send="true">OvmsDev@lists.openvehicles.com</a>
<a class="moz-txt-link-freetext" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" moz-do-not-send="true">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
      </blockquote>
      <br>
      <pre class="moz-signature" cols="160">-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
</pre>
      <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="160">-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
</pre>
  </body>
</html>