<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="">I’m just glad it wasn’t a hardware issue. I checked through my mails, and found we did spend quite some time on this with the guys in China when we did the final prototypes for v3.1; everything looked very stable back then.<div class=""><br class=""></div><div class="">Thanks for the feedback, and working through this problem. Hopefully the issue Craig reported, I hope it is either v3.0 dev hardware (pre pull-up) or something else.</div><div class=""><br class=""></div><div class="">Regards, Mark.<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 21 Nov 2019, at 5:46 PM, Michael Balzer <<a href="mailto:dexter@expeedo.de" class="">dexter@expeedo.de</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
  
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" class="">
  
  <div class="">
    Shame on me. Reminder: expect the unexpected.<br class="">
    <br class="">
    The egpio monitor actually caused this. Or more precisely, the
    MAX7317 input query, which was broken in a remarkable way.<br class="">
    <br class="">
    Explanation:<br class="">
    <br class="">
    The MAX7317 needs a deselect between addressing a register for read
    and reading the value returned. On the second SPI command to read
    the value, no TX was requested, just the two bytes RX.<br class="">
    <br class="">
    But on SPI, there is no "no TX". An SPI transaction always is TX and
    RX in parallel. Doing a 0 byte TX + 2 byte RX SPI command via our
    SPI API actually means you'll be doing a TX of two zero bytes to the
    device while reading two bytes from the device.<br class="">
    <br class="">
    And if you send two zero bytes to the MAX7317, it will interpret
    that as "set output port 0 to level 0"…<br class="">
    <br class="">
    While that's totally clear from the datasheet: in my humble opinion,
    requiring separate request & response transactions and then
    assigning a command to a sequence of all zero bytes is bad design.<br class="">
    <br class="">
    NOP on the MAX7317 is 0x20, so I've changed the input query to send
    that while receiving the result.<br class="">
    <br class="">
    Thanks, Mark.<br class="">
    <br class="">
    Back to the original issue: Input monitoring is disabled by default.
    Craig, you reported not being able to power down the modem 2 hours
    after I pushed the egpio monitoring. Did you have the issue with
    input monitoring enabled? If not, the issue still needs to be
    resolved.<br class="">
    <br class="">
    Regards,<br class="">
    Michael<br class="">
    <br class="">
    <br class="">
    <div class="moz-cite-prefix">Am 21.11.19 um 00:57 schrieb Mark
      Webb-Johnson:<br class="">
    </div>
    <blockquote type="cite" cite="mid:C5BB318E-8E00-4002-B650-32E7A0115268@webb-johnson.net" class="">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" class="">
      Michael,
      <div class=""><br class="">
      </div>
      <div class="">The manufacturer is having problems repeating the
        problem. He is looking at the voltage on MDM_EN when toggling
        EGPIO #0, using the v3.2 hardware, and says it switches properly
        for him. I did a quick check with some 3.1 hardware, and it
        seems ok for me as well (although I only used a multi-meter, not
        an oscilloscope).</div>
      <div class=""><br class="">
      </div>
      <div class="">Can you confirm what version of board (main board
        and modem) that you are using to recreate this problem? Also
        version of firmware and that the new egpio monitor feature is
        off (in case that is interfering in some way)?</div>
      <div class=""><br class="">
      </div>
      <div class="">Regards, Mark<br class="">
        <div class=""><br class="">
          <blockquote type="cite" class="">
            <div class="">On 19 Nov 2019, at 9:36 AM, Mark Webb-Johnson
              <<a href="mailto:mark@webb-johnson.net" class="" moz-do-not-send="true">mark@webb-johnson.net</a>>
              wrote:</div>
            <br class="Apple-interchange-newline">
            <div class="">
              <meta http-equiv="Content-Type" content="text/html;
                charset=UTF-8" class="">
              <div style="word-wrap: break-word; -webkit-nbsp-mode:
                space; line-break: after-white-space;" class="">That
                makes more sense.
                <div class=""><br class="">
                </div>
                <div class="">I have passed on the information to the
                  manufacturer, as he is best placed to check what is
                  going on. I suggested to him that he can recreate the
                  issue by powering off the SIMCOM (or not powering it
                  on in the first place) and then using 'egpio output 0
                  0’ and 'egpio output 0 1’ to test. He should be able
                  to give us a reply later this week.</div>
                <div class=""><br class="">
                </div>
                <div class="">Regards, Mark.<br class="">
                  <div class=""><br class="">
                    <blockquote type="cite" class="">
                      <div class="">On 18 Nov 2019, at 11:13 PM, Michael
                        Balzer <<a href="mailto:dexter@expeedo.de" class="" moz-do-not-send="true">dexter@expeedo.de</a>>
                        wrote:</div>
                      <br class="Apple-interchange-newline">
                      <div class="">
                        <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" class="">
                        <div class=""> Craig, Mark,<br class="">
                          <br class="">
                          I just stumbled upon a misreading from my
                          side:<br class="">
                          <br class="">
                          I had accidentally taken the v3.0 schematics
                          of the main board for reference, that only had
                          pull-ups on ports 1 & 2. There was a
                          change in v3.1 adding pull-up resistors on
                          ports 0 & 3 as well.<br class="">
                          <br class="">
                          So with a 3.1/3.2 module, there actually is a
                          10K pullup on both MDM_EN and MDM_DTR, before
                          the transistor.<br class="">
                          <br class="">
                          With that 10K, we have this transistor
                          control:<br class="">
                          <span id="cid:part1.8D922A6C.F803CC13@expeedo.de" class=""><ojgbfmjianhnlmjd.png></span><br class="">
                          <br class="">
                          <br class="">
                          That should result in ~1.5V at the base on
                          MDM_EN high, enough for the transistor to
                          switch, so I don't know what's going wrong
                          here.<br class="">
                          <br class="">
                          You can access both pullups from the side,
                          they are located left of the S2 switch on the
                          main board. R8 is on MDM_EN, R9 on MDM_DTR. R8
                          shows that very short rise in voltage on
                          transition to high, while R9 shows the
                          expected behaviour of a constant +3.3 when the
                          port is high.<br class="">
                          <br class="">
                          Regards,<br class="">
                          Michael<br class="">
                          <br class="">
                          <br class="">
                          <div class="moz-cite-prefix">Am 18.11.19 um
                            02:47 schrieb Mark Webb-Johnson:<br class="">
                          </div>
                          <blockquote type="cite" cite="mid:96E4F7CB-37A8-423B-9D7D-FCF76C5D34C5@webb-johnson.net" class="">
                            <pre class="moz-quote-pre" wrap="">I don’t think that circuit has changed since the very first v1 of OVMS. Maybe we have been lucky in the past with the timing?

