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