[Ovmsdev] v3 hardware disconnecting from v2 server

[Mark Webb-Johnson]

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

Needs some GPIOs that we don’t have spare
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 at 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 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
>> 
>> 
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.teslaclub.hk/pipermail/ovmsdev/attachments/20180327/9995b43a/attachment-0001.html>