ahoy icon indicating copy to clipboard operation
ahoy copied to clipboard

Published 20 hours ago • verified publisher icon lumapu

ESP32 resets several times a day[Bug]

Open mellow5 opened this issue 1 year ago • 40 comments
trafficstars

Platform

ESP32

Assembly

I did the assebly by myself

nRF24L01+ Module

nRF24L01+ plus

Antenna

circuit board

Power Stabilization

Elko (~100uF)

Connection picture

  • [ ] I will attach/upload an Image of my wiring

Version

0.8.52

Github Hash

455d29a

Build & Flash Method

AhoyDTU Webinstaller

Setup

Nothing was changed on the setup since 0.7.36.

Debug Serial Log output

No response

Error description

Since stable release 0.7.36 I never had a setup that did not reset several times per day. What are the most common problems for resetting? Else I'm very satisfied with the project.

How best to debug the reset?

mellow5 avatar Jan 12 '24 14:01 mellow5

How best to debug the reset?

If you could provide a serial log of the last messages, this could be helpful. Either by the Webserial or via USB serial (e.g. with putty).

You69Man avatar Jan 12 '24 17:01 You69Man

for some it helped to configure the ESP from scratch - don't forget to export your configuration first!

lumapu avatar Jan 12 '24 20:01 lumapu

Last lines from serial log before reboot tonight.

I: (#0) no communication to the inverter (night time)
I: (#1) no communication to the inverter (night time)

assert failed: tcp_update_rcv_ann_wnd IDF/components/lwip/lwip/src/core/tcp.c:951 (new_rcv_ann_wnd <= 0xffff)


Backtrace: 0x40083c71:0x3ffb2cc0 0x4008c94d:0x3ffb2ce0 0x40092c05:0x3ffb2d00 0x401262fa:0x3ffb2e30 0x401263a8:0x3ffb2e50 0x400f1cbe:0x3ffb2e70 0x40123090:0x3ffb2e90

If this does not give you any ideas, I will install from scratch.

mellow5 avatar Jan 13 '24 07:01 mellow5

Hier gab es auch einen issue zu diesem Fehler: https://github.com/espressif/arduino-esp32/issues/7895

You69Man avatar Jan 13 '24 09:01 You69Man

i (also) have constant async watchdog reboots using 0.8.53 see usb serial log below

maybe an important note: never reboots in ap mode, always reboots in wifi mode

what i've tried:

erasing and reflashing the esp32 with both web flasher and espressive flash_download_tool_3.9.5.exe, erase & flashing bootloader, partitions, ota and firmware to their specific locations (0x1000, 0x8000, 0e000,0x10000) result: still rebooting in wifi mode

then i disabled and removed the display set ntp to local fritzbox ip result: still rebooting in wifi mode

crosschecks to exclude esp32 hardware problems:

erased the esp32 and flashed another project using web and nrf24 result: works without issues

erased the esp32 and flashed ahoy dtu 0.6.9 result: works without issues

usb serial log from 0.8.53 reboots (short snippet of the repeating endless loop):

--------------------------------
Welcome to AHOY!

point your browser to http://************ (Station)
to configure your device
--------------------------------

Wifi event: 11
Wifi event: 10
[WiFi] AP disabled
Wifi event: 11
[WiFi] mDNS established: AHOY-DTU-32-EP.local
E (34596) task_wdt: Task watchdog got triggered. The following tasks did not reset the watchdog in time:
E (34596) task_wdt:  - async_tcp (CPU 1)
E (34596) task_wdt: Tasks currently running:
E (34596) task_wdt: CPU 0: IDLE
E (34596) task_wdt: CPU 1: IDLE
E (34596) task_wdt: Aborting.

abort() was called at PC 0x40115b3c on core 0


Backtrace: 0x40083c71:0x3ffbeccc |<-CORRUPTED




ELF file SHA256: d6fdd9617fa6c971

Rebooting...
ets Jul 29 2019 12:21:46

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:DIO, clock div:2
load:0x3fff0030,len:1184
load:0x40078000,len:13232
load:0x40080400,len:3028
entry 0x400805e4
I: Initializing FS ..
I:  .. done
I: Config Version: 0
I: Settings valid: true

---------
AhoyDTU Info:
Version: 0.8.53
Github Hash: ca6ebfe

---------
AP MODE
SSID: AHOY-DTU
PWD: esp_8266
IP Address: http://192.168.4.1
---------

Wifi event: 0
Wifi event: 2
Wifi event: 10
Wifi event: 11
Wifi event: 10
connect to network '************' ...
I: added inverter HM************
I: added inverter HM************
I: added inverter HM************
I: added inverter HM************
I: added inverter HM************
scanning APs with SSID ************
Wifi event: 1
BSSID 0: 3c a6 2f 8 7e 50
try to connect to AP with BSSID: 3c a6 2f 8 7e 50
Wifi event: 5
I: connectionEvent
Wifi event: 4
I: connectionEvent

[WiFi] Connected
Wifi event: 7
I: connectionEvent


--------------------------------
Welcome to AHOY!

point your browser to http://************ (Station)
to configure your device
--------------------------------

Wifi event: 11
Wifi event: 10
[WiFi] AP disabled
E (33085) task_wdt: Task watchdog got triggered. The following tasks did not reset the watchdog in time:
E (33085) task_wdt:  - async_tcp (CPU 1)
E (33085) task_wdt: Tasks currently running:
E (33085) task_wdt: CPU 0: IDLE
E (33085) task_wdt: CPU 1: IDLE
E (33085) task_wdt: Aborting.

abort() was called at PC 0x40115b3c on core 0


Backtrace: 0x40083c71:0x3ffbeccc |<-CORRUPTED




ELF file SHA256: d6fdd9617fa6c971

Rebooting...
ets Jul 29 2019 12:21:46

MetaChuh avatar Jan 13 '24 10:01 MetaChuh

I have been running version 0.8.53 on an ESP32 (including display and graph) for more than a day without any problems.

However I have managed to capture an unexcpected reboot now on an ESP8266 (same software version, also with display and display graph)!

This is the decoded exception output (callstack): grafik

It seems these async reboots always point to something within the TCP/IP stack, but I don't understand the details. The failure seems to be extremely sensitiv to tiny deviations in timing! That means that any change in configuration (also like display on/off settings) can make a difference.

I've built a slightly different version of the failed 0.8.53 on ESP8266 (just added some DBGPRINTLN lines to find possible reasons), but now the reboot doesn't show up again till now.

@lumapu: Do you think this could be due to too few yield() calls in the loops?

You69Man avatar Jan 14 '24 09:01 You69Man

no yield() is positive. I think the issue occurs on ESP8266 first because of its single core. An exception around TCP could be related to WiFi. Maybe we have to check our loops again. Do you know anything regarding heap fragmentation on ESP8266?

lumapu avatar Jan 14 '24 10:01 lumapu

0.8.53 derivate on ESP8266 (deviation: just some added DBGPRINTLN, running stable since several hours): heap frag: 3 heap free: 12280

If I ever come across a version with reboots, I will check heap and heap frag again!

You69Man avatar Jan 14 '24 10:01 You69Man

no yield() is positive

Yes, what I meant is, should we add some more yield(), e.g. between and inside the radio-, communication- or display loops? I don't have much experiance how many (or how often) yield() calls are necessary to fulfill the background tasks of the ESP.

You69Man avatar Jan 14 '24 11:01 You69Man

Ich habe 0.8.56 installiert und bekomme leider weiterhin die sporadischen reboots mit der gleichen Fehlermeldung.

mellow5 avatar Jan 15 '24 11:01 mellow5

@lumapu hi, ich hab' vor ca 4h testweise die 0.8.57 auf den gleichen test esp32 wie oben geflasht (esp32 d1 mini mit e-paper) update via ota von 0.6.9 auf 0.8.57 und augen zu

bisher kein reboot, gleiches wlan 👍

mal schauen, was passiert, sobald die ersten solar inverter offline gehen. ich polle jetzt mal zum testen alle inverter per api im 2 sekunden intervall sequenziell und geb' per edit bescheid, falls sich was ändert.

@You69Man danke für die saugeile mini graph für die oled displays 🙏 hab's heute auf einer anderen esp32 mit sh1106 kurz ausprobiert 👍 wirklich zu schön um wahr zu sein 😉

thx & greetings

MetaChuh avatar Jan 16 '24 13:01 MetaChuh

sehr schön hier positives zu lesen ☺️, ich hoffe der Sonnenuntergang hat die Stimmung nicht getrübt

lumapu avatar Jan 16 '24 20:01 lumapu

hi, nein gottseidank nichts getrübt durch den sonnenuntergang, erst nach zufälligem internetausfall in der nacht:

nach sonnenuntergang war alles noch ok und noch 2 batterie inverter online. uptime 12h+ trotz stakkato rekursiv api abfrage

nachts um ca 02:00h ist dann die dsl wan verbindung länger ausgefallen (lokales wifi, lan und geräte alle vorhanden, pool.ntp.org und alles externe nicht erreichbar) kurz darauf begannen alle ahoy dtus zu rebooten (bootloop auch bei v0.6.9)

kurz nachdem die dsl leitung wieder funktionierte, hörten die reboots auf.

hab' dann in allen ahoy dtus den ntp server zum testen auf eine lokale synology nas ip gesetzt, statt pool.ntp.org oder lokale fritzbox ip.

wichtig zum thema fritzbox als lokaler ntp: habe heute getestet, wenn der in der fritzbox eingetragene ntp server nicht erreichbar ist, stellt die fritzbox KEINE eigene uhrzeit bereit, und geht in timeout, als ob man direkt pool.ntp.org angegeben hätte. reines sntp passthrough, also ist diese avm funktion nutzlos, und nicht als lokaler failsafe ntp zu gebrauchen.

werd' weiter (sporadisch wegen zeitmangel) testen, um mehr zu finden, womit wir mehr reboots explizit, mit wissentlichem zusammenhang, reproduzieren können.

thx & greetings

MetaChuh avatar Jan 17 '24 09:01 MetaChuh

hi,

heute habe ich ota auf 0.8.58 upgedated und bumm, wieder sofort boot loops.

reboots passieren wieder nur im wifi mode. wenn ich mich mit dem ahoydtu access point verbinde, passiert kein dauerreboot und alle 5 inverter sind datenmäßig normal da.

aber sobald ich mich dann vom ap trenne und die ahoydtu sich wieder mit dem lokalen wifi verbindet, sofort wieder bootloops.

welche ntp server (lokal/remote) und einstellungen man macht war dabei egal und brachte keine verbesserung.

zusätzlich time calibration message flut in allen invertern währenddessen.

habe dann alle api html abfragen auf diese dtu abgedreht und nach ein paar minuten hat sie den bootloop dann beendet und läuft seitdem auch mit wieder aktivierter api abfrage, auch im 2sek abfrageintervall.

sehr seltsam, und ausser trial and error auszubrobieren, hab' ich keine ideen mehr.

console log auszug:


Rebooting...
ets Jul 29 2019 12:21:46

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:DIO, clock div:2
load:0x3fff0030,len:1184
load:0x40078000,len:13192
load:0x40080400,len:3028
entry 0x400805e4
I: Initializing FS ..
I:  .. done
I: Config Version: 8
I: Settings valid: true
I: Radio Config:
SPI Frequency		= 1 Mhz
Channel			= 3 (~ 2403 MHz)
Model			= nRF24L01+
RF Data Rate		= 250 KBPS
RF Power Amplifier	= PA_LOW
RF Low Noise Amplifier	= Enabled
CRC Length		= 16 bits
Address Length		= 5 bytes
Static Payload Length	= 32 bytes
Auto Retry Delay	= 1000 microseconds
Auto Retry Attempts	= 15 maximum
Packets lost on
    current channel	= 0
Retry attempts made for
    last transmission	= 0
Multicast		= Allowed
Custom ACK Payload	= Disabled
Dynamic Payloads	= Enabled
Auto Acknowledgment	= Enabled
Primary Mode		= RX
TX address		= 0xe7e7e7e7e7
pipe 0 (closed) bound	= 0xe7e7e7e7e7
pipe 1 ( open ) bound	= 0x6d57838701
pipe 2 (closed) bound	= 0xc3
pipe 3 (closed) bound	= 0xc4
pipe 4 (closed) bound	= 0xc5
pipe 5 (closed) bound	= 0xc6
I: DTU_SN: 8783576d

---------
AhoyDTU Info:
Version: 0.8.58
Github Hash: c3a2ad0

---------
AP MODE
SSID: AHOY-DTU
PWD: esp_8266
IP Address: http://192.168.4.1
---------

Wifi event: 0
Wifi event: 2
Wifi event: 10
Wifi event: 11
Wifi event: 10
connect to network '************' ...
I: added inverter HM************
I: added inverter HM************
I: added inverter HM************
I: added inverter HM************
I: added inverter HM************
scanning APs with SSID MetaWeb1230-7530
_PowerOn : 94004
_Update_Full : 4587000
_PowerOff : 139000
_PowerOn : 94004
Wifi event: 1
_Update_Full : 4407000
_PowerOff : 139000
BSSID 0: 3c a6 2f 8 7e 50
_PowerOn : 94000
_Update_Part : 732000
_Update_Part : 733000
try to connect to AP with BSSID: 3c a6 2f 8 7e 50
Wifi event: 5
I: connectionEvent
Wifi event: 4
I: connectionEvent

[WiFi] Connected
Wifi event: 7
I: connectionEvent


--------------------------------
Welcome to AHOY!

point your browser to http://10.10.10.41 (Station)
to configure your device
--------------------------------

Wifi event: 11
Wifi event: 10
Wifi event: 11
[WiFi] AP disabled
[WiFi] mDNS established: AHOY-DTU-32.local
_Update_Part : 732000
_Update_Part : 733000
_PowerOff : 139000
E (31254) task_wdt: Task watchdog got triggered. The following tasks did not reset the watchdog in time:
E (31254) task_wdt:  - async_tcp (CPU 1)
E (31254) task_wdt: Tasks currently running:
E (31254) task_wdt: CPU 0: IDLE
E (31254) task_wdt: CPU 1: IDLE
E (31254) task_wdt: Aborting.

abort() was called at PC 0x40115cb4 on core 0


Backtrace: 0x40083c71:0x3ffbeccc |<-CORRUPTED




ELF file SHA256: 2e5e26924045a82f

Rebooting...
ets Jul 29 2019 12:21:46

MetaChuh avatar Jan 18 '24 12:01 MetaChuh

@tictrick hat hier gestern versucht nachzubessern. Evtl. kann er was dazu sagen, da er gerade tief in dem Thema drin ist. Hoffentlich liegt es nicht an meiner reduzierten Anzahl von wdt-resets.

lumapu avatar Jan 18 '24 20:01 lumapu

@lumapu danke dir, hab's beobachtet wegen den 7 reset points, erkenne jedoch noch keinen direkten zusammenhang, das dies auslösen kann.

ps: ist nicht wichtig, weil die produktive umgebung hier durch tests nicht verändert wird. reines interesse neues ohne konsequenzen und dadurch mit fun auszutesten.

glg, metachuh

MetaChuh avatar Jan 18 '24 22:01 MetaChuh

@mellow5 hat bei dir eine neuere Version Verbesserung gezeigt?

lumapu avatar Jan 20 '24 14:01 lumapu

@mellow5 hat bei dir eine neuere Version Verbesserung gezeigt?

Nein, ich habe noch immer sporadische resets auch mit der 0.8.59.

mellow5 avatar Jan 20 '24 14:01 mellow5

Habe jetzt auf 0.8.60 hochgezogen.

mellow5 avatar Jan 20 '24 14:01 mellow5

gibt es ein Update?

lumapu avatar Jan 24 '24 22:01 lumapu

Bis auf die 63 hab ich alle Versionen probiert,ohne Veränderung. Weiterhin sporadische Reeboots. 5-7 pro Tag ungleichmäßig verteilt, auch nachts.

mellow5 avatar Jan 24 '24 23:01 mellow5

Ich habe heute mal probeweise einen ESP8266 verwendet. Bekomme noch immer reboots allerdings sieht der log beim reboot etwas anders aus. V0.8.65

I: (#0) Radio infos: -6 -6 -6 -6 4 | t: 2886, s: 2813, f: 5, n: 68 | p: 2
I: last tx setup: 16ms
I: (#0) TX 27 CH75 | 15 15 80
I: (#0) RX  17ms | 17 CH23 | 95 81
I: (#0) I: (#0) Payload (4)
I: (#0) Inv loss: 0 of 13, DTU loss: 2 of 43. ACKs: 13
-----
I: (#1) Radio infos: 4 -6 -6 -6 -6 | t: 2872, s: 2787, f: 7, n: 78 | p: 2
I: last tx setup: 4ms
I: (#1) TX 27 CH3 | 15 0B 80
I: (#1) RX  18ms | 27 CH40 | 95 01
I: (#1) RX  72ms | 27 CH40 | 95 02
W: (#1) frame 3 missing: request retransmit (3 attempts left)
I: (#1) TX 11 CH3 | 15 F9 83
I: (#1) RX  32ms | 23 CH40 | 95 83
I: (#1) I: (#1) Payload (42)
-----
I: com loop duration: 758ms
-----
I: (#0) Radio infos: -6 -6 -6 -6 4 | t: 2887, s: 2814, f: 5, n: 68 | p: 2
I: last tx setup: 21ms
I: (#0) TX 27 CH75 | 15 0B 80
I: (#0) RX  26ms | 27 CH23 | 95 01
I: (#0) RX  77ms | 27 CH23 | 95 02
I: (#0) RX 130ms | 27 CH23 | 95 03
I: (#0) RX 184ms | 27 CH23 | 95 84
I: (#0) I: (#0) Payload (62)
-----
I: (#1) Radio infos: 4 -6 -6 -6 -6 | t: 2873, s: 2788, f: 7, n: 78 | p: 2
I: last tx setup: 18ms
I: (#1) TX 27 CH3 | 15 0B 80
I: (#1) RX  39ms | 27 CH40 | 95 01
I: (#1) RX  72ms | 27 CH40 | 95 02
I: (#1) RX 118ms | 23 CH40 | 95 83
I: (#1) I: (#1) Payload (42)
-----
I: (#1) Radio infos: 4 -6 -6 -6 -6 | t: 2874, s: 2789, f: 7, n: 78 | p: 2
I: last tx setup: 37ms
I: (#1) TX 27 CH3 | 15 15 80
I: (#1) RX  22ms | 17 CH40 | 95 81
I: (#1) I: (#1) Payload (4)
I: (#1) Inv loss: 0 of 12, DTU loss: 1 of 32. ACKs: 10
-----
I: com loop duration: 503ms
-----
I: (#0) Radio infos: -6 -6 -6 -6 4 | t: 2888, s: 2815, f: 5, n: 68 | p: 2
I: last tx setup: 9ms
I: (#0) TX 27 CH75 | 15 0B 80
I: (#0) RX  32ms | 27 CH23 | 95 01
I: (#0) RX  85ms | 27 CH23 | 95 02
I: (#0) RX 138ms | 27 CH23 | 95 03
I: (#0) RX 182ms | 27 CH23 | 95 84
I: (#0) I: (#0) Payload (62)
-----
I: (#1) Radio infos: 4 -6 -6 -6 -6 | t: 2875, s: 2790, f: 7, n: 78 | p: 2
I: last tx setup: 16ms
I: (#1) TX 27 CH3 | 15 0B 80
I: (#1) RX  21ms | 27 CH40 | 95 01
I: (#1) RX  74ms | 27 CH40 | 95 02
I: (#1) RX 128ms | 23 CH40 | 95 83
I: (#1) I: (#1) Payload (42)
-----
I: com loop duration: 427ms
-----
I: (#0) Radio infos: -6 -6 -6 -6 4 | t: 2889, s: 2816, f: 5, n: 68 | p: 2
I: last tx setup: 9ms
I: (#0) TX 27 CH75 | 15 0B 80
I: (#0) RX  40ms | 27 CH23 | 95 01
I: (#0) RX  94ms | 27 CH23 | 95 02
I: (#0) RX 148ms | 27 CH23 | 95 03
I: (#0) RX 216ms | 27 CH23 | 95 84
I: (#0) I: (#0) Payload (62)
-----
I: (#1) Radio infos: 4 -6 -6 -6 -6 | t: 2876, s: 2791, f: 7, n: 78 | p: 2
I: last tx setup: 25ms
I: (#1) TX 27 CH3 | 15 0B 80
I: (#1) RX  27ms | 27 CH40 | 95 01
I: (#1) RX  80ms | 27 CH40 | 95 02
I: (#1) RX 126ms | 23 CH23 | 95 83
I: (#1) I: (#1) Payload (42)
-----
I: com loop duration: 461ms
-----
I: (#0) Radio infos: -6 -6 -6 -6 4 | t: 2890, s: 2817, f: 5, n: 68 | p: 2
I: last tx setup: 14ms
I: (#0) TX 27 CH75 | 15 0B 80
I: (#0) RX  41ms | 27 CH23 | 95 01
I: (#0) RX  84ms | 27 CH23 | 95 02
I: (#0) RX 148ms | 27 CH23 | 95 03
I: (#0) RX 191ms | 27 CH23 | 95 84
I: (#0) I: (#0) Payload (62)
-----
I: (#1) Radio infos: 4 -6 -6 -6 -6 | t: 2877, s: 2792, f: 7, n: 78 | p: 2
I: last tx setup: 23ms
I: (#1) TX 27 CH3 | 15 0B 80
I: (#1) RX  39ms | 27 CH40 | 95 01
I: (#1) RX  72ms | 27 CH40 | 95 02
I: (#1) RX 125ms | 23 CH40 | 95 83
I: (#1) I: (#1) Payload (42)
-----
I: com loop duration: 434ms
-----
I: (#0) Radio infos: -6 -6 -6 -6 4 | t: 2891, s: 2818, f: 5, n: 68 | p: 2
I: last tx setup: 37ms
I: (#0) TX 27 CH75 | 15 0B 80
I: (#0) RX  26ms | 27 CH23 | 95 01
I: (#0) RX  80ms | 27 CH23 | 95 02
I: (#0) RX 133ms | 27 CH23 | 95 03
I: (#0) RX 187ms | 27 CH23 | 95 84
I: (#0) I: (#0) Payload (62)
-----
I: (#1) Radio infos: 4 -6 -6 -6 -6 | t: 2878, s: 2793, f: 7, n: 78 | p: 2
I: last tx setup: 9ms
I: (#1) TX 27 CH3 | 15 0B 80
I: (#1) RX  50ms | 27 CH40 | 95 01
I: (#1) RX 122ms | 23 CH40 | 95 83
W: (#1) frame 2 missing: request retransmit (3 attempts left)
I: (#1) TX 11 CH3 | 15 F8 82
I: (#1) RX  29ms | 27 CH40 | 95 02
I: (#1) I: (#1) Payload (42)
-----
I: com loop duration: 681ms
-----
I: (#0) Radio infos: -6 -6 -6 -6 4 | t: 2892, s: 2819, f: 5, n: 68 | p: 2
I: last tx setup: 16ms
I: (#0) TX 27 CH75 | 15 0B 80
I: (#0) RX  20ms | 27 CH23 | 95 01
I: (#0) RX  84ms | 27 CH23 | 95 02
I: (#0) RX 119ms | 27 CH23 | 95 03
I: (#0) RX 183ms | 27 CH23 | 95 84
I: (#0) I: (#0) Payload (62)
-----
I: (#1) Radio infos: 4 -6 -6 -6 -6 | t: 2879, s: 2794, f: 7, n: 78 | p: 2
I: last tx setup: 4ms
I: (#1) TX 27 CH3 | 15 0B 80
I: (#1) RX  40ms | 27 CH40 | 95 01
I: (#1) RX  93ms | 27 CH40 | 95 02
I: (#1) RX 147ms | 23 CH40 | 95 83
I: (#1) I: (#1) Payload (42)
-----
I: com loop duration: 448ms
-----
I: (#0) Radio infos: -6 -6 -6 -6 4 | t: 2893, s: 2820, f: 5, n: 68 | p: 2
I: last tx setup: 22ms
I: (#0) TX 27 CH75 | 15 0B 80
I: (#0) RX  16ms | 27 CH23 | 95 01
I: (#0) RX  69ms | 27 CH23 | 95 02
I: (#0) RX 123ms | 27 CH23 | 95 03
I: (#0) RX 166ms | 27 CH23 | 95 84
I: (#0) I: (#0) Payload (62)
-----
I: (#1) Radio infos: 4 -6 -6 -6 -6 | t: 2880, s: 2795, f: 7, n: 78 | p: 2
I: last tx setup: 2ms
I: (#1) TX 27 CH3 | 15 0B 80
I: (#1) RX  39ms | 27 CH40 | 95 01
I: (#1) RX  74ms | 27 CH40 | 95 02
I: (#1) RX 128ms | 23 CH40 | 95 83
I: (#1) I: (#1) Payload (42)
-----
I: com loop duration: 411ms
-----
I: (#0) Radio infos: -6 -6 -6 -6 4 | t: 2894, s: 2821, f: 5, n: 68 | p: 2
I: last tx setup: 37ms
I: (#0) TX 27 CH75 | 15 0B 80
I: (#0) RX  27ms | 27 CH23 | 95 01
I: (#0) RX  84ms | 27 CH23 | 95 02
I: (#0) RX 147ms | 27 CH23 | 95 03
I: (#0) RX 180ms | 27 CH23 | 95 84
I: (#0) I: (#0) Payload (62)
-----
I: (#1) Radio infos: 4 -6 -6 -6 -6 | t: 2881, s: 2796, f: 7, n: 78 | p: 2
I: last tx setup: 9ms
I: (#1) TX 27 CH3 | 15 0B 80
I: (#1) RX  22ms | 27 CH40 | 95 01
I: (#1) RX  75ms | 27 CH40 | 95 02
I: (#1) RX 129ms | 23 CH40 | 95 83
I: (#1) I: (#1) Payload (42)
-----
I: com loop duration: 427ms
-----

 ets Jan  8 2013,rst cause:4, boot mode:(3,7)

wdt reset
load 0x4010f000, len 3424, room 16 
tail 0
chksum 0x2e
load 0x3fff20b8, len 40, room 8 
tail 0
chksum 0x2b
csum 0x2b
v00098fe0
~ld
 nrn|ll`bbrlnBnl`rllI: Initializing FS ..
I:  .. done
I: Config Version: 9
I: Settings valid: true
I: Radio Config:
SPI Frequency		= 1 Mhz
Channel			= 76 (~ 2476 MHz)
Model			= nRF24L01+
RF Data Rate		= 250 KBPS
RF Power Amplifier	= PA_LOW
RF Low Noise Amplifier	= Enabled
CRC Length		= 16 bits
Address Length		= 5 bytes
Static Payload Length	= 32 bytes
Auto Retry Delay	= 1000 microseconds
Auto Retry Attempts	= 15 maximum
Packets lost on
    current channel	= 0
Retry attempts made for
    last transmission	= 3
Multicast		= Disabled
Custom ACK Payload	= Disabled
Dynamic Payloads	= Enabled
Auto Acknowledgment	= Enabled
Primary Mode		= TX
TX address		= 0x0782238401
pipe 0 ( open ) bound	= 0x0782238401
pipe 1 ( open ) bound	= 0xe55f768101
pipe 2 (closed) bound	= 0xc3
pipe 3 (closed) bound	= 0xc4
pipe 4 (closed) bound	= 0xc5
pipe 5 (closed) bound	= 0xc6
I: DTU_SN: 81765fe5

---------
AhoyDTU Info:
Version: 0.8.65
Github Hash: 97d74d3

---------
AP MODE
SSID: AHOY-DTU
PWD: esp_8266
IP Address: http://192.168.4.1
---------

mellow5 avatar Jan 25 '24 15:01 mellow5

also beide ESPs (8266 und 32). Im letzten log hat er 2880 Sendeloops gemacht und ist dann abgestürzt. Ist dort noch MqTT oder ein Display konfiguriert?

lumapu avatar Jan 25 '24 21:01 lumapu

@MetaChuh kannst du auch mal ohne Display versuchen, sieht nach ePaper aus. Und evtl. die neueste 0.8.65.

lumapu avatar Jan 25 '24 21:01 lumapu

also beide ESPs (8266 und 32). Im letzten log hat er 2880 Sendeloops gemacht und ist dann abgestürzt. Ist dort noch MqTT oder ein Display konfiguriert?

Hab jetzt Mal mqtt aus geschaltet. Display hab ich nicht

mellow5 avatar Jan 25 '24 21:01 mellow5

hi @lumapu

thx, test läuft bereits seit kurz nach deinem build (stillschweigend, statt zu früh was zu sagen, dann wieder revidierend zurück rudern, dann wieder vor und ... 😉)

ergebnisse vom dauertest (ahoy dtu 0.8.65-97d74d3) seit 2024-01-25 03:44:

test1 - dauertest mit api poll im 10s intervall:

verwendete api endpoints: api/index (ts_*, inverter, is_avail, is_producing) api/inverter/id/[0-4] api/setup (device_name)

hardware: AZ-Delivery ESP32 D1 Mini (ESP32-D0WD-V3, 2x240mhz) Generic NRF24L01+PA+LNA SMA Antenna Waveshare 1.54" E-Paper Rev 2.1 (angeschlossen und aktiviert)

settings: factory default mit e-paper display und minimalen pin anpassungen (esp32 d1 mini pin position angleichung zu esp8266 d1 mini, als drop in replacement, pin kompatibel mit der aktuellen esp8266 ahoy dtu pin belegung) kein mqtt kein cmp2300a

uptime: 1 Day, 04:42:47 (bis dahin ohne reboots)

test2 - erhöhen auf api poll 2s intervall (gleiche endpoints):

ergebnisse folgen per edit

edit:

bei 2 sekunden poll, nach wenigen minuten, bootloop wenige sekunden nach wifi connect (async, watchdog)

preset ist 8 sekunden, jedoch sobald ein bootloop losgeht, rebootet er nur 1-2 sekunden nach wifi connect

siehe: app.h #define WDT_TIMEOUT_SECONDS 8 // Watchdog Timeout 8s eingebaut seit commit Watchdog 28dbc8b von @tictrick

~~evtl mal WDT_TIMEOUT_SECONDS konfigurierbar machen oder in einer testversion auf 30 setzen ?~~ edit: schon probiert, WDT_TIMEOUT_SECONDS 30 bringt mit 0.8.65 bei mir keine verbesserung.

edit: esp_task_wdt_init(WDT_TIMEOUT_SECONDS, false); brachte auch keine verbesserung

notes:

kannst du auch mal ohne Display versuchen

mit 0.8.54 minimal ohne e-paper hatte ich ebenfalls reboots bis bootloops, jedoch nur im wifi mode, nicht im ap mode 0.6.9 lief ohne bootloops, mit seltenen reboots (alle 1-14+ tage)

thx & greetings metachuh

MetaChuh avatar Jan 26 '24 08:01 MetaChuh

Bin zurück auf ESP32 0.8.65. Seit ich mqtt ausgeschaltet habe läuft Ahoy seit nunmehr drei Tagen durch.

HM1500 HM800 kein Display call der inverter api id 0 einmal pro Sekunde call der inverter api id 1 einmal pro Sekunde call der index api einmal pro Sekunde Update aller 5 Sekunden

Ich weiß es macht keien Sinn einmal pro Sekunde die api abzufragen, aber bei alten Versionen konnte ich die daten aller Sekunde aktualisieren von Ahoy. Und ich mache Rückspeiseregelung.

Bei Rückspeiseregelung wie die letzten Tage können je Umrichter bis zu aller 2 Sekunden power limits per api geschickt werden.

Hat prima fuktioniert die letzten Tage. Für mich ist es ok, ich komme auch gut ohne MQTT aus.

mellow5 avatar Jan 29 '24 20:01 mellow5

verstehe ich es richtig, dass alle, die hier in dem Ticket schreiben API-Polls machen?

lumapu avatar Jan 29 '24 20:01 lumapu

seit @mellow5 's letzter antwort glaube ich (in diesem issue) ja. @mellow5: Bin zurück auf ESP32 0.8.65. Seit ich mqtt ausgeschaltet habe läuft Ahoy seit nunmehr drei Tagen durch ... ich komme auch gut ohne MQTT aus.

ich wie immer ausschließlich api.

ps: ich komme ebenfalls derzeit mit den alten versionen produktiv gut aus und teste die neuen sowieso nur auf einer der separaten dev dtus.

der reboot bis bootloop fehler hat sich anscheinend irgendwann, zwischen v0.7.x bis jetzt eingeschlichen, jedoch zu wenig zeit zum alle builds durchzugehen und dann, sobald ich die älteste version finde, die in dieser umgebung rebootet, dann mir die diffs anzusehen.

MetaChuh avatar Jan 29 '24 21:01 MetaChuh

der Fehler ist aber reproduzierbar, daher kann man auch einfach den aktuellen Code quälen und dabei bisschen loggen. Das sollte doch zu finden sein ...

lumapu avatar Jan 30 '24 22:01 lumapu