Random reboots through out the day with InfluxDB API enabled about diybmsv4esp32

[atanisoft]

[D][influxdb.cpp:47] influxdb_onData(): Influx data received
assertion "new_rcv_ann_wnd <= 0xffff" failed: file "/home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/lwip/lwip/src/core/tcp.c", line 779, function: tcp_update_rcv_ann_wnd
abort() was called at PC 0x4011bc57 on core 0

ELF file SHA256: 0000000000000000

Backtrace: 0x40090d8c:0x3ffe0ee0 0x40091009:0x3ffe0f00 0x4011bc57:0x3ffe0f20 0x401495be:0x3ffe0f50 0x40149645:0x3ffe0f70 0x400e552a:0x3ffe0f90 0x401487a0:0x3ffe0fb0 0x40092cf6:0x3ffe0fe0

Rebooting...
ets Jun  8 2016 00:22:57

The assert is coming from this line, it looks like a data overrun (too much data being RX or TX?).

@magpern Can you decode the rest of the backtrace to determine which part of diyBMS (if any) was involved?

[magpern]

@magpern Can you decode the rest of the backtrace to determine which part of diyBMS (if any) was involved?

I probably can, but how?

Right now I am just dumping what ever I get from the ESP32 through a python script running on a raspberry pi

[atanisoft]

You should be able to use decoder.py from https://github.com/me21/EspArduinoExceptionDecoder as:

decoder.py -p ESP32 -t ~/.platformio/packages/toolchain-xtensa32 -e {path to the diyBMS elf file} {file containing the backtrace}

Also note that this issue should really be over on https://github.com/stuartpittaway/diyBMSv4ESP32 (which @stuartpittaway likely can move it there)

[stuartpittaway]

Thanks for taking a look @atanisoft you are used to decoding these dumps more than I am.

I was hoping it was just a stack over flow, no such luck.

@magpern can you tell me about your build, number of modules etc.

If you disable influx integration do the reboots stop?

[magpern]

@stuartpittaway you have access to my diybms on patreon message

I will try to disable Influx, since I am not using it at the moment. I will report back

[stuartpittaway]

Ah, ok, was it enabled but the influx server switched off??

I've had another user report an issue when the influx server was rebooted and the http call failed.

[magpern]

No Influx is running, I just have not started using the data. So it is not important to me, yet!

[stuartpittaway]

Did you get chance to look at the exceptoin decoder?

[atanisoft]

PlatformIO may also be able to automatically decode the backtrace if you are using it to monitor the ESP32.

[magpern]

I have had Infuxdb integration turned off, since yesterday. No reboots has occured since then.

[stuartpittaway]

Trying to lift the lid on this problem, managed to get this exception dump when influx settings are configured to point to a network address which doesn't exist.

[W][AsyncTCP.cpp:949] _poll(): pcb is NULL
[E][AsyncTCP.cpp:953] _poll(): 0x3fff1ad0 != 0x2200a8c0
[W][AsyncTCP.cpp:949] _poll(): pcb is NULL
[E][AsyncTCP.cpp:953] _poll(): 0x3fff1ad0 != 0x2200a8c0
[I][Rules.cpp:128] SetWarning(): Set warning 4
[W][AsyncTCP.cpp:949] _poll(): pcb is NULL
Guru Meditation Error: Core  1 panic'ed (InstrFetchProhibited). Exception was unhandled.
Core 1 register dump:
PC      : 0x00001670  PS      : 0x00060930  A0      : 0x800f18fb  A1      : 0x3fff0d60  
A2      : 0x3fff1938  A3      : 0x02180005  A4      : 0x3fff18f4  A5      : 0xfffffff3
A6      : 0x00000000  A7      : 0x3ffecec0  A8      : 0x800f18a9  A9      : 0x3fff0d40  
A10     : 0x3fff1938  A11     : 0x3fff0d6c  A12     : 0x3fff0d68  A13     : 0x3fff0d64
A14     : 0x00000020  A15     : 0x00000000  SAR     : 0x00000004  EXCCAUSE: 0x00000014  
EXCVADDR: 0x00001670  LBEG    : 0x4000c2e0  LEND    : 0x4000c2f6  LCOUNT  : 0xffffffff

ELF file SHA256: 0000000000000000

Backtrace: 0x00001670:0x3fff0d60 0x400f18f8:0x3fff0d90 0x400f1914:0x3fff0db0 0x400f1c4c:0x3fff0dd0 0x400f1cdd:0x3fff0df0 0x40092cee:0x3fff0e20
  #0  0x00001670:0x3fff0d60 in ?? ??:0
  #1  0x400f18f8:0x3fff0d90 in AsyncClient::_error(signed char) at .pio\libdeps\esp32-devkitc-debug\AsyncTCP\src/AsyncTCP.cpp:1039
  #2  0x400f1914:0x3fff0db0 in AsyncClient::_s_error(void*, signed char) at .pio\libdeps\esp32-devkitc-debug\AsyncTCP\src/AsyncTCP.cpp:1039
  #3  0x400f1c4c:0x3fff0dd0 in _handle_async_event(lwip_event_packet_t*) at .pio\libdeps\esp32-devkitc-debug\AsyncTCP\src/AsyncTCP.cpp:1039
  #4  0x400f1cdd:0x3fff0df0 in _async_service_task(void*) at .pio\libdeps\esp32-devkitc-debug\AsyncTCP\src/AsyncTCP.cpp:1039
  #5  0x40092cee:0x3fff0e20 in vPortTaskWrapper at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/freertos/port.c:355 (discriminator 1)    

Rebooting...
ets Jun  8 2016 00:22:57

rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DOUT, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:1044
load:0x40078000,len:10124
load:0x40080400,len:5828
entry 0x400806a8

[stuartpittaway]

Ok.

This looks like a sequencing issue in the code. The ASYNC client attempts to connect to the HTTP server - if it fails, it takes several seconds for it to timeout. If during this timeout the code is called again (by the task timer) then its likely to fail/stack dump.

[stuartpittaway]

Hi @magpern I think I've fixed this issue with some changes to the order the code gets run in.

Can you test and feedback please?

[voort4444]

i will give it a try tonight. nod need to update de modules them selves I think?

[stuartpittaway]

No, just the controller

[voort4444]

Hi Stuart, for me this seems to work; normally the moment the inluxdb server was unavailable, the controller started rebooting inmeadately. Not so now. I ll leave the linfxdb off for a night and report back tomorrow

[stuartpittaway]

Great that sounds promising

[voort4444]

I'm 12 hours into testing with infludb enabled ont he controller, so far no more reboots when the influxdb server is not running.
I'll continue running like this for another 12 hours to check iddue #48 and or # 59 have resolved with these fixes too.
Great work Stuart! Thanks

[voort4444]

Working great @stuartpittaway I have had no more reboots, think its safe to say all is resolved.
Thanks again, keep up the nice work!