<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">My code crashed with same error as it described. <div>plus one error: in <span style="font-family:Menlo;font-size:11pt;color:rgb(0,0,0)">esp32can.cpp:448</span></div><div><br></div><div>The files can access my dropbox folder: <a href="https://www.dropbox.com/sh/mowc7hc7zrzszmm/AACO4MAmM1yF3yoXsGoZO6R_a?dl=0">https://www.dropbox.com/sh/mowc7hc7zrzszmm/AACO4MAmM1yF3yoXsGoZO6R_a?dl=0</a></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Michael Balzer <<a href="mailto:dexter@expeedo.de" target="_blank">dexter@expeedo.de</a>> ezt írta (időpont: 2019. dec. 13., P, 10:16):<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
  
    
  
  <div>
    Greg, Mark,<br>
    <br>
    the new crash happened here:<br>
    <br>
    <tt><a href="mailto:balzer@leela:~/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3" target="_blank">balzer@leela:~/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3</a>>
      a2l 0x3ffcfda0:0x3ffc87a0 0x400da762:0x3ffc87d0
      0x400da95b:0x3ffc87f0 0x400da901:0x3ffc8810</tt><tt><br>
    </tt><tt>Using elf file:
/home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/ovms3.elf</tt><tt><br>
    </tt><tt>0x400da762 is in can::ExecuteCallbacks(CAN_frame_t const*,
      bool, bool)
