[Ovmsdev] ppp problem on disconnect

Mark Webb-Johnson mark at webb-johnson.net
Mon Dec 11 14:34:06 HKT 2017


I’ve committed all my changes, to improve the testing environment for this:

Documented the existing SIMCOM states
Split NetStart state into NetWait (waiting for cellular connection) and NetStart (start the PPP data session at the SIMCOM level)
Added a ‘simcom setstate’ command to be able to manually force a state (in particular force a cellular connection loss, rather than having to wait for it)
Sped up some of the detection checks (in particular, NetStart and NetWait).

It all look good, but then led to another issue:

D (40125) SIMCOM line: 55 4e 44 45 52 2d 56 4f 4c 54 41 47 45 20 57 41 UNDER-VOLTAGE WA
D (40125) SIMCOM line: 52 4e 4e 49 4e 47 20 50 4f 57 45 52 20 44 4f 57 RNNING POWER DOW
D (40125) SIMCOM line: 4e                                              N

D (40145) SIMCOM line: 73 74 61 72 74 69 6e 67 20 70 6f 77 65 72 20 6f starting power o
D (40145) SIMCOM line: 66 66 20 74 68 65 20 6d 6f 64 75 6c 65 21       ff the module!

Good grief. I guess my USB port doesn’t have enough power. Perhaps related to the SIMCOM GPS being enabled by default? A complete power down resolved this.

Anyway, I can now at least simulate a loss of cellular connectivity (simcom setstate NetWait). I can now try to find out a way to properly tear down the PPP connection (both at the lwip pppos and simcom levels). Very frustrating there are no good examples for lwip ppos (many show how to establish, but none show best practices for modem scripting and handling loss of connectivity).

Regards, Mark.

> On 11 Dec 2017, at 9:55 AM, Mark Webb-Johnson <mark at webb-johnson.net> wrote:
> 
> I’m aware of this, and working on it.
> 
> Something strange going on in the lwip pppos api. Seems to not be returning from the shutdown call, so our simcom thread gets locked up. Also messes up the main freertos threads (I think those drive the event timers for lwip).
> 
> I am working on a re-factor of the simcom state diagram to simplify the way we drive this, and also an ability to force a state change by command. At the moment, too much is being done in state NetMode. My test-debug cycle is also way too long (plug in antenna, power up simcom, wait for cellular connectivity, wait for GSM lock, wait for mux, wait for CSQ, wait for PPP, then disconnect antenna, and wait again…), can only be done in areas of poor cellular connectivity, and is driving me crazy. That should speed up debugging this issue. I’m working on it…
> 
> Regards, Mark.
> 
>> On 11 Dec 2017, at 2:55 AM, Michael Balzer <dexter at expeedo.de> wrote:
>> 
>> Just had this after letting the module idle for a while:
>> 
>>>> I (11249582) simcom: CREG Network Registration: RegisteredRoaming
>> I (11253822) ovms-server-v2: Send MP-0 D0,0,5,0,0,-40,0,0,0,11251,0,0,1,0,0.373626,0,0,0,0,0
>> I (11273832) ovms-server-v2: Send MP-0 D0,0,5,0,0,-40,0,0,0,11271,0,0,1,0,0.401099,0,0,0,0,0
>> I (11279582) simcom: CREG Network Registration: RegisteredRoaming
>> I (11282842) ovms-server-v2: Send MP-0 D0,0,5,0,0,-40,0,0,0,11280,0,0,1,0,0.362637,0,0,0,0,0
>> I (11286902) simcom: PPP Connection disconnected
>> I (11286902) simcom: PPP Connection disconnected
>> I (11287562) simcom: Lost network connection (+PPP disconnect in NetMode)
>> I (11287562) gsm-ppp: Shutting down (hard)...
>> I (11287562) simcom: State: Enter NetStart state
>> I (11287562) gsm-nmea: Startup
>> I (11292662) gsm-ppp: StatusCallBack: User Interrupt
>> E (11292662) gsm-ppp: status_cb: User interrupt|
>> I (11292662) gsm-ppp: Shutdown (via status callback)
>> I (11292662) events: Signal(system.modem.down)
>> I (11292662) events: Signal(network.modem.down)
>> I (11292852) ovms-server-v2: Send MP-0 D0,0,5,0,0,-40,0,0,0,11290,0,0,1,0,0.417582,0,0,0,0,0
>> I (11292902) simcom: PPP Connection disconnected
>> I (11292902) simcom: PPP Connection disconnected
>> I (11292902) simcom: PPP Connection disconnected
>> I (11299592) simcom: PPP Connection is ready to start
>> I (11300562) simcom: State: Enter NetMode state
>> I (11300562) gsm-ppp: Initialising...
>> OVMS > Task watchdog got triggered. The following tasks did not feed the watchdog in time:
>> - IDLE (CPU 0)
>> Tasks currently running:
>> CPU 0: tiT
>> CPU 1: ipc1
>> Task watchdog got triggered. The following tasks did not feed the watchdog in time:
>> - IDLE (CPU 0)
>> Tasks currently running:
>> CPU 0: tiT
>> CPU 1: ipc1
>> Task watchdog got triggered. The following tasks did not feed the watchdog in time:
>> - IDLE (CPU 0)
>> Tasks currently running:
>> CPU 0: tiT
>> CPU 1: ipc1
>>>> 
>> … and so on, no more input reaction from the shell here, had to do a reset.
>> 
>> Regards,
>> Michael
>> 
>> -- 
>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>> 
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.teslaclub.hk
>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
> 
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20171211/839ad5ba/attachment.htm>


More information about the OvmsDev mailing list