ESP32 - Firmware Issue
ConnorHowell opened this issue · 4 comments
Hey, just tried to use this brilliant project but the ESP32 firmware seems to fail even on just logging a simple UDS request for the VIN.
In Wireshark it logged the RDBI request a couple hundred times before the firmware crashed and rebooted.
Let me know if you need any additional info! (This happened both when tracing datagrams and just the raw socketcan style output)
Guru Meditation Error: Core 1 panic'ed (StoreProhibited). Exception was unhandled.
Core 1 register dump:
PC : 0x4000c325 PS : 0x00060130 A0 : 0x800d6793 A1 : 0x3ffc9190
A2 : 0x00000000 A3 : 0x3ffb4fe2 A4 : 0x00000003 A5 : 0x00000000
A6 : 0x0000f122 A7 : 0x00000000 A8 : 0x00000000 A9 : 0x3ffc9160
A10 : 0x00000000 A11 : 0x00000004 A12 : 0x00060b20 A13 : 0x3ffc91fc
A14 : 0x00000003 A15 : 0xaa90f122 SAR : 0x0000001f EXCCAUSE: 0x0000001d
EXCVADDR: 0x00000000 LBEG : 0x4000c2e0 LEND : 0x4000c2f6 LCOUNT : 0xffffffff
Backtrace:0x4000c322:0x3ffc91900x400d6790:0x3ffc91a0 0x400d6bee:0x3ffc91e0 0x400d6d4d:0x3ffc9220 0x400d5ff8:0x3ffc9260 0x400d601d:0x3ffc92a0 0x4008b631:0x3ffc92c0
0x400d6790: Task_Tcp_Wireshark_Raw_AddNewRawMessage at ~/Downloads/Monitor-master/Firmware/ESP32/main/Task_Tcp_Wireshark_Raw.c:270
0x400d6bee: Passive_Iso15765_SingleFrame at ~/Downloads/Monitor-master/Firmware/ESP32/main/Passive_Iso15765.c:60
0x400d6d4d: Passive_Iso15765_Parse at ~/Downloads/Monitor-master/Firmware/ESP32/main/Passive_Iso15765.c:140
0x400d5ff8: ProcessCanElements at ~/Downloads/Monitor-master/Firmware/ESP32/main/Task_CanReconstruct.c:63
0x400d601d: Task_CanReconstruct at ~/Downloads/Monitor-master/Firmware/ESP32/main/Task_CanReconstruct.c:39 (discriminator 1)
0x4008b631: vPortTaskWrapper at ~/esp/esp-idf/components/freertos/port/xtensa/port.c:131
Hi, I know about the problem I have made some weird error when I was porting code from STM32F4 (where it works just fine) to ESP32. It is also #1 but I have never attempted to fix that as I was using other tools which I have at my disposal.
Will try to work on that to fix this issue. From my research in #1 it seems like it is some misconfiguration of LWIP, but I don't have much experience with this subsystem.
At least in my case it seems to not be freeing up memory when sending a packet which is why it spams the same CAN message over and over, eventually running out of memory then throwing this exception.
In this instance I was testing it with just my custom diagnostic tool hooked up and simply sending 1 request for the VIN, but Wireshark was filled with hundreds of the same packet.
I'll do some more testing with this when I get a chance and see if I can figure out the issue!
Bug is now fixed, at least for me. During copying of malloc, I have forget to remove sizeof getting something like pvPortMalloc(sizeof(length)) and allocating only 4 bytes for a whole frame instead of allocating length amount of bytes
Closed