[Ovmsdev] Cannot reset simcom stuck in PoweringOn state without removing module power

Tue Nov 19 09:36:57 HKT 2019

That makes more sense.

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.

Regards, Mark.

> On 18 Nov 2019, at 11:13 PM, Michael Balzer <dexter at expeedo.de> wrote:
> 
> Craig, Mark,
> 
> I just stumbled upon a misreading from my side:
> 
> 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.
> 
> So with a 3.1/3.2 module, there actually is a 10K pullup on both MDM_EN and MDM_DTR, before the transistor.
> 
> With that 10K, we have this transistor control:
> <ojgbfmjianhnlmjd.png>
> 
> 
> 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.
> 
> 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.
> 
> Regards,
> Michael
> 
> 
> Am 18.11.19 um 02:47 schrieb Mark Webb-Johnson:
>> 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.
>> 
>>> On 17 Nov 2019, at 8:11 PM, Michael Balzer <dexter at expeedo.de> <mailto:dexter at expeedo.de> 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:
>>>> 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
>>>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
>>> -- 
>>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
>>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>>> 
>>> 
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
> 
> -- 
> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20191119/81153dac/attachment.htm>