[Ovmsdev] Modem won't start

[Craig Leres]

On 2020-09-30 01:42, Chris van der Meijden wrote:
> Oh boy ...
> 
> Found this one:
> 
> http://lists.openvehicles.com/pipermail/ovmsdev/2020-February/006640.html
> 
> You indeed have to pull the fuse for a minute and not only for two 
> seconds ...
> 
> Very strange, but hey it works now :-)
> 
> Network Registration: RegisteredHome Provider: o2 - de+ Signal: -97 dBm 
> State: NetStart

I have not seen this issue since Mark made the change in April described 
in the attached; he added a uart_flush() call to simcom::PowerCycle():

 
https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/9de2ecd94da64da6496a57acd0286e48f93dd250

		Craig


-------- Forwarded Message --------
Subject: 	[Ovmsdev] Modem unable to power cycle successfully
Date: 	Thu, 16 Apr 2020 10:40:20 +0800
From: 	Mark Webb-Johnson <mark at webb-johnson.net>
Reply-To: 	OVMS Developers <ovmsdev at lists.openvehicles.com>
To: 	OVMS Developers <ovmsdev at lists.openvehicles.com>




I’ve seen cases where the modem will not come up correctly, even 
following a power cycle. But, a reset of the OVMS module (ESP32) solves 
the problem. This really makes no sense, unless something is getting 
corrupted inside the UART / EGPIO driver itself. The modem module status 
is not changed during an ESP32 reset - only the software side of it 
running in the ESP32.

Thomas Heder has reported some success with using uart_flush to flush 
the UART ring buffer when power cycling the modem. Flushing the buffer 
would not seem to affect this, as we use ‘AT’ to look for an OK response 
during power up check anyway; but perhaps something is corrupt in the 
ring buffer itself, so using uart_flush clears that problem.

Note that uart_flush is an alias for uart_flush_input, and the source 
code does seem to show a complete reset of the ring buffer pointers with 
interrupts disabled (not just a simple emptying).

Anyway, the approach does not seem to do any harm, so I have added it to 
the latest code and let’s see if it improves the situation.

 
https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/354


Regards, Mark.