(/home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/can/src/can.cpp:866).</tt><tt><br>
    </tt><tt>861      {</tt><tt><br>
    </tt><tt>862      if (tx)</tt><tt><br>
    </tt><tt>863        {</tt><tt><br>
    </tt><tt>864        if (frame->callback)</tt><tt><br>
    </tt><tt>865          {</tt><tt><br>
    </tt><tt>866          (*(frame->callback))(frame, success); //
      invoke frame-specific callback function</tt><tt><br>
    </tt><tt>867          }</tt><tt><br>
    </tt><tt>868        for (auto entry : m_txcallbacks) {      //
      invoke generic tx callbacks</tt><tt><br>
    </tt><tt>869          entry->m_callback(frame, success);</tt><tt><br>
    </tt><tt>870          }</tt><tt><br>
    </tt><tt>0x400da95b is in canbus::TxCallback(CAN_frame_t*, bool)
(/home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/can/src/can.cpp:1018).</tt><tt><br>
    </tt><tt>1013        }</tt><tt><br>
    </tt><tt>1014      else</tt><tt><br>
    </tt><tt>1015        {</tt><tt><br>
    </tt><tt>1016        LogFrame(CAN_LogFrame_TX_Fail, p_frame);</tt><tt><br>
    </tt><tt>1017        }</tt><tt><br>
    </tt><tt>1018      MyCan.ExecuteCallbacks(p_frame, true, success);</tt><tt><br>
    </tt><tt>1019      }</tt><tt><br>
    </tt><tt>1020    </tt><tt><br>
    </tt><tt>1021    /**</tt><tt><br>
    </tt><tt>1022     * canbus::Write -- main TX API</tt><tt><br>
    </tt><tt>0x400da901 is in CAN_rxtask(void*)
(/home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/can/src/can.cpp:730).</tt><tt><br>
    </tt><tt>725                 
      me->IncomingFrame(&msg.body.frame);</tt><tt><br>
    </tt><tt>726                } while (loop);</tt><tt><br>
    </tt><tt>727              break;</tt><tt><br>
    </tt><tt>728              }</tt><tt><br>
    </tt><tt>729            case CAN_txcallback:</tt><tt><br>
    </tt><tt>730             
      msg.body.bus->TxCallback(&msg.body.frame, true);</tt><tt><br>
    </tt><tt>731              break;</tt><tt><br>
    </tt><tt>732            case CAN_txfailedcallback:</tt><tt><br>
    </tt><tt>733             
      msg.body.bus->TxCallback(&msg.body.frame, false);</tt><tt><br>
    </tt><tt>734             
      msg.body.bus->LogStatus(CAN_LogStatus_Error);</tt><br>
    <br>
    <br>
    As the frame callback invocation is secured against null, it must
    have been a missing initialization of frame.callback. So I checked
    our source tree for uses of CAN_frame_t without memset or zero
    initialization and found one in obd2ecu::IncomingFrame() -- causing
    this crash I assume -- and two more in the can rx/tx shell commands.<br>
    <br>
    Fix is in commit <a href="https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/34302254567b15a8c0f9dfb730b5cf24703ac700" target="_blank">https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/34302254567b15a8c0f9dfb730b5cf24703ac700</a><br>
    <br>
    …and build in <a href="https://ovms.dexters-web.de/firmware/ota/v3.1/edge/" target="_blank">https://ovms.dexters-web.de/firmware/ota/v3.1/edge/</a><br>
    <br>
    Greg, please test again.<br>
    <br>
    Regards,<br>
    Michael<br>
    <br>
    <br>
    <div>Am 13.12.19 um 07:09 schrieb Greg D.:<br>
    </div>
    <blockquote type="cite">
      
      Hi Michael,<br>
      <br>
      Ok, so I believe I loaded your Edge build, and the issue remains. 
      To verify, this is the string reported by the web Status page:<br>
      <br>
      3.2.007-102-g07440970/ota_1/main (build idf
      v3.3-beta3-774-g6652269e1 Dec 12 2019 11:59:14)<br>
      <br>
      Following my earlier email, I left the configuration as-is,
      including launching the obd2ecu task, but with the attached OBDII
      module removed, and the crash was resolved.  Rebooting the module
      had it come up running normally.  I then plugged in the OBDII
      module into the OVMSv3, and OVMS crashed the instant the first it
      started polling.  The device is a SyncUp Drive, which is a
      telematics and WiFi hotspot.  Connecting the OBDII device with 12v
      power off, as expected, did nothing.  Power it on, wait a few
      seconds to boot, and OVMS crashes immediately.<br>
      <br>
      New console log, attached.  It shows the module booting normally
      (OBDII device not present), followed by the device being attached
      (indicated in the log), and the subsequent crash.  I removed the
      device right after the boot started, so as to let the OVMS boot
      normally.<br>
      <br>
      So, clearly the obd2ecu task it is receiving frames on CAN3 just
      fine, but transmits back out on that same bus aren't working.  Is
      this something I need to address within obd2ecu, or is it in the
      core code?  I've not changed obd2ecu in quite some time.<br>
      <br>
      Greg<br>
      <br>
      <br>
      <div>Michael Balzer wrote:<br>
      </div>
      <blockquote type="cite">
        
        Fix commit is <a href="https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/8fef3f5fb6eec9fca26997e01d9c7d08080cdc06" target="_blank">https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/8fef3f5fb6eec9fca26997e01d9c7d08080cdc06</a><br>
        <br>
        Greg, please test.<br>
        <br>
        New build with SPIRAM fix: <a href="https://ovms.dexters-web.de/firmware/ota/v3.1/edge/" target="_blank">https://ovms.dexters-web.de/firmware/ota/v3.1/edge/</a><br>
        <br>
        Regards,<br>
        Michael<br>
        <br>
        <br>
        <div>Am 12.12.19 um 11:17 schrieb
          Michael Balzer:<br>
        </div>
        <blockquote type="cite">
          
          Last line of a2l was missing:<br>
          <br>
          <tt>#!/bin/bash</tt><tt><br>
          </tt><tt>elf=~/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/ovms3.elf</tt><tt><br>
          </tt><tt>for adr in $* ; do</tt><tt><br>
          </tt><tt>  if [[ "$adr" =~ "elf" ]] ; then</tt><tt><br>
          </tt><tt>    elf="$adr"</tt><tt><br>
          </tt><tt>  else</tt><tt><br>
          </tt><tt>    cmd+=" -ex 'l *${adr/:*/}'"</tt><tt><br>
          </tt><tt>  fi</tt><tt><br>
          </tt><tt>done</tt><tt><br>
          </tt><tt>cmd+=" -ex 'q'"</tt><tt><br>
          </tt><tt>echo "Using elf file: $elf"</tt><br>
          <tt>eval xtensa-esp32-elf-gdb -batch $elf $cmd 2>/dev/null
          </tt><br>
          <br>
          <br>
          <br>
          <div>Am 12.12.19 um 11:12 schrieb
            Michael Balzer:<br>
          </div>
          <blockquote type="cite">
            
            Mark,<br>
            <br>
            1) maybe I missed posting my later version of a2l, which
            automatically strips the stack pointers from the ":" address
            syntax so you can copy&paste the USB output. Here it is:<br>
            <br>
            <tt>#!/bin/bash</tt><tt><br>
            </tt><tt>elf=~/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/ovms3.elf</tt><tt><br>
            </tt><tt>for adr in $* ; do</tt><tt><br>
            </tt><tt>  if [[ "$adr" =~ "elf" ]] ; then</tt><tt><br>
            </tt><tt>    elf="$adr"</tt><tt><br>
            </tt><tt>  else</tt><tt><br>
            </tt><tt>    cmd+=" -ex 'l *${adr/:*/}'"</tt><tt><br>
            </tt><tt>  fi</tt><tt><br>
            </tt><tt>done</tt><tt><br>
            </tt><tt>cmd+=" -ex 'q'"</tt><tt><br>
            </tt><tt>echo "Using elf file: $elf"</tt><tt><br>
            </tt><br>
            <br>
            2) You're right, the bug is tx_frame with null origin
            overwriting body.bus in the union. I didn't notice that when
            checking Marko's submission.<br>
            <br>
            tx_frame is a copy of the last frame given to the bus for
            transmission. The queue msg is gone when the TX done IRQ
            comes in, and Marko needed a copy of the frame the TX IRQ
            relates to. I asked him (see PR discussion), he checked and
            confirmed that all TX is done sequentially, so a single
            buffer is sufficient.<br>
            <br>
            Swapping the lines would work. The frame.origin also
            shouldn't be null, but the handler should tolerate that.
            …oops, tx_frame also doesn't get initialized in the canbus
            constructor, so there's also potentially garbage in tx_frame
            if due to some bug a TX IRQ is generated or processed
            without a previous tx.<br>
            <br>
            I'll do the fixes… and also rename tx_frame to m_tx_frame
            for consistency.<br>
            <br>
            Regards,<br>
            Michael<br>
            <br>
            <br>
            <div>Am 12.12.19 um 01:20 schrieb
              Mark Webb-Johnson:<br>
            </div>
            <blockquote type="cite">
              
              <div>Two issues:</div>
              <div><br>
              </div>
              <div><u><b>1] A2L</b></u></div>
              <div><br>
              </div>
              My a2l is this:
              <div><br>
              </div>
              <blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px">
                <div>
                  <div><font face="Andale Mono"><span style="font-style:normal;font-size:14px">#!/bin/bash</span></font></div>
                  <div><font face="Andale Mono"><span style="font-style:normal;font-size:14px">elf=3.2.007.ovms3.elf</span></font></div>
                  <div><font face="Andale Mono"><span style="font-style:normal;font-size:14px">for adr in $* ; do</span></font></div>
                  <div><font face="Andale Mono"><span style="font-style:normal;font-size:14px">  if [[ "$adr" =~ "elf" ]] ; then</span></font></div>
                  <div><font face="Andale Mono"><span style="font-style:normal;font-size:14px">    elf="$adr"</span></font></div>
                  <div><font face="Andale Mono"><span style="font-style:normal;font-size:14px">  else</span></font></div>
                  <div><font face="Andale Mono"><span style="font-style:normal;font-size:14px">    cmd+=" -ex 'l *$adr'"</span></font></div>
                  <div><font face="Andale Mono"><span style="font-style:normal;font-size:14px">  fi</span></font></div>
                  <div><font face="Andale Mono"><span style="font-style:normal;font-size:14px">done</span></font></div>
                  <div><font face="Andale Mono"><span style="font-style:normal;font-size:14px">cmd+=" -ex 'q'"</span></font></div>
                  <div><font face="Andale Mono"><span style="font-style:normal;font-size:14px">echo "Using elf file: $elf"</span></font></div>
                  <div><font face="Andale Mono"><span style="font-style:normal;font-size:14px">echo "xtensa-esp32-elf-gdb -batch $elf
                        $cmd"</span></font></div>
                  <div><font face="Andale Mono"><span style="font-style:normal;font-size:14px">eval xtensa-esp32-elf-gdb -batch $elf
                        $cmd 2>/dev/null #| grep "^0x.* is in "</span></font></div>
                </div>
              </blockquote>
              <div>
                <div><br>
                </div>
                <div>When I run it, I get:</div>
                <div><br>
                </div>
              </div>
              <blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px">
                <div><font face="Andale Mono"><span style="font-style:normal;font-size:14px">$ a2l 3.2.007.ovms3.elf
                      0x400d5e4c:0x3ffc5c40 0x7ffffffd:0x3ffc5c90</span></font></div>
                <div><font face="Andale Mono"><span style="font-style:normal;font-size:14px">Using elf file: 3.2.007.ovms3.elf</span></font></div>
                <div><font face="Andale Mono"><span style="font-size:14px">xtensa-esp32-elf-gdb
                      -batch 3.2.007.ovms3.elf  -ex 'l
                      *0x400d5e4c:0x3ffc5c40' -ex 'l
                      *0x7ffffffd:0x3ffc5c90' -ex ‘q'</span></font></div>
              </blockquote>
              <div>
                <div><br>
                </div>
                <div>And a manual run gives:</div>
                <div><br>
                </div>
              </div>
              <blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px">
                <div>
                  <div><font face="Andale Mono"><span style="font-style:normal;font-size:14px">$ xtensa-esp32-elf-gdb -batch
                        3.2.007.ovms3.elf  -ex 'l
                        *0x400d5e4c:0x3ffc5c40' -ex 'l
                        *0x7ffffffd:0x3ffc5c90' -ex 'q'</span></font></div>
                  <div><font face="Andale Mono"><span style="font-style:normal;font-size:14px">Junk at end of line specification.</span></font></div>
                  <div><font face="Andale Mono"><span style="font-style:normal;font-size:14px"><br>
                      </span></font></div>
                  <div><font face="Andale Mono"><span style="font-style:normal;font-size:14px">$ </span><span style="font-size:14px">xtensa-esp32-elf-gdb 3.2.007.ovms3.elf</span></font></div>
                  <div><font face="Andale Mono"><span style="font-size:14px">GNU gdb
                        (crosstool-NG crosstool-ng-1.22.0-80-g6c4433a)
                        7.10</span></font></div>
                  <div><span style="font-size:14px;font-family:"Andale Mono"">(gdb) l
                      *0x400d5e4c:0x3ffc5c40</span></div>
                  <div><font face="Andale Mono"><span style="font-size:14px">
                        <div>Junk at end of line specification.</div>
                        <div>(gdb) l *0x7ffffffd:0x3ffc5c90</div>
                        <div>(gdb) quit</div>
                      </span></font></div>
                </div>
              </blockquote>
              <div>
                <div><br>
                </div>
                <div><u><b>2] Frame origin</b></u></div>
                <div><br>
                </div>
                <div>Regarding the CAN_txcallback, I think you are
                  correct. And both generators of that message set the
                  frame correctly. So my initial thought was that it is
                  either a memory corruption, or somewhere else sending
                  a frame with garbage data.</div>
                <div><br>
                </div>
                <div>I do see this technique used in both the mcp2515
                  and esp32can drivers:</div>
                <div><br>
                </div>
              </div>
              <blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px">
                <div>
                  <div><font face="Andale Mono"><span style="font-style:normal;font-size:14px">msg.body.bus = me;</span></font></div>
                  <div><font face="Andale Mono"><span style="font-style:normal;font-size:14px">msg.body.frame = me->tx_frame;</span></font></div>
                </div>
              </blockquote>
              <div>
                <div><br>
                </div>
                <div>I don’t normally just copy structures over like
                  that. I memcpy() them, but I guess it must work.
                  However, as our CAN_queue_msg_t is a union of
                  CAN_frame_t (frame, with first member of the structure
                  a canbus*) and 'canbus* bus’, that is a little
                  worrying. It seems that the msg.body.bus will get
                  overwritten with whatever is in msg.body.frame.origin.
                  I can’t see anywhere that tx_frame.origin is set -
                  which is scary because that would mean it is always
                  random junk.</div>
                <div><br>
                </div>
                <div>Maybe it works if tx_frame.origin is set to the bus
                  before anything else, but not in Greg’s circumstances
                  where something else arrives first. Perhaps related to
                  obd2ecu? I only see tx_frame set in can.cpp
                  canbus::Write. I don’t really understand the tx_frame
                  approach at all, and why the frame is just not passed
                  on the queue.</div>
                <div><br>
                </div>
              </div>
              <blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px">
                <div>
                  <div><font face="Andale Mono"><span style="font-style:normal;font-size:14px">// CAN Frame</span></font></div>
                  <div><font face="Andale Mono"><span style="font-style:normal;font-size:14px">// Note: Take care changing this
                        structure, as it is a union with</span></font></div>
                  <div><font face="Andale Mono"><span style="font-style:normal;font-size:14px">// CAN_log_message_t and position of
                        'origin' is fixed.</span></font></div>
                  <div><font face="Andale Mono"><span style="font-style:normal;font-size:14px">struct CAN_frame_t</span></font></div>
                  <div><font face="Andale Mono"><span style="font-style:normal;font-size:14px">  {</span></font></div>
                  <div><font face="Andale Mono"><span style="font-style:normal;font-size:14px">  canbus*     origin;                  
                        // Origin of the frame</span></font></div>
                  <div><font face="Andale Mono"><span style="font-style:normal;font-size:14px">  CanFrameCallback * callback;        
                         // Frame-specific callback. Is called when this
                        frame is successfully sent (or sending failed)</span></font></div>
                  <div><font face="Andale Mono"><span style="font-style:normal;font-size:14px">  CAN_FIR_t   FIR;                    
                         // Frame information record</span></font></div>
                  <div><font face="Andale Mono"><span style="font-style:normal;font-size:14px">  uint32_t    MsgID;                  
                         // Message ID</span></font></div>
                  <div><font face="Andale Mono"><span style="font-style:normal;font-size:14px">  union</span></font></div>
                  <div><font face="Andale Mono"><span style="font-style:normal;font-size:14px">    {</span></font></div>
                  <div><font face="Andale Mono"><span style="font-style:normal;font-size:14px">    uint8_t   u8[8];                  
                         // Payload byte access</span></font></div>
                  <div><font face="Andale Mono"><span style="font-style:normal;font-size:14px">    uint32_t  u32[2];                  
                        // Payload u32 access (Att: little endian!)</span></font></div>
                  <div><font face="Andale Mono"><span style="font-style:normal;font-size:14px">    uint64_t  u64;                    
                         // Payload u64 access (Att: little endian!)</span></font></div>
                  <div><font face="Andale Mono"><span style="font-style:normal;font-size:14px">    } data;</span></font></div>
                  <div><font face="Andale Mono"><span style="font-style:normal;font-size:14px"><br>
                      </span></font></div>
                  <div><font face="Andale Mono"><span style="font-style:normal;font-size:14px">  esp_err_t Write(canbus* bus=NULL,
                        TickType_t maxqueuewait=0);  // bus: NULL=origin</span></font></div>
                  <div><font face="Andale Mono"><span style="font-style:normal;font-size:14px">  };</span></font></div>
                  <div><font face="Andale Mono"><span style="font-style:normal;font-size:14px"><br>
                      </span></font></div>
                  <div>
                    <div><font face="Andale Mono"><span style="font-size:14px">// CAN
                          message<br>
                          typedef struct<br>
                            {<br>
                            CAN_queue_type_t type;<br>
                            union<br>
                              {<br>
                              CAN_frame_t frame;  // CAN_frame<br>
                              canbus* bus;<br>
                              } body;<br>
                            } CAN_queue_msg_t;</span></font></div>
                  </div>
                </div>
              </blockquote>
              <div>
                <div><br>
                </div>
                <div>This approach seems to date back to the swcan
                  support merge (f94ae5a1b).</div>
                <div><br>
                </div>
                <div>Should we swap around, and set the msg.body.bus
                  after msg.body.frame? Or am I missing something…</div>
                <div><br>
                </div>
                <div>Regards, Mark.</div>
                <div><br>
                  <blockquote type="cite">
                    <div>On 12 Dec 2019, at 2:29 AM, Michael
                      Balzer <<a href="mailto:dexter@expeedo.de" target="_blank">dexter@expeedo.de</a>>
                      wrote:</div>
                    <br>
                    <div>
                      
                      <div> Mark,<br>
                        <br>
                        good example why not to use addr2line: I think
                        that result is wrong. a2l uses gdb which gives:<br>
                        <br>
                        <tt><a href="mailto:balzer@leela:%7E/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3" target="_blank">balzer@leela:~/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3</a>>
                          a2l tmp/3.2.007.ovms3.elf
                          0x400d5e4c:0x3ffc5c40 0x7ffffffd:0x3ffc5c90<br>
                          Using elf file: tmp/3.2.007.ovms3.elf<br>
                          0x400d5e4c is in CAN_rxtask(void*)
