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@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@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev