[Ovmsdev] v3 hardware disconnecting from v2 server

[Stephen Casner]

I have not dug deeply, but all the references I have seen to using gdb
for debugging on the ESP32 require extra JTAG hardware.  The
ESP-WROVER-KIT includes the FTDI FT2232HL USB bridge that allows a
JTAG connection over USB in addition to the UART connection.  I don't
know if it would have been feasible to include that debugging function
into the OVMS v3 hardware design.

                                                        -- Steve

On Mon, 26 Mar 2018, Mark Webb-Johnson wrote:

> > 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
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>
>