I did look at JTAG, but it would have meant a few changes:

  1. Needs some GPIOs that we don’t have spare
  2. Needs to change to FTDI dual async chip

Overall, just too risky to add at the late stage, so we didn’t attempt it.

Regards, Mark.

On 27 Mar 2018, at 3:26 AM, Stephen Casner <casner@acm.org> wrote:

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@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

_______________________________________________
OvmsDev mailing list
OvmsDev@lists.teslaclub.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev


_______________________________________________
OvmsDev mailing list
OvmsDev@lists.teslaclub.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev