[Ovmsdev] v3 hardware disconnecting from v2 server

[Mark Webb-Johnson]

> Would moar printfs to pin down where it dies help?


I added a log output to ppp just after closing the connection, to see if we come back from the call to shutdown the ppp link.

> Is it possible to break into the system with gdb over the serial port and do a "thread apply all bt" or similar to get the state of all the threads? Or place a breakpoints in the right places and resume the system?


I haven’t managed to get gdb to recognise freertos tasks. I’ve seen references to doing this over JTAG, but not via gdbstub. Anybody else have any luck with this?

Regards, Mark.

> On 25 Mar 2018, at 6:10 PM, Tom Parker <tom at carrott.org> wrote:
> 
> On 25/03/18 22:58, Mark Webb-Johnson wrote:
>> I think that the housekeeping task is locked up. With the latest code I have, the per-10-minute housekeeping message has stopped.
> 
> It certainly has -- Housekeeping::Ticker1 increments monotonic and that isn't working. I had a look at the simcom power code and there is a vTaskDelay(1000 / portTICK_PERIOD_MS) in simcom::PowerCycle() but I'm not clear whether that is called when you power off the modem.
> 
>> My guess is still the ppp code, during session teardown.
> 
> Would moar printfs to pin down where it dies help? I see the watchdog changes you've added, I'm not running them yet. I'll do that tomorrow.
> 
>> I sent a detailed message on this an hour or so, with my analysis of this.
> 
> Read that, tried a few things from it.
> 
> Is it possible to break into the system with gdb over the serial port and do a "thread apply all bt" or similar to get the state of all the threads? Or place a breakpoints in the right places and resume the system?
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev