Node MCU und WeMos D1 immer wdt reset

OP #4739661
Lesenswert?

Hallo zusammen,

ich bin ein wenig verzweifelt bei meinen 2 boards. Dem NodeMCU und den 
WemosD1. Nach nur wenigen Codezeilen erhalte ich immer den wdt reset. 
Dabei kann ich den Code so minimalistisch halten wie möglich. Auch 
andere Beiträge im Netz mit Watchdog füttern oder wdt disable helfen 
nichts. Bekommt jemand eines der beiden Boards problemlos zum laufen?
Hier mein Code:
1
// the setup routine runs once when you press reset:
2
void setup() {
3
  // initialize serial communication at 9600 bits per second:
4
  Serial.begin(115200);
5
  ESP.wdtDisable();
6
  ESP.wdtEnable(WDTO_8S);
7
}
8

9
// the loop routine runs over and over again forever:
10
void loop() {
11

12
  Serial.println("Hello");
13
  delay(500);        // delay in between reads for stability
14
  ESP.wdtFeed();
15
}

Die Ausgabe ist IMMER gleich:
1
Hello
2
Hello
3

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

6
wdt reset
7
load 0x4010f000, len 1384, room 16 
8
tail 8
9
chksum 0x2d
10
csum 0x2d
11
v09f0c112
12
~ld
13

14
Hello
15
Hello
16
Hello
17
Hello
18

19
 ets Jan  8 2013,rst cause:4, boot mode:(3,6)
20

21
wdt reset
22
load 0x4010f000, len 1384, room 16 
23
tail 8
24
chksum 0x2d
25
csum 0x2d
26
v09f0c112
27
~ld
28

29
Hello
30
Hello
31
Hello
32
Hello
33

34
usw.
die ESP Funktionen habe ich auch schonmal auskommentiert, aber das 
Resultat war dasselbe. Die Augabe beim D1 unterscheidet sich nur darin 
das Bootmode 3,7 drinsteht.


Habe lediglich das USB Kabel angeschlossen sonst nichts. Auch keine 
extra Spannungsversorgung.
Benutze die Arduino IDE 1.6.7
Die esp8266 board lib ist die 2.3.0
Als Board habe NodeMCU0.9 und 1.0 bereits probiert (kein Unterschied 
gemerkt)

Ich hoffe jemand kann mir helfen. Mit dem PretzelBoard hat bislang immer 
alles geklappt, aber das ist zu teuer wenn man mehrere braucht.

mfg

apo
#4739701
Lesenswert?

Hallo,

laß den ESP-Watchdog in Ruhe, der führt auf dem ESP ein ziemliches 
Eigenleben. Abschalten geht ohnehin nicht, es gibt einen 
Hardware-Watchdog, der nach rund 6s zuschlägt, wenn den ESP was nicht 
gefällt.

Ich kann den Effekt hier auf einem NodeMCU nicht nachvollziehen, auch 
mit
1
// the setup routine runs once when you press reset:
2
void setup() {
3
  // initialize serial communication at 9600 bits per second:
4
  Serial.begin(115200);
5
}
6

7
// the loop routine runs over and over again forever:
8
void loop() {
9

10
  Serial.println("Hello");
11
  delay(500);        // delay in between reads for stability
12
}
läuft es stabil durch.

Hast Du irgendwas am NodeMCU angeschlossen außer USB?
Boardtyp bzw. Flashgröße richtig angegeben?

Nimm mal
#include <ESP8266WiFi.h>

in Deinen Sketch mit rein, auch wenn Du noch nichts mit dem WLAN machst.
Ich hatte da mal so einen komischen Effekt.

Gruß aus Berlin
Michael
OP #4739850
Lesenswert?

Hi,

und danke für die Tipps. Den header hatte ich auch schonmal mit 
eingebaut...selber Effekt. Den Node habe ich zufällig gerade durch 
Ändern der esp boardversion von 2.3.0 auf 2.0.0 zum laufen gebracht. 
Bislang funktioniert es. Vielleicht läufst du auch auf der 2.0.0 und 
kannst es deshalb nicht nachstellen. Ich hoffe es lag nur an der 
fehlerhaften lib... Ich teste jetzt mal den D1
Gast #4846028
Lesenswert?

Fetter Elko zwischen VCC und GND hilft bei mir (nodeMCU und nakte 
ESP-0x) erstmalig, 10µF wird oft als ausreichend angesehen, war zwar 
besser aber immer noch sporadische Resets. Vermutlich reichen 100µF, ich 
habe gleich einen 330mF angeklemmt und seitdem ist Ruhe. Vorher ständig 
sporadische Resets (alle paar Stunden wenn er eigentlich nix zu tun 
hatte), lief heute mal einen Tag komplett durch und semmelt auch nicht 
mehr bei Last weg.

Alles andere war bisher Voodo (pullup an RST (bei ESP01 vielleicht 
sinnvoll), wdt-gefummel, andere Kabel/port, 
reflashen/flash_erase,C/arduino anstatt lua/javascript,... ALLES 
BULLSHIT)
Sorg für ordentliche Stromversorgung auch wenn das Ding scheinbar nur 
rumidled, der scheint immer wieder mal Bursts zu haben wo er kurzfrisitg 
viel Saft zieht.
Gast #4856355
Lesenswert?

Jetzt habe ich auch wieder das Problem mit den Resets und habe die 
Ursache gefunden:
Sobald ich das Ding auf ein Breadboard stecke fängt es öfters an zu 
reseten.
Reibt man das Breadboard (unten Plastikklebeband, nicht das mit Metall) 
über den Tisch (kunststoffbeschichtet), resetet es sofort!
Gast #5297138
Lesenswert?

