"Task watchdog" Reboot loop at startup with 0.8.140 and 0.8.141 / INT Pin status "unknown" for nRF24L01? #1733
Comments
|
NTP, which server or ip is inserted? Your local Router? |
|
didnt change the default "pool.ntp.org" setting. |
|
give a try, insert ip from local router if the device will deploy time services. Better also if ISP is down. |
Did so, using IP address of my WiFi router. Works perfectly well with Web landing page keeps switching between and in irregular intervals (some seconds). Also uptime counter not working, even saw it count backwards once.. After some minutes, I've downgraded to yours, |
|
Save your Settings and then remove inverter #1 completely and try again with 0.8.141. |
Ok, will give it a try when i'm home, however everything works fine with P.s.: will fire up inverter #1 and enable it first, then upgrade to |
|
Update: Starting after enabling Inverter #1 and rebooting with After upgrading to then after a few seconds, system time is lost again, which also breaks inverter communication: What i found interesting: in the error case, the Uptime counter never got higher than 10 seconds. After reaching 9-10 seconds, system time was lost and the uptime counter reset to a lower value of 4-5 seconds. As i need both inverters to be working, i decided not to delete inverter #1 (if there's a plausible reason/suspicion to try to delete inv#1 please explain). I'm currently fine with the old version, if there's anything else i can do to help track down the problem let me know. For the sake of completeness, i am using this ESP32-S3 board: NOTE: "System" page of Ahoy-DTU at version yours, |
|
hi, look under "System" to the reason of restarting your DTU. to me it looks like a reboot-loop whatever |
|
Sounds plausible to me, will check this out. |
|
You were perfectly right! "System" reports this: I would assume the "unknown" status of the INT pin to be the reason for the problems, but as i'm writing this comment, the status suddenly changed: As you can see in the new screenshot, ESP seems to have stopped rebooting, everything seems to work fine now. This is the pinout which i've configured for the NRF: When i manually issue a reboot on the ESP, the reboot loop once again starts and calms down after some time. I will stay on I have also attached a coredump file which was taken while the "reboot loops" were in progress, maybe it helps. |
juepi
changed the title
|
Updated issue title according to the new findings. |
|
can you try to download a coredump from system page? It would be really helpful to better understand what happens. It would be helpful if you can do that with .140 version, but once the last crash was with .140 you also can read it using .130 version. |
lumapu
added
bug
Hi Lukas, Let me know if you still need the requested coredump from yours, |
|
A small update from my side: i just had to reboot my AhoyDTU after a configuration change, it cam up instantly without the reboot-loop and Int-Pin working set to "true". I have made the following changes due to Inverter1 being replaced from a HM-800 to HM-400:
EDIT: after another change (deleted Inverter1, reboot) the problem occured again, created another coredump: So it seems that the reboot-loop does not occur on every reboot. Also, every reboot-loop occurence seems to end after a while (minutes) and after that, AhoyDTU is running perfectly well. yours, |
|
Hey Juergen, I translated your Coredumps: 2024-08-23_11-17-09_v0.8.141_opendtufusion_coredump.bin2024-08-29_10-24-02_v0.8.141_opendtufusion_coredump.binBoth show the same behavior, the 🐶 is not fed. But I still don't know where it needs to be fed more. What is about display, is it configured? Does your ESP crash by itself or only if the WebUI is open? |
|
Hi Lukas,
Yes, MQTT is used, but at the stage where the coredumps have been downloaded, it did not yet work.
No display connected, only the NRF radio.
Uh, hard to tell. What i can tell for sure is that it only happens on startup/reboot. As soon as it switches into a "stable mode", it seems to run perfectly well (at least for a week as far as i can tell by now). yours, P.s.: coredump added in working state - maybe it helps? |
|
One more thing concerning your question about accessing the WebUI: if you're thinking of the new AsyncWebserver of yours, |
|
lt. deinem Screenshot hat du ein sehr hohen MqTT-Verkehr: fast 3000 Tx in 4 min! Ist das normal, oder kann sich da die DTU verschlucken? |
Also es ist etwas über meinem Durchschnitt, über die letzten 24h komme ich auf etwa 400TX/min, wobei in der Nacht die Inverter deaktiviert waren, so gesehen wäre das mit ca. 600 TX/min schon plausibel. habe ein MQTT- und Inverter-Intervall von 5 Sekunden konfiguriert, das entspricht dem Datenintervall meines SmartMeters. Nulleinspeiseregelung läuft über FHEM (Perl-script) und wird per MQTT an AhoyDTU geliefert (limits), was in diesem Setup sehr gut funktioniert. Wie gesagt: sobald das Werkl mal läuft nach der "startup reboot loop" läuft das sehr stabil. Ging sogar mit ESP8266, dort am Ende allerdings mit Stabilitätsproblemen, deswegen der Wechsel auf ESP32-S3. lg, |
|
leider zeigt auch der dritte Coredump das gleiche Bild. Kannst du mal testweise das MqTT intervall auf 0 setzen, d.h. nicht, dass keine Daten geliefert werden, sondern immer dann wenn neue zur Verfügung stehen. |
|
Wollte ich gerade umstellen - steht schon auf 0! Shame on me, sorry für die Fehlinformation! |
|
Morgen, Habe gerade ein interessantes Verhalten festgestellt: nach dem reboot (inkl. MQTT broker) meines Servers (WiFI inkl. NTP und Namensauflösung blieb online) tritt das gleiche Verhalten auf! AohyDTU geht in die reboot-schleife und "erholt" sich wieder nach einiger Zeit.. Hier nochmal ein Dump: Dieser entstand nach einer "MQTT broker offline reboot schleife" (zu dem Zeitpunkt war der Broker aber schon wieder online und AhoyDTU hat sich erholt). Eventuell ein buffer-overflow nach dem boot, weil MQTT messages zum senden anstehen aber der broker noch nicht connected hat? lg, |
|
sieht sehr danach aus woran wir alle gerade knappern scheint dasselbe Problem zu sein.... |
|
Aha, spannend finde ich dass das bei mir offenbar nur beim booten zum Problem wird. Wie gesagt, einmal im Betrieb läuft das wie ein Glöckerl.
lg, |
|
also bei mir ist nach spätestens 24h Schluss, dann restartet sich die DTU mit Task Watchdog. Leider verabschiedet sich auch mein ESP8266 mit -min-Konfig immer wieder mit "Exception" |
nein, die lg, |
juepi
changed the title
|
Also gemittelt über die letzten 3 tage habe ich ca. 560 MqTT TX pro Minute. Keine resets von AhoyDTU in dieser Zeit. lg, |
|
Update meinerseits: habe gerade auf die Update: I've just upgraded to lg, P.S.: |
Platform
ESP32
Assembly
I did the assembly by myself
nRF24L01+ Module
nRF24L01+ plus
Antenna
circuit board
Power Stabilization
Elko (~100uF)
Connection picture
Version
0.8.140
Github Hash
f1f4481
Build & Flash Method
AhoyDTU Webinstaller
Setup
MQTT configured, Inverter interval 5 seconds, 2 inverters configured, one activated
Debug Serial Log output
No response
Error description
Really not sure if this is a problem with my infrastructure, but reporting it anyways in case it sounds familiar to someone:
Hardware: ESP32-S3, using image
*_opendtufusion.binwas running fine on
0.8.130for several weeks. Decided to go for a update to the new release0.8.140, however directly after the upgrade (AhoyDTU /update page) i've experienced the following issues:I would assume the corrupted system time to be the root cause for all other problems.
I've also tried the current dev build
0.8.141, same issue. I've downgraded my ESP to the0.8.130devbuild again, seems to work fine now.yours,
Juergen
The text was updated successfully, but these errors were encountered: