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