[Ovmsdev] v3 hardware disconnecting from v2 server

[Mark Webb-Johnson]

That is pretty cool. The ‘make monitor’ auto-magic address discovery makes the output useful:

3FFC8BAC 16 Blk tiT               484   692  6144       0      0    128
0x401fe551  0x4008ebfd  0x401f23f8  0x401ebd0c  0x401e978e  0x401e978e
0x401fe551: sys_arch_mbox_fetch at /Users/mark/esp/esp-idf/components/lwip/port/freertos/sys_arch.c:548
0x4008ebfd: xQueueGenericReceive at /Users/mark/esp/esp-idf/components/freertos/./queue.c:2037
0x401f23f8: sys_timeouts_mbox_fetch at /Users/mark/esp/esp-idf/components/lwip/core/timers.c:551
0x401ebd0c: netif_poll at /Users/mark/esp/esp-idf/components/lwip/core/netif.c:440
0x401e978e: tcpip_thread at /Users/mark/esp/esp-idf/components/lwip/api/tcpip.c:474
0x401e978e: tcpip_thread at /Users/mark/esp/esp-idf/components/lwip/api/tcpip.c:474

Now, the only issue is recreating the problem in a manner where I can get in with ‘make monitor’. Or, maybe not…

$ ~/esp/xtensa-esp32-elf/bin/xtensa-esp32-elf-addr2line -pfiaC -e build/ovms3.elf 0x401fe551  0x4008ebfd  0x401f23f8  0x401ebd0c  0x401e978e  0x401e978e
0x401fe551: sys_arch_mbox_fetch at /Users/mark/esp/esp-idf/components/lwip/port/freertos/sys_arch.c:548
0x4008ebfd: xQueueGenericReceive at /Users/mark/esp/esp-idf/components/freertos/./queue.c:2037
0x401f23f8: sys_timeouts_mbox_fetch at /Users/mark/esp/esp-idf/components/lwip/core/timers.c:551
0x401ebd0c: netif_poll at /Users/mark/esp/esp-idf/components/lwip/core/netif.c:440
0x401e978e: tcpip_thread at /Users/mark/esp/esp-idf/components/lwip/api/tcpip.c:474
0x401e978e: tcpip_thread at /Users/mark/esp/esp-idf/components/lwip/api/tcpip.c:474

It seems that I only need the ‘.elf’ file that was used to build the .bin that went on the module.

This might be workable. I will try to keep the .elf and .bin files, and see if I can get something the next time it locks up (although I think my watchdog reboot may now avoid that).

I’m 99.9% certain the issue is in the TiT tcpip task. Both wifi and pppos go down, while other parts of the system still seem to be running ok.

Regards, Mark.

> On 26 Mar 2018, at 2:33 PM, Stephen Casner <casner at acm.org> wrote:
> 
> On Sun, 25 Mar 2018, Stephen Casner wrote:
> 
>> I might be able to add an option on the command to print each task's
>> PC, which the python code would look up to translate to a source
>> line number.
> 
> I have now done this.  "module tasks" works as before, but "module
> tasks stack" shows a crude stack trace for each task.
> 
>                                                        -- Steve
> _______________________________________________
> 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.openvehicles.com/pipermail/ovmsdev/attachments/20180326/4d641e73/attachment.htm>