(/home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/can/src/can.cpp:730).<br>
                          725                 
                          me->IncomingFrame(&msg.body.frame);<br>
                          726                } while (loop);<br>
                          727              break;<br>
                          728              }<br>
                          729            case CAN_txcallback:<br>
                          730             
                          msg.body.bus->TxCallback(&msg.body.frame,
                          true);<br>
                          731              break;<br>
                          732            case CAN_txfailedcallback:<br>
                          733             
                          msg.body.bus->TxCallback(&msg.body.frame,
                          false);<br>
                          734             
                          msg.body.bus->LogStatus(CAN_LogStatus_Error);<br>
                        </tt><tt><br>
                        </tt>…and that actually makes sense and matches
                        the register dump.<br>
                        <br>
                        If I read the gdb disassembly correctly, A10 =
                        msg.body.bus, so Greg's got a CAN_txcallback msg
                        without a bus.<br>
                        <br>
                        Hardening the rxtask against null here would
                        probably avoid the crash, but I don't see yet
                        how that could be possible.<br>
                        Both esp32can and mcp2515 set the bus field to
                        their object addresses, which cannot be null.<br>
                        <br>
                        Regards,<br>
                        Michael<br>
                        <br>
                        <br>
                        <div>Am 11.12.19 um
                          13:45 schrieb Mark Webb-Johnson:<br>
                        </div>
                        <blockquote type="cite">
                          
                          Can’t get a2l working at the moment. The
                          addr2line gives:
                          <div><br>
                          </div>
                          <blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px">
                            <div>
                              <div>addr2line -e
                                3.2.007.ovms3.elf 0x400d5e4c:0x3ffc5c40
                                0x7ffffffd:0x3ffc5c90</div>
                              <div>/home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/can/src/can.cpp:551</div>
                            </div>
                          </blockquote>
                          <div>
                            <div>
                              <div><br>
                              </div>
                              <div>That is:</div>
                              <div><br>
                              </div>
                            </div>
                          </div>
                          <blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px">
                            <div>
                              <div>
                                <div>
                                  <div>void
                                    canbus::LogInfo(CAN_log_type_t type,
                                    const char* text)</div>
                                  <div>  {</div>
                                  <div>  MyCan.LogInfo(this,
                                    type, text);    <—— HERE</div>
                                  <div>  }</div>
                                </div>
                              </div>
                            </div>
                          </blockquote>
                          <div>
                            <div>
                              <div><br>
                              </div>
                              <div>ELF is at:</div>
                              <div><br>
                              </div>
                            </div>
                          </div>
                          <blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px">
                            <div>
                              <div>
                                <div><a href="http://api.openvehicles.com/firmware/ota/v3.2/main/3.2.007.ovms3.elf" target="_blank">http://api.openvehicles.com/firmware/ota/v3.2/main/3.2.007.ovms3.elf</a></div>
                              </div>
                            </div>
                          </blockquote>
                          <div>
                            <div>
                              <div><br>
                              </div>
                              <div>Regards, Mark.</div>
                              <div><br>
                                <blockquote type="cite">
                                  <div>On 11 Dec 2019, at 5:20
                                    PM, Michael Balzer <<a href="mailto:dexter@expeedo.de" target="_blank">dexter@expeedo.de</a>>
                                    wrote:</div>
                                  <br>
                                  <div>
                                    
                                    <div>
                                      <div>Mark,<br>
                                        <br>
                                        Greg uses your build, the crash
                                        point seems to be consistent,
                                        can you post the a2l on this?<br>
                                        <br>
                                        Regards,<br>
                                        Michael<br>
                                        <br>
                                        PS: Greg, would you mind
                                        switching to EAP to beta test
                                        future releases?<br>
                                        <br>
                                        <br>
                                        Am 11.12.19 um 04:33 schrieb
                                        Greg D.:<br>
                                      </div>
                                      <blockquote type="cite">
                                        <pre>Hi folks,

