[Ovmsdev] Cannot reset simcom stuck in PoweringOn state without removing module power
Mark Webb-Johnson
mark at webb-johnson.net
Fri Nov 22 09:42:33 HKT 2019
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.
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.
Regards, Mark.
> On 21 Nov 2019, at 5:46 PM, Michael Balzer <dexter at expeedo.de> wrote:
>
> Shame on me. Reminder: expect the unexpected.
>
> The egpio monitor actually caused this. Or more precisely, the MAX7317 input query, which was broken in a remarkable way.
>
> Explanation:
>
> 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.
>
> 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.
>
> And if you send two zero bytes to the MAX7317, it will interpret that as "set output port 0 to level 0"…
>
> 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.
>
> NOP on the MAX7317 is 0x20, so I've changed the input query to send that while receiving the result.
>
> Thanks, Mark.
>
> 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.
>
> Regards,
> Michael
>
>
> Am 21.11.19 um 00:57 schrieb Mark Webb-Johnson:
>> Michael,
>>
>> 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).
>>
>> 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)?
>>
>> Regards, Mark
>>
>>> On 19 Nov 2019, at 9:36 AM, Mark Webb-Johnson <mark at webb-johnson.net <mailto:mark at webb-johnson.net>> wrote:
>>>
>>> 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 <mailto: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 <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>
>>
>>
>>
>> _______________________________________________
>> 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/20191122/7341a31d/attachment.htm>
More information about the OvmsDev
mailing list