Ich habe die gleiche Erfahrung gemacht.
Wenn das Nodemcu auf eine Breadboard steckt fängt der leidige WDT Reset 
an
und spricht ständig an. Meine Vermutung: Die Kontaktbahnen im Breadboard 
wirken wie Antennen und fangen Störung auf die zu dem WDT Reset führen.
Gast #5297144
Lesenswert?

Stefan schrieb:
> Ich habe die gleiche Erfahrung gemacht.
> Wenn das Nodemcu auf eine Breadboard steckt fängt der leidige WDT Reset
> an
> und spricht ständig an. Meine Vermutung: Die Kontaktbahnen im Breadboard
> wirken wie Antennen und fangen Störung auf die zu dem WDT Reset führen.

Ohne Breadboard gibt es keine Problem und das Nodemcu arbeite sehr 
stabil.
Gast #5297211
Lesenswert?

Erstmal zum Watchdog:

Es ist wichtig, das die Firmware genügend Rechenzeit ab bekommt, sonst 
fällt das Modul aus. Alle eigenen Programmteile müssen spätestens nach 
50ms (empfohlen werden 20ms) die Kontrolle an die Firmware abgeben, 
indem entweder die loop() Funktion verlassen wird, oder delay(ms) oder 
yield() aufgerufen wird. Man soll den Watchdog im eigenen Code ganz in 
Ruhe lassen.

Zur Stromversorgung:
Direkt an VCC und GND sollte man einen Kondensator mit 100µF (manche 
nehmen auch mehr) löten. Auf dem NodeMCU Board ist er bereits vorhanden. 
Steckbretter und USB Kabel haben häufig zu hohe Übergangswiderstände, 
deswegen besser ein Netzteil direkt ans Modul löten.

Ich benutze die ESP Erweiterung Version 2.3.0 mit Arduino 1.8.2 und das 
läuft bei mir absolut stabil.

Weitere Tipps bezüglich Stabilität:
http://stefanfrings.de/esp8266/index.html#stability
http://stefanfrings.de/esp8266/index.html#fallstricke
Gast #5299672
Lesenswert?

Stefan schrieb:
> Wahrscheinlich sind es die Kontaktbahnen (Metall) des Breadboards für
> die Störungen verantwortlich sind.
> Wie gesagt Nodemcu vom Breadboard runter und die WDT Resets sind weg.

Ist für mich nicht schlüssig: Breadboard ist Hardware und Watchdog ist 
Software. Du hast dein Problem nicht gelöst, es wird dich wieder 
einholen, wenn du es am wenigsten brauchen kannst.

MfG Klaus
Gast #5299683
Lesenswert?

> Breadboard ist Hardware und Watchdog ist
> Software. Du hast dein Problem nicht gelöst

Schlechte Stromversorgung löst Fehlfunktionen aus. Einen Softwarefehler 
hatten wir bereits ausgeschlossen. Der Hardwarefehler wurde durch 
Versuch bestätigt.
Gast #5302039
Lesenswert?

Der Fehler zeigt sich doch recht eindeutig.
Nodemcu über Usb Kabel am Rechner angeschlossen als Stromversorgung.
Ist das Nodemcu auf dem Breadboard alle paar Sekunden der WDT Reset.
Runter vom Breadboard, läuft das Ding Stundenlang ohne Fehler.
Gast #5309282
Lesenswert?

Hab das nochmal untersucht.
Ich glaube das die IO's (CLK, SD1, SD2 usw) für den Flashspeicher die 
WDT's auslösen.
Hier wird was Falsches eingelesen weil Störungen durch die Kontaktbahnen 
des Breadboards (Induktic, Kapazitiv) eingefangen werden. Die Frequenz 
des CLK liegt hier bei 40 Mhz.
Gast #5309303
Lesenswert?

Das klingt plausibel. Knipse die Pins einfach ab, die kannst du ohnehin 
nicht benutzen.

Und sage dann bitte Bescheid ob es geholfen hat. Das wäre nämlich ein 
interessanter Punkt für meine Homepage.
Gast #5309600
Lesenswert?

Stefan U. schrieb:
> Schlechte Stromversorgung löst Fehlfunktionen aus

Stefan schrieb:
> Ich glaube das die IO's (CLK, SD1, SD2 usw) für den Flashspeicher die
> WDT's auslösen.
> Hier wird was Falsches eingelesen weil Störungen durch die Kontaktbahnen
> des Breadboards (Induktic, Kapazitiv) eingefangen werden. Die Frequenz
> des CLK liegt hier bei 40 Mhz.

Eine schlechte Stromversorgung wars also nicht, obwohl das immer als 
erstes behauptet wird. Mein vermuteter Softwarefehler aber auch nicht.

MfG Klaus
Gast #5309624
Lesenswert?

Hallo zusammen,
das Nodemcu lief jetzt über Nacht ohne einen einzigen WDT.
Damit kann man zu 100% sagen das das Problem an den Störungen auf die 
PIN's lag.
Wieder ein Erkenntnis mehr. Wenn man bedenkt wie oft das Thema in Foren 
angesprochen wurde.
Gast #6120201
Lesenswert?

Danke für den goldenen Tipp von Stefan. Die Rechenzeit für die Firmware 
war bei mir tatsächlich das Problem!

Konkret habe ich die Stepper Lib genutzt und wollte einfach ein paar 
Umdrehungen machen und das dauert, da die lib blockiert, zu lange. 
Schwubs hat der Watchdog zugebissen!

Einfach die Drehung aufgeteilt und dazwischen ein Delay, jetzt klappt 
es!

Danke!

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren