Derek, Given the numbers from the crash dump (in this case 0x4008e627 0x4008e8c1 0x400f2be4 0x400f3145 0x4014a7d1 0x401538b0 0x401082be 0x401092ed 0x401082be 0x40108430 0x4010a3bb 0x4010647a 0x400fb63f 0x400fb6ed), you: cd to your OVMS source tree, vehicle/OVMS.V3 directory support/a2l build/ovms3.elf 0x4008e627 0x4008e8c1 0x400f2be4 0x400f3145 0x4014a7d1 0x401538b0 0x401082be 0x401092ed 0x401082be 0x40108430 0x4010a3bb 0x4010647a 0x400fb63f 0x400fb6ed That script will decode the backtrace and give you a nice summary. You need the ovms3.elf that exactly matches the crash version. For the edge/eap/main OTA builds, we keep these online (like 3.2.014.ovms3.elf in this case). If you are building yourself, you will need the .elf file from your build. Regards, Mark.

On 26 Aug 2020, at 1:11 PM, Derek Caudwell <d.caudwell@gmail.com> wrote:

Hi Mark

This looks like the same issue I have been having/trying to debug (re: frequent crashes thread).

I had not realised I could get a more detailed trace. Does it have to be enabled prior to crash or can you enable it afterwards?

On my local build I have implemented Michael's suggested change in event script task priority to 19 and disabled Mcp2515 error logging on buffer overflow, which has helped but not entirely resolved the issue. There are also some issues relating to polling in the Leaf because of the two buses I am working on, I think these may be unrelated to the event ticker crash messages though (which can happen when not using web ui as well).

Kind regards Derek _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev