<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>