I will discuss it with the manufacturer, as that part of the circuit is his design and he should know the thinking behind it the best.

Our intention it have EGPIO #0 able to control the PWRKEY of the modem - so as to be able to power it up/down under program control. We are not really controlling the power to the modem - more telling the modem to control itself.

Regards, Mark.

</pre>
                            <blockquote type="cite" class="">
                              <pre class="moz-quote-pre" wrap="">On 17 Nov 2019, at 8:11 PM, Michael Balzer <a class="moz-txt-link-rfc2396E" href="mailto:dexter@expeedo.de" moz-do-not-send="true"><dexter@expeedo.de></a> wrote:

I also saw this & can also reproduce this on my workbench.

Mark, it seems we've got a hardware flaw here: EGPIO output port 0 (MDM_EN) is connected to transistor Q2 base via R16 without any pull-up. As the EGPIO ports
are open drain, that can only work by chance. Maybe R16 was meant to be the pull-up, i.e. be connected to +3.3V, and MDM_EN should be connected directly to the
transistor base?

I've verified this by checking the voltage level at MDM_EN & PWRKEY. When setting the port to 1, MDM_EN only rises for a very short time (too short for my
multimeter to tell), and PWRKEY only drops very briefly. The modem needs PWRKEY low for at least 180ms to power up and at least 500ms to power down.

Manually pushing S1 reliably switches the modem on/off.

Maybe a fix for existing boards could be adding a pullup resistor at the transistor base?

Regards,
Michael


Am 17.11.19 um 02:39 schrieb Craig Leres:
</pre>
                              <blockquote type="cite" class="">
                                <pre class="moz-quote-pre" wrap="">Maybe this has been discussed and I missed it but occasionally I'll get a module with the modem/simcom stuck in the PoweringOn state. Rebooting does not fix
this.

I thought I saw that you could reset the simcom with:

    power simcom off
    [wait a minute]
    power simcom on

but that doesn't work. I turned up some logging:

    log monitor
    log level verbose simcom

and I see this happen about every 30 seconds:

    I (2204129) simcom: State timeout, transition to 2
    I (2204129) simcom: State: Enter PoweringOn state
    I (2204129) simcom: Power Cycle

I thought this level of logging would let me see the results of command like:

    simcom muxtx 3 at+csq

(signal quality) but I don't see anything after sending it.

Is there a way to hardware reset the simcom? (Is there any reason this doesn't happen when the ovms module reboots?)

        Craig
_______________________________________________
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>
                              <pre class="moz-quote-pre" wrap="">-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26


_______________________________________________
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>
                            <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 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.openvehicles.com" class="" moz-do-not-send="true">OvmsDev@lists.openvehicles.com</a><br class="">
                        <a href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" class="" moz-do-not-send="true">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br class="">
                      </div>
                    </blockquote>
                  </div>
                  <br class="">
                </div>
              </div>
              _______________________________________________<br class="">
              OvmsDev mailing list<br class="">
              <a href="mailto:OvmsDev@lists.openvehicles.com" class="" moz-do-not-send="true">OvmsDev@lists.openvehicles.com</a><br class="">
              <a class="moz-txt-link-freetext" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br class="">
            </div>
          </blockquote>
        </div>
        <br class="">
      </div>
      <br class="">
      <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 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.openvehicles.com" class="">OvmsDev@lists.openvehicles.com</a><br class="">http://lists.openvehicles.com/mailman/listinfo/ovmsdev<br class=""></div></blockquote></div><br class=""></div></body></html>