Well, the module updated to 3.2.007 last night.  I just checked on it,
and it appears that it didn't exactly survive.  Crashed while running
the autoconfig script.  Log with two cycles attached.

I tried renaming the /store/events directory to /store/was_events since
it seems like Duktape was getting in the way, but that didn't resolve
the crash.  I manually enabled wifi so I could manage the module, and
moved it back to 3.2.005 from the other partition.  Seems stable again.

The car is going into the Service Center tomorrow (the perennial issue
with 1146 alerts), so I need to have the module stable so that I can
keep an eye on it.  Going to leave it on 3.2.005 for now, unless someone
has a quick fix in the next few hours...

Otherwise, any ideas for troubleshooting after I get the car back back
(hopefully end of day)?

Greg

</pre>
                                        <br>
                                        <fieldset></fieldset>
                                        <pre>_______________________________________________
OvmsDev mailing list
<a href="mailto:OvmsDev@lists.openvehicles.com" target="_blank">OvmsDev@lists.openvehicles.com</a>
<a href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" target="_blank">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
                                      </blockquote>
                                      <br>
                                      <br>
                                      <pre cols="144">-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
</pre>
                                    </div>
_______________________________________________<br>
                                    OvmsDev mailing list<br>
                                    <a href="mailto:OvmsDev@lists.openvehicles.com" target="_blank">OvmsDev@lists.openvehicles.com</a><br>
                                    <a href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" target="_blank">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br>
                                  </div>
                                </blockquote>
                              </div>
                              <br>
                            </div>
                          </div>
                          <br>
                          <fieldset></fieldset>
                          <pre>_______________________________________________
