<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    Ok, I understand.  So what else in the active code path changes when
    simply changing the menuconfig to enable canopen?  The only things I
    "start" are the obdii ecu, wifi client, and the v2 server.  Vehicle
    is TR (not currently connected).  Config list shows:<br>
    <blockquote><tt>locations</tt><tt><br>
      </tt><tt>modem</tt><tt><br>
      </tt><tt>obd2ecu</tt><tt><br>
      </tt><tt>obd2ecu.map</tt><tt><br>
      </tt><tt>password</tt><tt><br>
      </tt><tt>server.v2</tt><tt><br>
      </tt><tt>ssh.info       (though ssh, telnet, and related stuff are
        not present)</tt><tt><br>
      </tt><tt>ssh.server</tt><tt><br>
      </tt><tt>system.adc</tt><tt><br>
      </tt><tt>vehicle        (only the Roadster is present here)</tt><tt><br>
      </tt><tt>wifi.ap</tt><tt><br>
      </tt><tt>wifi.ssid</tt><br>
    </blockquote>
    So, it must be some side-effect in the build process.  What in the
    build configuration might be enabled by the presence of the canopen
    framework, that I'm not seeing?<br>
    <br>
    Thanks,<br>
    <br>
    Greg<br>
    <br>
    <br>
    <div class="moz-cite-prefix">Michael Balzer wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:d8666cd0-6360-6717-95f8-e5e10f39192b@expeedo.de">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      Greg,<br>
      <br>
      CANopen is a general framework for CANopen devices, not
      specifically for the Twizy. The module provides tools to analyze
      and talk to CANopen nodes of any kind. It's generally useful for
      reverse engineering and getting access to vehicle components.<br>
      <br>
      Including the CANopen module makes no difference to the running
      system (except a bit of memory usage for the shell commands, see
      my earlier response to Mark), unless you explicitly start a
      CANopen process. Without a "co … start" command, there is no
      CANopen task or listener present.<br>
      <br>
      There is also no filtering code in CANopen that applies to
      anything else but the CANopen listeners.<br>
      <br>
      So your issue is certainly not related to the CANopen module, it's
      just coincidence it seemed to make a difference in your test.<br>
      <br>
      Regarding the RX performance, see my previous message. Please
      verify it's the bus, not the obd2ecu.<br>
      <br>
      Regarding the Wifi connection triggering the problem: this seems
      to match the assumed performance issue of the MCP driver.<br>
      <br>
      Regards,<br>
      Michael<br>
      <br>
      <br>
      <div class="moz-cite-prefix">Am 08.01.2018 um 20:49 schrieb Greg
        D.:<br>
      </div>
      <blockquote type="cite"
        cite="mid:50485bc0-0147-10d0-273f-d926c11e36bd@gmail.com">
        <meta http-equiv="Content-Type" content="text/html;
          charset=UTF-8">
        Hi Michael,<br>
        <br>
        Linking the several parts to this thread...  With the clarity of
        a new day, I'm being a bit more methodical, changing one thing
        at a time.  TL:DR question:  What is Canopen actively doing in a
        system without the Twizzy even present?<br>
        <br>
        Continuing on my issue isolation work from last night, it
        appears the whole 12v / modem thing might be irrelevant.  I've
        reproduced the "partial hang", where the OBDWiz dongle gets part
        way through the connect sequence before CAN3 hangs.  Metrics
        show 5 frames received, 7 transmitted.  One frame Rx overflow. 
        Error status = 0x 2040.  If I stop and restart obdii ecu, I can
        repeat the hang by restarting the connect in OBDWiz.<br>
        <br>
        The previous build was able to start OBDWiz and it ran all night
        with no issues.  The only difference between this build and the
        previous one is that I included Canopen in it.  <b>So, first
          issue:  Why would including Canopen make a difference?</b>  I
        don't have any reference to Canopen in my config, and the Twizzy
        vehicle module is not included in the build (I've got a Tesla
        Roadster).  The OBDWiz is on CAN3; CAN2 is unconnected.  The
        module is on my desk, so nothing on CAN1, either.<br>
        <br>
        The system.start script is as follows:<br>
        <blockquote>enable ******<br>
          obdii ecu start can3<br>
          power ext12v on<br>
          wifi mode client<br>
          # power simcom on<br>
          vehicle module TR<br>
          server v2 start<br>
        </blockquote>
        Note the modem enable is commented out, so the need for 12v
        power is shown to be irrelevant.  Wifi connectivity is
        effectively disabled because the only configured network is
        hidden, so it doesn't auto-connect.  <br>
        <br>
        <b>Second issue:  If I remove Canopen and change the wifi
          hotspot to be not hidden, CAN3 hangs at the point where Wifi
          auto-connects.  </b>As before, there appears to be an Rx
        overflow, but this time if I stop and restart obdii, everything
        connects and runs properly.  Wifi disconnecting doesn't affect
        the CAN bus, but when it reconnects, the hang repeats.<br>
        <br>
        I've verified with can trace that the frames truly aren't being
        received, so it's not the obd2ecu process that's hung.  Obd2ecu
        continues to process other commands normally (e.g. obdii ecu
        list).<br>
        <br>
        So, summarizing, I believe there are two issues here.  First,
        the CAN2/3 driver needs some work in handling receive
        overflows.  In theory, the CAN devices should be resilient
        enough to withstand the loss of a frame or two, and indeed, I
        see OBDwiz retrying the connect (as monitored by Wireshark via a
        CAN splitter cable).    Second, Canopen is getting in the way,
        even when it is not being used.  If I understand the ESP
        architecture, all CAN recipients get all CAN frames from all (or
        both?) CAN busses, and ignore the ones they don't need.  I'm
        guessing this filtering code in Canopen is taking too long to be
        transparent.<br>
        <br>
        Greg<br>
        <br>
        <br>
        <br>
        <div class="moz-cite-prefix">Michael Balzer wrote:<br>
        </div>
        <blockquote type="cite"
          cite="mid:c492e7ad-2616-13b8-0565-11adacd8bbd7@expeedo.de">
          <meta http-equiv="Content-Type" content="text/html;
            charset=UTF-8">
          <div class="moz-cite-prefix">Mark,<br>
            <br>
            the Twizy implementation currently depends largely on the
            CANopen framework. It may be possible to build a -very-
            restricted version without, but the result would not be used
            by any Twizy driver.<br>
            <br>
            The CANopen framework is also a general toolkit to discover
            and talk to CANopen devices, see my intro at:<br>
            <br>
            <a class="moz-txt-link-freetext"
