[Ovmsdev] LoadProhibited exception on core 0

Wed Jul 5 07:39:47 HKT 2023

Not sure how reliable that short backtrack is, but here is what it shows:

$ ../a2l ovms3.elf 0x4028128f 0x402823bf
Using elf file: ovms3.elf
0x4028128f is in mdns_parse_packet (C:/Users/soko/Source/OVMS/home/soko/esp-idf/components/mdns/mdns.c:2839).
0x402823bf is in _mdns_service_task (C:/Users/soko/Source/OVMS/home/soko/esp-idf/components/mdns/mdns.c:3545).
3540	in C:/Users/soko/Source/OVMS/home/soko/esp-idf/components/mdns/mdns.c

So that implies a crash parsing a MDNS packet.

If that is repeatable, it would be a bug in the ESP IDF for mdns. You could try disabling CONFIG_OVMS_COMP_MDNS in your build and see if that works around the issue. There is also CONFIG_MDNS_TASK_STACK_SIZE and CONFIG_MDNS_MAX_SERVICES which may be related. But that is based on the single backtrace, which may be wrong.

The only other thing I can think of is the MDNS service packets we transmit. What is your vehicle ID? Anything unusual (non-ascii characters, long length, etc)?

Regards, Mark

> On 4 Jul 2023, at 6:10 PM, Soko <ovms at soko.cc> wrote:
> 
> Hi Mark,
> 
> I have the exact bin & elf I'm using (I've compiled it myself back in the day...). I've also found the script you are mentioning, but it seems to be a linux script, I'm on windows.
> Looking at the script though - educated guessing - it just looks at the address in the ELF file.
> Opening the ELF file with an hex-editor in windows reveals it ends at 0x0240D5DB.
> 
> <vwPxeAnwFzenPgJR.png>
> 
> Do I have to translate the address somehow? Or is the a2l script doing more than just looking.
> 
> I've also uploaded the bin & elf (http://soko.yourweb.de/ovms3.zip) if you wonna have a quick look.
> 
> The backtrace (0x4028128f 0x402823bf) is more or less the only constant numbers I get with each crash. So if they are too short can I add/activate some trace which leads to more info without connecting to a laptop (my old devenv doesn't seem to work anymore, and it was Windows anyhow...)
> 
> thx
> Soko
> 
> 
> On 04.07.2023 03:01, Mark Webb-Johnson wrote:
>> To understand what is going on, you’ll need to get the ELF file for the *exact* build of firmware you are using, and then use the support/a2l script to decode the backtrace addresses to something human readable. If you can’t do this, you could try by letting us know the firmware version you are running, where you got it from (API or Dexters), and provide the backtrace addresses. If you are using standard firmware builds, you can normally find the .elf file by simply change ovms3.bin to ovms3.elf in the download URL.
>> 
>> Alternatively, connect the module over USB to a laptop/workstation running the development build environment and GDB stub running to capture the panic.
>> 
>> The backtrace you show below (0x4028128f 0x402823bf) does not seem to be valid (too short), and probably won’t help much.
>> 
>> Regards, Mark.
>> 
>>> On 4 Jul 2023, at 5:41 AM, Soko <ovms at soko.cc> <mailto:ovms at soko.cc> wrote:
>>> 
>>> Hi guys,
>>> 
>>> Running happily my OVMS on my VW e-Up since 2020 it drives my crazy since today :(
>>> 
>>> It restarts roughly every minute with this status afterwards:
>>> ------------
>>> Last boot was 28 second(s) ago
>>> Time at boot: 2023-07-03 21:25:07 CEST
>>> This is reset #1 since last power cycle
>>> Detected boot reason: Crash (12/12)
>>> Reset reason: Exception/panic (4)
>>> Crash counters: 1 total, 0 early
>>> 
>>> Last crash: LoadProhibited exception on core 0
>>> Registers:
>>> PC : 0x4028128f PS : 0x00060d30 A0 : 0x802823c2 A1 : 0x3ffe71d0
>>> A2 : 0x3ffe9f9c A3 : 0x00000000 A4 : 0x00000000 A5 : 0x00000001
>>> A6 : 0x3ffe9fe8 A7 : 0x3ffe71d0 A8 : 0x0000005b A9 : 0xffffffff
>>> A10 : 0x00000e10 A11 : 0x0000000e A12 : 0x00000010 A13 : 0x3ffbd3ac
>>> A14 : 0x3f84e83c A15 : 0x3ffbd46b SAR : 0x00000010 EXCCAUSE: 0x0000001c
>>> EXCVADDR: 0x00000004 LBEG : 0x4008b0e9 LEND : 0x4008b11d LCOUNT : 0x00000000
>>> Backtrace:
>>> 0x4028128f 0x402823bf
>>> ------------
>>> 
>>> And now the crazy part: It only happens when I'm connected to a specific WiFi/network?!?!
>>> 
>>> What I've tried so far:
>>> Factory Reset (multiple times)
>>> Set a static IP address
>>> Reconnect all cables and make sure all are snug and tight
>>> Brought OVMS closer to the AP (only one, no mesh)
>>> Restarted AP
>>> Restarted DNS & DHCP Server
>>> It even happens when I have no vehicle selected after a factory reset
>>> It gets more crazy: My WiFi is via Unifi/Ubiquity. So I can have multiple SSIDs with the same AP. So all hardware involved is the same...
>>> 
>>> When I connect to SSID "E3200", which is network 192.168.254.0/24, the exception happens every minute or so.
>>> When I connect to SSID "SurfHere" which is network 192.168.179.0/24, everything works fine!
>>> 
>>> Do you guys have any idea why this is happening?
>>> 
>>> I've tried to look at logs via Shell and "log level verbose" but nothing shows up. Is there more I can activate to log this issue?
>>> 
>>> Maybe my hardware is faulty... Where do I get a new OVMS here in Europe/EU/Austria? Do I have to import in from the UK (https://shop.openenergymonitor.com/ovms/)?
>>> 
>>> thanks heaps in advance,
>>> Soko
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>> 
>> 
>> 
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
> 
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20230705/8f965ded/attachment.htm>