OvmsDev mailing list
<a href="mailto:OvmsDev@lists.openvehicles.com" target="_blank">OvmsDev@lists.openvehicles.com</a>
<a href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" target="_blank">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
                        </blockquote>
                        <br>
                        <pre cols="160">-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
</pre>
                      </div>
                      _______________________________________________<br>
                      OvmsDev mailing list<br>
                      <a href="mailto:OvmsDev@lists.openvehicles.com" target="_blank">OvmsDev@lists.openvehicles.com</a><br>
                      <a href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" target="_blank">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br>
                    </div>
                  </blockquote>
                </div>
                <br>
              </div>
              <br>
              <fieldset></fieldset>
              <pre>_______________________________________________
OvmsDev mailing list
<a href="mailto:OvmsDev@lists.openvehicles.com" target="_blank">OvmsDev@lists.openvehicles.com</a>
<a href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" target="_blank">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
            </blockquote>
            <br>
            <pre cols="160">-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
</pre>
            <br>
            <fieldset></fieldset>
            <pre>_______________________________________________
OvmsDev mailing list
<a href="mailto:OvmsDev@lists.openvehicles.com" target="_blank">OvmsDev@lists.openvehicles.com</a>
<a href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" target="_blank">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
          </blockquote>
          <br>
          <pre cols="160">-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