href="https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/blob/master/vehicle/OVMS.V3/components/canopen/doc/Howto-detect-CANopen-nodes.txt"
              moz-do-not-send="true">https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/blob/master/vehicle/OVMS.V3/components/canopen/doc/Howto-detect-CANopen-nodes.txt</a><br>
            <br>
            The RAM usage of the manager module, while not having
            started a bus instance, is 24 bytes for the module state
            plus command registry. Command registry follows the approach
            of the CAN framework to do the interface selection as a
            command level. So the CANopen command registry entries
            consist of 2 + 3 * 13 = 41 commands.<br>
            <br>
            The same command registry overhead applies to all optional
            components, i.e. OBD2ECU and REtools. Maybe a better
            solution is to make all these components loadable like the
            vehicles. I saw you subclassed RE from pcp, was this meant
            to support the dynamic loading/init by means of the power
            control command, or is there another plan on this?<br>
            <br>
            Regards,<br>
            Michael<br>
            <br>
            <br>
            Am 08.01.2018 um 01:04 schrieb Mark Webb-Johnson:<br>
          </div>
          <blockquote type="cite"
            cite="mid:507CD09E-3370-47DD-A726-51FFB17BE3B6@webb-johnson.net">
            <meta http-equiv="Content-Type" content="text/html;
              charset=UTF-8">
            <div class=""><br class="">
            </div>
            <div class="">With renault twizy and canopen enabled:</div>
            <div class=""><br class="">
            </div>
            <blockquote style="margin: 0 0 0 40px; border: none;
              padding: 0px;" class="">
              <div class="">
                <div class="">OVMS > module memory</div>
                <div class="">============================</div>
                <div class="">Free 8-bit 78744/243064, 32-bit
                  29116/55900, blocks dumped = 0</div>
              </div>
            </blockquote>
            <div class=""><br class="">
            </div>
            <div class="">With renault twizy and canopen disabled:</div>
            <div class=""><br class="">
            </div>
            <blockquote style="margin: 0 0 0 40px; border: none;
              padding: 0px;" class="">
              <div class="">
                <div class="">OVMS > module memory</div>
                <div class="">============================</div>
                <div class="">Free 8-bit 84928/243096, 32-bit
                  29720/56504, blocks dumped = 0</div>
              </div>
            </blockquote>
            <div class=""><br class="">
            </div>
            <div class="">I can’t compile with canopen disabled and
              renault twizy enabled.</div>
            <div class=""><br class="">
            </div>
            <div class="">Not sure where the difference is, but it would
              be preferrable if these optional components didn’t consume
              any ram unless explicitly loaded. Using the class object
              model, and member variables, should make that relatively
              simple.</div>
            <div class=""><br class="">
            </div>
            <div class="">Regards, Mark.<br>
            </div>
          </blockquote>
          <br>
          <pre class="moz-signature" cols="144">-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
</pre>
          <br>
          <fieldset class="mimeAttachmentHeader"></fieldset>
          <br>
          <pre wrap="">_______________________________________________
OvmsDev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.teslaclub.hk" moz-do-not-send="true">OvmsDev@lists.teslaclub.hk</a>
<a class="moz-txt-link-freetext" href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev" moz-do-not-send="true">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a>
</pre>
        </blockquote>
        <br>
        <br>
        <fieldset class="mimeAttachmentHeader"></fieldset>
        <br>
        <pre wrap="">_______________________________________________
OvmsDev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.teslaclub.hk" moz-do-not-send="true">OvmsDev@lists.teslaclub.hk</a>
<a class="moz-txt-link-freetext" href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev" moz-do-not-send="true">http://lists.teslaclub.hk/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>
      <br>
      <pre wrap="">_______________________________________________
OvmsDev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.teslaclub.hk">OvmsDev@lists.teslaclub.hk</a>
<a class="moz-txt-link-freetext" href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>