</pre>
          <br>
          <fieldset></fieldset>
          <pre>_______________________________________________
OvmsDev mailing list
<a href="mailto:OvmsDev@lists.openvehicles.com" target="_blank">OvmsDev@lists.openvehicles.com</a>
<a href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" target="_blank">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
        </blockquote>
        <br>
        <pre cols="160">-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
</pre>
        <br>
        <fieldset></fieldset>
        <br>
        <pre>_______________________________________________
OvmsDev mailing list
<a href="mailto:OvmsDev@lists.openvehicles.com" target="_blank">OvmsDev@lists.openvehicles.com</a>
<a href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" target="_blank">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
      </blockquote>
      <br>
      <br>
      <fieldset></fieldset>
      <pre>_______________________________________________
OvmsDev mailing list
<a href="mailto:OvmsDev@lists.openvehicles.com" target="_blank">OvmsDev@lists.openvehicles.com</a>
<a href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" target="_blank">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
    </blockquote>
    <br>
    <pre cols="160">-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
</pre>
  </div>

_______________________________________________<br>
OvmsDev mailing list<br>
<a href="mailto:OvmsDev@lists.openvehicles.com" target="_blank">OvmsDev@lists.openvehicles.com</a><br>
<a href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" rel="noreferrer" target="_blank">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr">Üdvözlettel:<br>Kovács Tamás<br><br></div>