ESP-12S startet nicht korrekt nach deep sleep.

[Gustl B. (-gb-)]

Hallo zusammen.

Ich habe einen ESP-12S und dort den IO16 mit Reset verbunden damit der 
deep sleep funktioniert.

Der ESP geht auch wie erwartet in den Tiefschlaf, und wacht auch auf, 
schreibt mir

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

aber das Programm startet nicht.

Was ich mit dem Oszi sehen konnte ist:
- An IO15, da habe ich nur einen 4,7 kOhm Pulldown, wackelt es hin und 
her, mal 0 V, mal die VCC Spannung 3,6 V.
- An I2C habe ich Sensoren und da liegt nach dem Tiefschlaf dauerhaft 
die Clock SCL (IO0) an.

Was habe ich schon probiert?
Ich habe einen 100 nF Kondensator an Reset entfernt.
Reset hat einen 10 kOhm Pullup.
Der IO2 hat einen 10 kOhm Pullup.
Ich habe aus meinem Programm alle I2C Bestandteile entfernt (auch wire). 
Und trotzdem toggelt SCL dauerhaft nach dem Tiefschlaf.

Meine Fragen sine jetzt:
- Muss ich in meinem Programm irgendwelche Dinge beachten nach dem 
Aufwachen?
- Ich verwende Wire für I2C, kann ich das irgendwie vor dem Tiefschlaf 
deaktivieren damit da SCL dauerhaft aus bleibt?
- Ich habe am I2C einen VEML7700 und einen BME280. Die werden vor dem 
Tiefschlaf auch korrekt gefunden und liefern ordentliche Werte, alles 
wunderbar. Nach dem Tiefschlaf liegt aber SCL dauerhaft an, auch wenn 
ich wire und I2C in meinem Programm nicht verwende. Während des 
Tiefschlafs ist SCL dauerhaft low. SCL ist an IO0 und SDA an IO4. habe 
ich da einen Fehler gemacht?

Nachtrag:
Ich habe jetzt versucht vor dem Tiefschlaf beide Sensoren am I2C auch in 
den Tiefschlaf zu schicken mit:

settings.mode = BME280::Mode_Sleep;
bme.setSettings(settings);
veml.enable(0);

Hat aber nichts gebracht. Direkt nach dem Aufwachen sehe ich wieder die 
I2C Clock.

Nachtrag2:
Über einen Taster an Reset startet der ESP wunderbar neu und startet 
auch das Programm.

Edit:
Sorry, bitte in das uC Forum verschieben. Danke!

[Michael U. (amiga)]

Hallo,

ich habe meist 10k an GPIO15, der Wert ist aber relativ egal.
Warum hast Du I2C an GPIO0 und 5? GPIO0 ist kritisch, weil er 
entscheidet, wie gebootet wird, der muß beim Reset/Aufwachen sicher auf 
H liegen.
Üblich ist eher GPIO4 und 5 für I2C, die sind da unkritisch.
Ein ESP8266-12 mit BME280 und BH1750 an einer LiFePO4 Zelle hat hier 
noch nie Probleme gemacht.

Gruß aus Berlin
Michael

[Stefan F. (stefanus)]

Da gibt es eine ganze Menge zu beachten. Michael hat den Anfang gemacht, 
aber da sind noch mehr Pins, die zum Start bestimmte Pegel haben müssen.

Am besten liest du dich mal dort ein: 
http://stefanfrings.de/esp8266/index.html

Ohne Schaltplan und Quelltext können wir dir nicht konkreter helfen.

[Gustl B. (-gb-)]

Michael U. schrieb:
> Warum hast Du I2C an GPIO0 und 5? GPIO0 ist kritisch, weil er
> entscheidet, wie gebootet wird, der muß beim Reset/Aufwachen sicher auf
> H liegen.

Da hatte ich nicht dran gedacht, bin Anfänger und das ist ein 
Lernprojekt. Ich habe da aber 4,7 kOhm als Pullup an SCL und SDA.

Michael U. schrieb:
> Üblich ist eher GPIO4 und 5 für I2C, die sind da unkritisch.

OK, werde ich in Zukunft beachten.

--------------------------------------------------------

So, jetzt habe ich eine 2. Platine nur minimal bestückt, also auch beide 
Sensoren am I2S weggelassen. Und auch mein Programm habe ich sehr 
minimalistisch gehalten.
Das Problem besteht weiterhin. Nach dem Tiefschlaf startet der ESP und 
schreibt mir:

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

Das ist exakt die gleiche Meldung wie wenn ich den Reset Taster drücke. 
Nur mit dem Unterschied, dass beim Reset Taster das Programm startet und 
SCL ruhig bleibt.
Über den Reset nach dem deep sleep startet das Programm nicht und SCL 
toggelt fröhlich vor sich hin.

Das Programm:

int cap_u_gate = 12;
int cap_u_temp_u = 13;
int cap_o_gate = 2;
int cap_o_temp_m = 14;
int temp_gate = 15;

void setup() {
pinMode(cap_u_gate, OUTPUT);
pinMode(cap_u_temp_u, INPUT);
pinMode(cap_o_gate, OUTPUT);
pinMode(cap_o_temp_m, INPUT);
pinMode(temp_gate, OUTPUT);

digitalWrite(cap_u_gate,LOW);
digitalWrite(cap_o_gate,LOW);
digitalWrite(temp_gate,LOW);

// UART
Serial.begin(74880);
Serial.println("Start!");

ESP.deepSleep(10e6,WAKE_RF_DISABLED);
delay(100);
}

void loop() {
}

Um Strom zu sparen habe ich vor ein paar Sensoren Schalter eingebaut. 
Die sollen als Default abgeschaltet sein

digitalWrite(cap_u_gate,LOW);
digitalWrite(cap_o_gate,LOW);
digitalWrite(temp_gate,LOW);

und nur zur Messung kurz eingeschaltet werden, also nur kurz Strom 
bekommen. Wie ist das mit dem deep sleep, was machen da die IOs? 
Behalten die den letzten Zustand, werden die hochohmig?

Edit:
Auch ein noch kleineres Programm wird nach dem deep sleep nicht erneut 
aufgerufen:

void setup() {
Serial.begin(74880);
Serial.println("Start!");
ESP.deepSleep(10e6,WAKE_RF_DISABLED);
delay(100);
}

void loop() {
}

Kann das was mit dem UART zu tun haben? Darf der beim Reset nach dem 
deep sleep nicht angeschlossen sein?
Mich irritiert, dass der normale Reset über den Taster funktioniert und 
der ESP auch exakt die gleiche Meldung ausgibt, egal ob über Resettaster 
oder über automatischen Reset nach deep sleep.

[Stefan F. (stefanus)]

Ich zitiere mal von meiner eigenen Webseite:
> Normaler Start:
>    GPIO0  = HIGH
>    GPIO15 = LOW
>    GPIO1 (TxD)   = nicht herunter ziehen
>    GPIO2 (TxD1) = nicht herunter ziehen

Prüfe diese Signalpegel. Einer davon wird wohl nicht stimmen.

In der Nähe des ESP Moduls sollten alle Widerstände nicht mehr als 2,2kΩ 
haben, weil die Signale sonst von den eigenen Radiowellen gestört 
werden. 100kΩ sind dort ein absolutes No-Go.

S1 ist gefährlich. Wenn er geschlossen ist, bootet das Ding nicht und 
wenn du diesen Pin versehentlich aus Ausgang konfigurierst, geht er auch 
noch kaputt!

Bei deinem "cap_o_gate" Pin ist unklar, was du da angeschlossen hast. 
Wenn da eine kapazitive Last dran hängt (das kann auch ein MOSFET sein), 
dann kann das auch den Bootvorgang blockieren.

> Kann das was mit dem UART zu tun haben? Darf der beim Reset nach
> dem deep sleep nicht angeschlossen sein?

Der darf schon angeschlossen sein, aber TxD muss auf High Pegel liegen. 
Wen du da einen USB-UART Adapter dran hängen hast, der keine 
Stromversorgung hat, dann wird er diesen Pin herunter ziehen, was nicht 
sein darf.

[Gustl B. (-gb-)]

Stefan ⛄ F. schrieb:
> Ich zitiere mal von meiner eigenen Webseite:
>> Normaler Start:
>>    GPIO0  = HIGH
>>    GPIO15 = LOW
>>    GPIO1 (TxD)   = nicht herunter ziehen
>>    GPIO2 (TxD1) = nicht herunter ziehen
>
> Prüfe diese Signalpegel. Einer davon wird wohl nicht stimmen.

Daran hatte ich mich gehalten bei der Schaltung. Aber gut, ich habe 
gemessen und zwar während der im tiefschlaf ist. Weil das ja der Zustand 
ist aus dem heraus der aufwacht.

TXD High
RXD High
IO5 unverbunden, Low
IO4 Pullup, High
IO0 Pullup, High
IO2 Pullup, High
IO15 Pulldown, Low
IO16 Pullup, High
IO14 Pulldown, Low
IO12 Pulldown, Low
IO13 Pulldown, Low

High und Low sehen auf dem Oszi wunderbar stabil aus und ändern sich 
während des Tiefschlafs auch nicht.

Stefan ⛄ F. schrieb:
> In der Nähe des ESP Moduls sollten alle Widerstände nicht mehr als 2,2kΩ
> haben, weil die Signale sonst von den eigenen Radiowellen gestört
> werden. 100kΩ sind dort ein absolutes No-Go.

OK, dann tausche ich die mal aus. Konnte ich im Datenblatt nicht finden 
... und ich betreibe den ja ohne WLAN.

Stefan ⛄ F. schrieb:
> S1 ist gefährlich. Wenn er geschlossen ist, bootet das Ding nicht

Ja, aber wie denn sonst? Ich brauche den doch um in den Download Modus 
zu kommen? Bisher bootet der wunderbar wenn ich Reset (S2) drücke. Und 
auch nach dem Tiefschlaf bootet der da irgendwie, der schreibt mir ja 
diese eine Zeile und dort exakt den gleichen Boot Mode wie wenn ich den 
über S2 resette. Nur das Programm startet dann nicht, dafür toggelt die 
SCL.

Stefan ⛄ F. schrieb:
> wenn du diesen Pin versehentlich aus Ausgang konfigurierst, geht er auch
> noch kaputt!

Steht das im Datenblatt? Wenn ich den über Wire als SCL konfiguriere 
dann ist das doch ein Ausgang. Bisher lebt der IO. Auf einer anderen 
Platine seit mehreren Wochen.

Stefan ⛄ F. schrieb:
> Bei deinem "cap_o_gate" Pin ist unklar, was du da angeschlossen hast.

Da soll natürlich was dran an den IO, aber jetzt in der 
Minimalbestückung ist nix dran. Da ist die Schaltung gerade genau so wie 
im Schaltplan.

Stefan ⛄ F. schrieb:
> Der darf schon angeschlossen sein, aber TxD muss auf High Pegel liegen.

Ist angeschlossen, ein USB Adapter mit FT232RL, der bekommt seinen Strom 
natürlich über USB. Beide UART IOs sind High.

Ich verwende ja für den Sleep

ESP.deepSleep(60e6,WAKE_RF_DISABLED);

aber man kann ja auch

esp_sleep_enable_timer_wakeup(60*1000000);
esp_deep_sleep_start();

nutzen wenn ich das richtig verstanden habe.

Da muss ich aber z. B. "soc/rtc_cntl_reg.h" verwenden und die findet 
meine Arduino IDE nicht. Wo bekomme ich die her oder was muss ich dazu 
installieren um diese "nativen" Befehlen nutzen zu können?

Und dann gibt es ja noch diese blaue LED am ESP. Kann man die einfach 
weglöten oder ist die irgendwie erforderlich?

Edit:
Alle Pullups und Pulldowns gegen 2 kOhm ausgetauscht. Verhalten bleibt 
leider gleich.

[Gustl B. (-gb-)]

So, Fehler gefunden, Lösung noch unbekannt.

Gefunden hier:
https://github.com/esp8266/Arduino/issues/5892
https://github.com/esp8266/Arduino/issues/6007

Was ist also das Problem?

Der Resetpuls von IO16 ist eher kurz und schwach und schafft es nicht, 
Reset ordentlich runter zu ziehen. Siehe Oszi Bildchen.

Ich habe extern keinen Kondensator dran. Und ich habe auch den 10 kOhm 
Pullup an Reset durch einen 300 kOhm ersetzt. Das zeigt das Bild. Da ist 
also intern im ESP-12S wohl ein Kondensator verbaut. Nach Datenblatt 
http://wiki.ai-thinker.com/_media/esp8266/a020ps01a0_esp-12s_product_specification.pdf 
sogar ein 1 uF.

So wie ich das sehe kann ich das nicht am Modul (Software/Hardware) 
lösen ausser ich löte die Schirmung und den Kondensator weg. Machbar, 
klar, aber ne, will ich nicht.

Wie könnte man das extern lösen?
Ich bräuchte eine Schaltung die den Kondensator schneller entlädt oder 
den Resetpuls verlängert. Gleichzeitig geht es natürlich um den 
Tiefschlaf, die Schaltung darf also nicht viel Strom ziehen.

[Gustl B. (-gb-)]

Ich habe jetzt verschiedene Dinge probiert aber ohne Erfolg.

Dem ESP-12S habe ich die Schirmung geklaut (geht schnell und ohne Löten) 
und den Kondensator C8 (0402 zum Glück gut lötbar) entfernt.
Dann konnte ich den Resetpuls also mal angucken wie der wirklich 
aussieht. Und tja, der ist sehr kurz. Ich vermute das ist eben ein CPU 
Takt.

Das wollte ich irgendwie verlängern, also habe ich extern wieder 
verschiedene Cs hingelötet und rumprobiert. Wie es aussieht zieht der 
IO16 nur sehr kurz und eher schwach. Ein Pullup, auch der ESP-interne R2 
(12k, 0402) zieht das schon schnell nach oben.

Mein bestes Ergebnis ist weder Pullup noch Pulldown und ein sehr kleiner 
Kondensator um die 100 pF. Aber auch das reicht nicht für den Reset.

Wobei ... irgendwas wird ja resettet, der ESP schreibt mir ja diese eine 
Zeile.

Ich brauche also eine andere Schaltung um diesen kurzen Puls zu 
verlängern. Oder ich lass das mit diesem ESP. Boards anderer Hersteller 
scheinen ja weniger Ärger zu machen.

[Stefan F. (stefanus)]

Gustl B. schrieb:
> Ja, aber wie denn sonst? Ich brauche den doch um in den Download Modus
> zu kommen?

Wenn der Taster nur dazu dient, dann ist es Ok.

>> wenn du diesen Pin versehentlich aus Ausgang konfigurierst, geht er auch
>> noch kaputt!
> Steht das im Datenblatt?

Manche Dinge muss man wissen, ohne dass sie im Datenblatt stehen. Dazu 
gehört die Erkenntnis, dass ein Kurzschlusstrom in der regel weit über 
den Maximum Ratings ist, sofern das Gegenteil nicht ausdrücklich erwähnt 
wird.

Wenn du dir da keine Sorgen machst, dann werfe mal eine Hand voll 
Schrauben in deinen laufenden PC. Ich denke, danach weist du Bescheid, 
was Kurzschlussfestigkeit angeht.

> soc/rtc_cntl_reg.h
Ich glaube, diese Datei ist Bestandteil des Espressif SDK. Aber da gibt 
es viele unterschiedliche Versionen und außerdem würde ich die Arduino 
Funktion nutzen, so weit es geht. Die machen vor dem Deep-Sleep sicher 
noch einige Vorbereitungen (z.B. Timer stoppen oder so), was nötig sein 
könnte.

> Und dann gibt es ja noch diese blaue LED am ESP. Kann man die einfach
> weglöten

Ja

[Stefan F. (stefanus)]

Gustl B. schrieb:
> So, Fehler gefunden, Lösung noch unbekannt.
> Der Resetpuls von IO16 ist eher kurz

Mach den Kondensator am Reset Pin weg.

> Ich habe extern keinen Kondensator dran.

Huch! Du hast in deinem Schaltplan aber einen drin (C7). Tue uns bitte 
einen Gefallen und diskutiere nicht über einen Plan, der nicht dem 
Aufbau entspricht.

Probiere mal ein ESP-12F Modul, damit hatte ich noch keine Probleme.

[Michael U. (amiga)]

Hallo,

ich hatte schon mehrere ESP8266-12E mit DeepSleep im Einsatz, einer 
davon über lange Zeit. Derartige Probleme hatte ich da nie.
Am Modul generell 10k GPIO15-GND, Brücke GPIO16-Reset, EN über 10k an 
+Ub.
Da einen 100mF Elko zwischen +Ub und GND am Modul.
Ansonsten nur die Sensoren am I2C, BME280 im Forced Mode, dann schläft 
er sowieso von alleine wieder.
Mit WAKE_RF_DISABLED hatte ich auch mal experimentiert, der reale Gewinn 
war mir aber dann den Aufwand nicht wert.

Gruß aus Berlin
Michael

[Johannes S. (Gast)]

Stefan ⛄ F. schrieb:
> Huch! Du hast in deinem Schaltplan aber einen drin (C7). Tue uns bitte
> einen Gefallen und diskutiere nicht über einen Plan, der nicht dem
> Aufbau entspricht.

Das steht schon im ersten Post, als erste Massnahme. Zeichnest du für 
jeden Test bei einer Fehlersuche erst einen neuen Schaltplan?

Stefan ⛄ F. schrieb:
> Wenn du dir da keine Sorgen machst, dann werfe mal eine Hand voll
> Schrauben in deinen laufenden PC.

Ver(störender) finde ich da solche abstrusen Vorschläge/Vergleiche.

Und genau das Problem wird mit neueren ESP-12F in dem Issue genannt.

[Gustl B. (gustl_b)]

Stefan ⛄ F. schrieb:
> Huch! Du hast in deinem Schaltplan aber einen drin (C7). Tue uns bitte
> einen Gefallen und diskutiere nicht über einen Plan, der nicht dem
> Aufbau entspricht.

Dann lies doch mal welchen Wert C7 hat.

Stefan ⛄ F. schrieb:
> Mach den Kondensator am Reset Pin weg.

Der externe Kondensator würde da mit 100 nF oder so kaum was ändern denn 
im ESP Modul ist ein 1 uF am Reset Pin. Den habe ich auch entfernt (C8).

Ich sehe das jetzt als komisches Hardwareproblem von einem Modul das 
sehr schlecht designt ist. Guckt euch mal euren Resetpuls an mit dem 
Oszi. Der geht nicht mal soweit runter dass er das CMOS Low Level 
erreicht. Was der Hersteller da gemacht hat ist Pfusch.
Ob das jetzt AI Thinker oder Espressif ist weiß ich aber nicht, 
vielleicht sind meine Module von Amazon auch keine Originale obwohl die 
recht original aussehen.

Es könnte natürlich weiterhin auch ein Softwareproblem sein. Der ESP 
schreibt mir ja nach dem Aufwachen genau die selbe Zeile wie nach dem 
funktionierendem Reset mit Button. Auf Github in dem Thread hatte Jemand 
eine andere Deepsleep Funktion geschrieben die bei manchen Leuten das 
Problem gelöst hat. Bei mir leider nicht, ich bekomme da eine Bootloop.

Ich gebe aber noch nicht ganz auf sondern werde mir einen schönen 
Resetpuls bauen. Irgendwie.

[batman (Gast)]

Versuchs einfach mal mit der Firm/Hardware von einem der paar Tausend, 
wo es problemlos funktioniert.

[Stefan F. (stefanus)]

Johannes S. schrieb:
> Und genau das Problem wird mit neueren ESP-12F in dem Issue genannt.

Welches Problem meinst du, das Aufwachen oder die kurzschlussfestigkeit?

Wie wird es denn genannt, als gelöst oder noch offen?

[Stefan F. (stefanus)]

Gustl B. schrieb:
> Ich sehe das jetzt als komisches Hardwareproblem von einem Modul das
> sehr schlecht designt ist. Guckt euch mal euren Resetpuls an mit dem
> Oszi. Der geht nicht mal soweit runter dass er das CMOS Low Level
> erreicht. Was der Hersteller da gemacht hat ist Pfusch.

Das sehe ich auch so. Da ich damit noch keine Probleme hatte, wusste ich 
nicht einmal, dass der Pin überhaupt mit einem Modul-internen 
Kondensator beschaltet ist. Und dann auch noch so einen großen! Warum 
machen die das?

[Gustl B. (gustl_b)]

Ich wusste das auch nicht. Meine Vermutung ist, dass die das machen um 
was dem kurzen Resetpuls einen längeren Puls zu erzeugen. Das klappt ja 
auch, aber dann geht die Spannung nicht mehr weit runter und die Flanken 
sind nicht steil.

[batman (Gast)]

Ein externer Reset-Puls wird generell extern erzeugt und muß immer eine 
definierte Minimalbreite haben.

[Gustl B. (-gb-)]

Nun, typischerweise wird GPIO16 verwendet für den Reset.

------------------------------------------------------------

Aber gut, es geht weiter:

Ich habe jetzt an Reset einen schwachen Pullup. GPIO 16 ist nicht mit 
Reset verbunden weil ich mir das Signal an GPIO 16 mal getrennt angucken 
wollte.

Der GPIO 16 ist erstmal Low. Sobald der ESP in den Tiefschlaf wechselt 
geht der GPIO 16 auf High. Wenn der Tiefschlaf vorbei ist wechselt der 
wieder auf Low.

Ausserdem:
Auch wenn der GPIO 16 nicht mit dem Reset verbunden ist schreibt mir der 
ESP nach der Tiefschlafzeit diese eine Zeile. Also irgendwie oder 
irgendwas im ESP wacht da auch komplett ohne Reset auf.

Und dann gibt es ein weiteres Problem:
Ich kann den also mauell resetten indem ich Reset mit einem Draht kurz 
mit Masse verbinde.
Wenn ich das nach dem Tiefschlaf mache, dann funktioniert der manuelle 
Reset immer erst beim zweiten Versuch. Das sieht also so aus:

- ESP wacht aus dem Tiefschlaf auf und schreibt mir diese eine Zeile, 
startet aber nicht das Programm.
- Ich resette manuell und der ESP schreibt mir wieder nur eine Zeile.
- Ich resette erneut manuell und erst dann startet das Programm.

batman schrieb:
> Versuchs einfach mal mit der Firm/Hardware von einem der paar Tausend,
> wo es problemlos funktioniert.

Firmwares habe ich noch keine probiert, davon habe ich keine Ahnung. Ich 
habe bisher nur in der Arduino IDE ein Board gewählt und diesen Code 
verwendet:

ESP.deepSleep(10e6,WAKE_RF_DISABLED);
delay(100);

[Klaus (Gast)]

Stefan ⛄ F. schrieb:
> Da ich damit noch keine Probleme hatte, wusste ich
> nicht einmal, dass der Pin überhaupt mit einem Modul-internen
> Kondensator beschaltet ist. Und dann auch noch so einen großen! Warum
> machen die das?

Wir hatten hier mehrmals das Problem, daß die ESP an bestimmten 
Versorgungen nicht richtig starteten. Das lag am Ende nicht am Strom für 
den Funk, der läuft erst viel später an, sondern am Reset. Der Prozessor 
läuft schon los, wenn die Spannung eigentlich noch zu niedrig ist. Da 
gehört eigentlich ein Resetbaustein hin. Bevor es diese Bausteine gab, 
hat man gerne den Resetpuls über einen Kondensator verzögert, 
Resetbaustein für Arme. Ich vermute, dazu ist er da. Statt also den 
GPIO16 direkt mit Reset zu verbinden, sollte man dort einen 
Resetbaustein mit Reseteingang einbauen.

Gustl B. schrieb:
> Firmwares habe ich noch keine probiert, davon habe ich keine Ahnung.
> Ich habe bisher nur in der Arduino IDE ein Board gewählt und diesen
> Code verwendet:

Was die Arduino IDE erzeugt, ist die Firmware.

Gustl B. schrieb:
> Es könnte natürlich weiterhin auch ein Softwareproblem sein. Der ESP
> schreibt mir ja nach dem Aufwachen genau die selbe Zeile wie nach dem
> funktionierendem Reset mit Button.

Der ESP hat gar keinen Deepsleep. Er kann sich nur selbst ausschalten 
aber nicht wieder einschalten. Er hat aber einen Timer, der unabhängig 
läuft. Mit seinem Ausgang, den man auf GPIO16 legen kann, weckt er dann 
den ESP mit einem Reset wieder auf. Für den ESP ist das ein ganz 
gewöhnlicher Reset, daher die gleiche Meldung.

MfG Klaus

[Gustl B. (-gb-)]

Klaus schrieb:
> Der Prozessor
> läuft schon los, wenn die Spannung eigentlich noch zu niedrig ist.

Na gut, das kann ich ausschließen, denn die ganze Zeit über liegt eine 
schöne Spannung an. Die bricht auch nicht ein. Also wenn der aus dem 
Tiefschlaf aufwacht und resettet dann ändert sich die Spannung am ESP 
Modul nicht oder nur minimal. Ich habe dazu ja extra diesen eher dicken 
DCDC verbaut und einen 100 uF Kerko an den VCC Anschluss des ESP Moduls 
gesetzt.

Klaus schrieb:
> Was die Arduino IDE erzeugt, ist die Firmware.

OK, na dann erstelle ich also mit jeder Kompilation eine neue Firmware, 
fein.

Klaus schrieb:
> Für den ESP ist das ein ganz
> gewöhnlicher Reset, daher die gleiche Meldung.

Tja irgendwie ja nicht denn er wacht anders auf. Und nach dem Tiefschlaf 
funktioniert auch der erste manuelle Reset über den Taster nicht. Auch 
da schreibt mir der ESP dann diese eine Zeile, startet aber nicht mein 
Programm.

Ohne Tiefschlaf funktioniert der Reset immer ohne Probleme. Aber wenn 
der ESP vorher im Tiefschlaf war, dann funktioniert der erste manuelle 
Reset nicht mehr. Ein zweiter manueller Reset aber schon. Ich vermute 
also irgendeinen Fehler in der Tiefschlaf Funktion.

Aber ich habe weitergebastelt^^:

Jetzt habe ich ein AND Gatter genommen und das extern an den Reset 
getan.

Reset <= VCC AND GPIO16

Wenn der GPIO16 Low ist, ist Reset auch Low und zwar schön sauber auf 
Masse. Funktioniert aber trotzdem nicht. War aber auch zu erwarten, weil 
nach dem Tiefschlaf ja auch der erste manuelle Reset den ESP nicht 
korrekt startet und beim manuellen Reset über Taster wird Reset ja auch 
schön nach Masse gezogen.

Ich bin jetzt der Meinung das ist ein Softwareding.

In dem Github Thread hatte Jemand eine andere Tiefschlaf Funktion 
gepostet, ich verstehe die nicht, aber vielleicht versteht die ja hier 
Irgendwer. Bei manchen Usern auf Github hat die das Problem behoben, bei 
mir führt die Funktion zu einer Dauerbootschleife.

#define ets_wdt_disable ((void (*)(void))0x400030f0)
#define ets_delay_us ((void (*)(int))0x40002ecc)
#define _R (uint32_t *)0x60000700
void nk_deep_sleep(uint64_t time)
{
  ets_wdt_disable();
  *(_R + 4) = 0;
  *(_R + 17) = 4;
  *(_R + 1) = *(_R + 7) + 5;
  *(_R + 6) = 8;
  *(_R + 2) = 1 << 20;
  ets_delay_us(10);
  *(_R + 39) = 0x11;
  *(_R + 40) = 3;
  *(_R) &= 0xFCF;
  *(_R + 1) = *(_R + 7) + (45*(time >> 8));
  *(_R + 16) = 0x7F;
  *(_R + 2) = 1 << 20;
  __asm volatile ("waiti 0");
}

[Michael U. (amiga)]

Hallo,

Klaus schrieb:
> Der ESP hat gar keinen Deepsleep. Er kann sich nur selbst ausschalten
> aber nicht wieder einschalten. Er hat aber einen Timer, der unabhängig
> läuft. Mit seinem Ausgang, den man auf GPIO16 legen kann, weckt er dann
> den ESP mit einem Reset wieder auf. Für den ESP ist das ein ganz
> gewöhnlicher Reset, daher die gleiche Meldung.

naja, für die DeepSleep Geschichte muß ja Betriebsspannung anliegen 
bleiben.
Der ESP8266 kann bei niedriger und (noch) instabiler Betriebsspannung in 
den Zustand kommen, daß er komplett hängenbleibt und dann gut 20mA und 
mehr verbraucht, Da kommt er auch nicht wieder raus.
Reset ist eigentlich mit dem internen PullUp sehr zuverlässig, ein 
langsamer Anstieg der Spannung an Reset hat hier jedenfalls nie 
Fehlfunktionen ausgelöst. Ich habe DeepSleep schon mit diversen ESP8266 
mal genutzt, vom -01 mit nachgerüsteter Brücke vom GPIO16, auch beim -03 
und -07, es gab hier nie solche Probleme.
GPIO manchmal per Schottkydiode mit Reset verbunden, um Kollisionen mit 
externem Taster oder der DTR/RTS-Logik zu vermeiden.

Gruß aus Berlin
Michael

[Johannes S. (Gast)]

Gustl B. schrieb:
> #define ets_wdt_disable ((void (*)(void))0x400030f0)
> #define ets_delay_us ((void (*)(int))0x40002ecc)

das nimmt an das die Funktionen auf diesen Adressen liegen. Bei 
verschiedenen SDK Versionen können die sicher an verschiedenen Stellen 
liegen, so das es nur mit einer bestimmten Version funktioniert.
Im Boardverwalter sollten sich andere Versionen auswählen lassen, also 
mal mit anderen probieren?

Ich habe 2.4.1 installiert, da passen die Adressen, stehen in
c:\Users\ich\Documents\ArduinoData\packages\esp8266\hardware\esp8266\2.4 
.1\bootloaders\eboot\rom.ld

[Gustl B. (-gb-)]

Johannes S. schrieb:
> Ich habe 2.4.1 installiert, da passen die Adressen,

Fein, du meinst von 2.4.1 von esp8266?

c:\Users\ich\Documents\ArduinoData\packages\esp8266\hardware\esp8266\2.4
.1\bootloaders\eboot\rom.ld

Gibt es bei mir nicht. Windows findet auf meinem Rechner keinen Ordner 
"ArduinoData".

Ich habe die 2.7.2 installiert. Habe jetzt auch die rom.ld gefunden. Die 
Adressen passen, aber wie kann ich überprüfen ob auch

#define _R (uint32_t *)0x60000700

stimmt?

[Johannes S. (Gast)]

Habe auch noch etwas gesucht, die Adressen sind fix im ROM, das sollte 
sich nicht ändern. Aber es muss ja einen Grund geben das der einfache 
delay nach Start zur Endlosschleife wird.
Ja, meine 2.4.1 ist schon alt.

[Stefan F. (stefanus)]

Gustl B. schrieb:
> Firmwares habe ich noch keine probiert,

Wie gesagt kannst du in der Arduino IDE im Boardmanager unterschiedliche 
Versionen der ESP8266 core laden, womit sich auch die Firmware Version 
ändert. Probiere den Core 2.3.0, der läuft gut.

[Stefan F. (stefanus)]

Klaus schrieb:
> Bevor es diese Bausteine gab,
> hat man gerne den Resetpuls über einen Kondensator verzögert,
> Resetbaustein für Arme. Ich vermute, dazu ist er da

Ja, das wäre eine plausible Erklärung.

[Johannes S. (Gast)]

Gustl B. schrieb:
> Die Adressen passen, aber wie kann ich überprüfen ob auch
>
> #define _R (uint32_t *)0x60000700
>
> stimmt?

Die Trickserei mit dem _R durchschaue ich nicht. Sieht jedenfalls sehr 
fragil aus.

[Stefan F. (stefanus)]

Klaus schrieb:
> Er hat aber einen Timer, der unabhängig
> läuft. Mit seinem Ausgang, den man auf GPIO16 legen kann, weckt er dann
> den ESP mit einem Reset wieder auf.

Das ist fast richtig. Der Chip wacht auf ohne diese Verbindung von 
GPIO16 zu RESET auf, aber er macht dann nichts sinnvolles, verplempert 
nur Strom.

Ich vermute, dass diese Verbindung ein Workaround für einen Fehler im 
Chip-Design ist. Eigentlich müsste es auch einen Sleep Modus geben, in 
dem das RAM erhalten bleibt und man ohne Neustart fortsetzen kann.

[Gustl B. (-gb-)]

Stefan ⛄ F. schrieb:
> Der Chip wacht auf ohne diese Verbindung von
> GPIO16 zu RESET auf, aber er macht dann nichts sinnvolles, verplempert
> nur Strom.

Danke! Ja genau so ist das auch, aber mit Eigenheiten.

Der wacht auch ohne die Verbindung auf und gibt sogar diese eine Zeile 
über UART aus.

Aber selbst mit Verbindung und korrektem Reset wacht der nach dem 
Tiefschlaf ebenfalls zuerst nicht richtig auf. Zumindest bei meiner 
Software.

Stefan ⛄ F. schrieb:
> Wie gesagt kannst du in der Arduino IDE im Boardmanager unterschiedliche
> Versionen der ESP8266 core laden, womit sich auch die Firmware Version
> ändert. Probiere den Core 2.3.0, der läuft gut.

Ah, das meinst du mit verschiedenen Firmwares. Ich dachte da gäbe es 
mehrere verschiedene ESP8266 Bibliotheken, aber da finde ich nur die 
eine.

Welches Board sollte ich denn auswählen? Bisher verwende ich das NodeMCU 
1.0.

Jetzt wollte jetzt 2.3.0 installieren und bekomme
java.lang.NullPointerException

Was ist das denn für ein kaputtes Ökosystem? Da verwendet man das ein 
paar Tage und schon zerbröselt es förmlich ...

[Stefan F. (stefanus)]

Gustl B. schrieb:
> Ich dachte da gäbe es
> mehrere verschiedene ESP8266 Bibliotheken

Ja eben, die sind in dem Arduino Core drin.

> Jetzt wollte jetzt 2.3.0 installieren und bekomme
> java.lang.NullPointerException

Probiere zuerst den ESP8266 Core zu deinstallieren und dann wieder zu 
installieren. Wenn das auch nicht klappt, installiere die ganze Arduino 
IDE neu oder downloade beide zusammenhängend als "portable" Version von 
meiner Homepage: http://stefanfrings.de/esp8266/index.html#arduinostart

[Gustl B. (-gb-)]

Stefan ⛄ F. schrieb:
> Probiere zuerst den ESP8266 Core zu deinstallieren und dann wieder zu
> installieren.

Hat funktioniert. Jetzt funktioniert mit der 2.3.0

void setup() {
Serial.begin(74880);
Serial.println("Start!");
}

nicht mehr. Also ganz ohne Tiefschlaf. Nach einem Reset bekomme ich

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

load 0x4010f000, len 1384, room 16 
tail 8
chksum 0x2d
csum 0x2d
v6000001c
~ld
⸮*]X⸮⸮!

Also sieht nach falscher Baudrate aus, habe aber genau die passende 
eingestellt. Naja egal. Welches Board sollte ich denn in der IDE 
auwählen wenn ich den ESP-12S verwende?

[Stefan F. (stefanus)]

Schrott-Meldungen nach einem Reset können passieren, wenn der Zugriff 
auf den Flash zu schnell ist. Probiere mal als Board einen "ESP8266 
generic", dann als Flash Frequency "40 MHz" und den Modus "DIO". Damit 
laufen die meisten Module gut.

Siehe http://stefanfrings.de/esp8266/index.html#flash
Und nochmal http://stefanfrings.de/esp8266/index.html#arduinostart

[Klaus (Gast)]

Stefan ⛄ F. schrieb:
> Ich vermute, dass diese Verbindung ein Workaround für einen Fehler im
> Chip-Design ist.

Das klingt zusammen mit einigen anderen Aussagen, die ich gelesen habe, 
plausibel.

MfG Klaus

[Gustl B. (-gb-)]

Stefan ⛄ F. schrieb:
> Und nochmal http://stefanfrings.de/esp8266/index.html#arduinostart

Danke. Hatte ich schon gelesen, aber ich hatte eher gehofft, dass ich 
irgendwo ein ESP-12S Board finde.

> Reset Method: NodeMCU, spielt keine Rolle wenn die
> Reset+Flash Tasten manuell drückt

Was bewirken denn die unterschiedlichen Einstellungsmöglichkeiten?

Klaus schrieb:
> Das klingt zusammen mit einigen anderen Aussagen, die ich gelesen habe,
> plausibel.

Gibt es dann auch bugfreie ESP Boards? Wie sind die Boards/Module von 
Espressif selbst? Können die auch alle mit der Arduino IDE verwendet 
werden oder ist diese Kompatibilität zur Arduino IDE eine Leistung der 
OpenSource Gemeinschaft? Ich meine, wenn Espressif das nicht selber 
macht, dann muss sich Jemand finden oder auch nicht und es ist nicht 
sicher dass alle Espressif Module mit der Arduino IDE verwendet werden 
können.

---------------------------------

Der ESP kann sich selbst resetten und auch korrekt starten. Und zwar 
wenn ich in der Arduino IDE ein Programm/Firmware aufspiele kann der 
danach automatisch neu starten und das Programm ausführen. Geht 
wunderbar. Es sind dazu keine Buttons nötig. Dann sollte der nach dem 
Tiefschlaf auch korrekt starten können. Das wird immer mehr zu einem 
Softwareding.

[Stefan F. (stefanus)]

Gustl B. schrieb:
> Was bewirken denn die unterschiedlichen Einstellungsmöglichkeiten?

Lies doch einfach die Webseite. Die Nodemcu Reset Methode ist dort 
beschrieben. Die andere kenne ich nicht.

[Stefan F. (stefanus)]

Gustl B. schrieb:
> Gibt es dann auch bugfreie ESP Boards?

Wahrscheinlich nicht. Das Hauptproblem ist die Software. Die ist so 
komplex und eilig zusammen gestrickt, dass sie wohl nie wirklich fertig 
wird.

Die ESP-12F Module von AI-Tinker haben allerdings einen guten Ruf.

> Wie sind die Boards/Module von Espressif selbst?

Brauchbar. Die haben sich aber dem ESP32 zugewendet. Im ESP8266 Bereich 
ist nichts großartiges mehr zu erwarten.

> Ich meine, wenn Espressif das nicht selber
> macht, dann muss sich Jemand finden

Tue dir keinen Zwang an, fange an! Beklage dich nicht, dass die 
Hobbyentwickler nicht alle Module kennen und unterstützen. Das ist doch 
ein Fass ohne Boden! Dabei gibt es das "generische ESP8266 Board", damit 
laufen alle. Man muss die Parameter nur passend einstellen.

Die ganzen Boards unterscheiden sich (in Arduino) nur in den Parametern. 
Du kannst die boards.txt selbst erweitern.

[Gustl B. (-gb-)]

Stefan ⛄ F. schrieb:
> Die andere kenne ich nicht.

OK.

> We recommend that you use CHIP_EN, instead of EXT_RSTB, to reset the chip.

Aha, das empfiehlt Espressif. Also sollte ich doch eine ordentliche 
Resetschaltung bauen die sich an die Vorgaben hält. Wobei Espressif auch 
vorschlägt IO16 mit Reset zu verbinden um aus dem Tiefschlaf 
aufzuwachen.

Stefan ⛄ F. schrieb:
> Tue dir keinen Zwang an, fange an!

Tja da bin ich noch Anfänger, ich liefere da ungerne schlechten Code ab. 
Andere Sachen gebe ich gerne weiter, aber ja, vielleicht sollte ich mir 
mal einen Github Account klicken ...

Stefan ⛄ F. schrieb:
> Die ESP-12F Module von AI-Tinker haben allerdings einen guten Ruf.

Sehr fein.

Stefan ⛄ F. schrieb:
> Die ganzen Boards unterscheiden sich (in Arduino) nur in den Parametern.

Ah OK. Na dann ...

Zusätzlich zu der Arduino IDE gibt es noch die Software von Espressiv 
selbst. Ich habe eine Empfehlung für diese Tiefschlaffunktion bekommen:

esp_sleep_enable_timer_wakeup(time);
esp_deep_sleep_start();

Was muss ich machen um diese Funktionen (vermutlich nativ aus der 
Espressif Software) in der Arduino IDE nutzen zu können?

[Stefan F. (stefanus)]

Gustl B. schrieb:
>> We recommend that you use CHIP_EN, instead of EXT_RSTB, to reset the chip.
> Aha, das empfiehlt Espressif.

Vorsicht, wenn die Software abschmiert hilft oft nur ein richtige Reset. 
Der Enable Eingang reagiert dann nicht mehr.

Gustl B. schrieb:
> Was muss ich machen um diese Funktionen (vermutlich nativ aus der
> Espressif Software) in der Arduino IDE nutzen zu können?

Ich habe weiter oben bereits davon abgeraten. Programmiere bei 
bestehenden Funktionen nicht am Framework vorbei - es sei denn, die hast 
Lust auf ganz schwierige Probleme.

[Gustl B. (-gb-)]

Stefan ⛄ F. schrieb:
> Lust auf ganz schwierige Probleme.

Ja naja, wenn die Funktion vom Framework mein Problem nicht löst würde 
ich das gerne trotzdem anders versuchen. Ich bin jetzt alle Versionen 
vom ESP8266 Framework durch und das waren nicht wenige.

Edit:
Kann es sein, dass es die Funktionen

esp_sleep_enable_timer_wakeup(time);
esp_deep_sleep_start();

für den ESP8266 nicht gibt sondern nur für den ESP32?

[Klaus (Gast)]

Stefan ⛄ F. schrieb:
> Ich vermute, dass diese Verbindung ein Workaround für einen Fehler im
> Chip-Design ist.

Gustl B. schrieb:
> Gibt es dann auch bugfreie ESP Boards?

Wenn es ein Problem im Chip ist, wie soll ein Board das besser machen?

Auf den Modulen ist doch eigentlich nichts drauf. Da ist der ESP und das 
serielle Flash. Da der ESP aus seinem ROM daraus bootet, muß das Flash 
exakt so angeschlossen werden, wie es ist. Dazu ein paar Pullups, 
Pulldowns, Stützkondensatoren und ne Leiterbahn als Antenne. Je nach 
Modul ESP01 bis ESP12 werden mehr oder auch alle GPIOs rausgeführt. 
Inzwischen haben auch die ESP01 meisst größere FLASH, kosten ja fast 
nix. Alles andere ist nicht essentiell, weder ein Spannungsregler noch 
ein USB-UART. Das kann man auch extern anschließen. Ich packe ESP01, 
wenns steckbar sein soll, ESP07 mit externer Antenne oder ESP12 auf 
meine eigenen Platinen und benutze für alle die gleiche Basissoftware.

Deepsleep nutze ich gar nicht, Wifi und Lowpower passen für mich nicht 
zusammen. Für mich sind die ESP Ersatz für Ethernet, billiger als ein 
Magjack plus Kabel.

Die Diskussion um die Boards kommt mir vor wie ein Streit welcher 
Jahrgang eines Weins der bessere ist.

MfG Klaus

[Gustl B. (-gb-)]

Klaus schrieb:
> Die Diskussion um die Boards kommt mir vor wie ein Streit welcher
> Jahrgang eines Weins der bessere ist.

Naja manche ESP Module sind ja schon länger am Markt und andere noch 
nicht so lange. Da könnte es durchaus bugbereinigte Versionen vom 
gleichen Chip geben.

[Michael U. (amiga)]

Hallo,

Gustl B. schrieb:
> Klaus schrieb:
>> Die Diskussion um die Boards kommt mir vor wie ein Streit welcher
>> Jahrgang eines Weins der bessere ist.
>
> Naja manche ESP Module sind ja schon länger am Markt und andere noch
> nicht so lange. Da könnte es durchaus bugbereinigte Versionen vom
> gleichen Chip geben.

wenn man lange zurück sucht findet man bei Espressif was zum 
WakeUp/GPIO16 Problem. Es ist ein Designfehler des ESP8266, mir ist 
nicht bekannt, daß der jemals behoben wurde oder werden sollte.
In der ArduinoID bzw. in den neueren SDK Versionen gibt es auch ein 
problem mit WAKE_RF_DISABLED, das ging irgendwann nicht mehr bzw. nicht 
mehr richtig.
Da habe ich nicht verfolgt, ob es irgendwann wieder repariert wurde.
Aber das findet man ja problemlos raus, indem man eben mal 
WAKE_RF_DEFAULT setzt.
Ich habe jetzt auf Anhieb nur diesen Thread aus der Zeit gefunden:
https://www.esp8266.com/viewtopic.php?f=33&t=16949

Ich habe das seit damals (könnte so 2018 gewesen sein) nicht mehr weiter 
verfolgt.

Gruß aus Berlin
Michael

[Stefan F. (stefanus)]

Danke Michael, das hilft weiter.

[batman (Gast)]

Wo ist jetzt der Zusammenhang? Hängts von der WAKE_..-Option ab?

[Gustl B. (gustl_b)]

Ne, auch ohne Option ist das Problem gleich. Aber gut, Designfehler. Tja 
... dann werde ich wohl einen anderen ESP verwenden ...

[Johannes S. (Gast)]

In dem langen Thread auf GitHub hatte ja auch jemand geschrieben das es 
am Flash liegt und der Fehler nach Austausch weg war.
Das ist wohl auch ein bekanntes Problem und in den generischen ESP wurde 
eingebaut das der bis 20 MHz runter getaktet werden kann.

[Gustl B. (gustl_b)]

Tja irgendwie hat jeder Lösungsvorschlag irgendjemandem geholfen. Das 
mit dem Flash hatte ich aber noch nicht probiert, vielen Dank!

Aus dem Code oben wäre noch interessant wie man den Wert, also 
vermutlich eine Start Adressen von _R herausfindet.

[Johannes S. (Gast)]

Gustl B. schrieb:
> Aus dem Code oben wäre noch interessant wie man den Wert, also
> vermutlich eine Start Adressen von _R herausfindet.

das müssten irgendwelche Register der RTC sein, muss man aus den .ld 
files rausfinden. Und die RTC Struktur für die Felder die da gesetzt 
werden.
Die Adressen dürften doch festgenagelt sein, meine Vermutung das die 
sich mit der Firmware ändern ziehe ich zurück. Wenn ich jetzt richtig 
verstehe hat der ESP ein Bootrom und das ist schon lange unverändert.

Und es scheint ja mehrere Ursachen für das Problem zu geben:
1) Firmwarefehler in älterer Version mit dem Wakeup Mode, aber schon 
länger gefixt
2) Bei einigen WeMos ist eine Automatik mit Transistoren drauf die nicht 
richtig kompatibel ist
3) schlechte (zu langsame) Flash Speicher.
4) das übliche Power Problem. Wobei da ja bekannt ist das der ESP 
durstig ist.

[Johannes S. (Gast)]

Das hier ist noch interessant bzgl Boot Prozess:
https://richard.burtons.org/2015/05/17/esp8266-boot-process/
Und sein folgender Blog mit GitHub Link.

[Gustl B. (-gb-)]

Johannes S. schrieb:
> 1) Firmwarefehler in älterer Version mit dem Wakeup Mode, aber schon
> länger gefixt

Also was meinst du mit Firmware? Das was ich über die Arduino IDE 
hochlade oder das was dauerhaft in dem Baustein bleibt?

Johannes S. schrieb:
> 3) schlechte (zu langsame) Flash Speicher.

Ich habe jetzt mal mit geringererem Flash Takt versucht, aber auch das 
bringt nix.

Johannes S. schrieb:
> 4) das übliche Power Problem. Wobei da ja bekannt ist das der ESP
> durstig ist.

Gut, das kann ich ausschließen. Wenn ich den Resetpuls nach dem 
Tiefschlaf anlege bootet der nicht korrekt, bei einem zweiten Resetpuls 
nach dem Tiefschlaf aber immer korrekt. Ausserdem habe ich da einen DCDC 
der große Ströme kann und auch noch dicke Kondensatoren. Die 
Versorgungsspannung bricht laut Oszilloskop nicht ein, also ein paar 
wenige mV, aber nur sehr greing.

[Stefan F. (stefanus)]

Gustl B. schrieb:
> Also was meinst du mit Firmware? Das was ich über die Arduino IDE
> hochlade oder das was dauerhaft in dem Baustein bleibt?

Nochmal: Die Arduino IDE erzeugt eine Firmware. Diese basiert auf einer 
bestimmten Version des SDK von Espressif, welches wiederum einen 
wesentlichen Teil in Binärform ohne Quelltext enthält.

Dein Arduino Sketch ist die Firmware. Oder nur der Teil von Espressif - 
je nach Sichtweise. Wenn du die Version des Arduino Cores änderst, 
änderst du damit auch die Version des Teils, den Espressif dazu 
beigesteuert hat.

Und dann gibt es da noch den Bootloader, der ist fest im Chip drin und 
nicht veränderbar. Der Bootloader überträgt die Firmware vom seriellen 
Port in den Flash Speicher.

[Gustl B. (-gb-)]

Stefan ⛄ F. schrieb:
> Oder nur der Teil von Espressif -
> je nach Sichtweise.

Genau darum geht es mir. Bei einem Android Handy z. B. könnte man das 
Android das man da "flasht" auch als "Firmware" bezeichnen und macht das 
wohl manchmal auch. Aber da ist dann noch viel weitere Software im Gerät 
wie der Bootloader, das Recovery, das Baseband, ...

Firmware ist normalerweis als die Software definiert, die zur Hardware 
gehört. Die vom Hersteller aufgespielt wird und vom Benutzer nicht 
verändert werden kann. Beim ESP würde ich also den Bootloader oder wie 
auch immer man das dennt, als Firmware bezeichnen.

Stefan ⛄ F. schrieb:
> Nochmal: Die Arduino IDE erzeugt eine Firmware.

OK, wenn hier diese Definition gemeint ist, dann ist das Bootproblem 
definitiv nicht für alle ESP8266 behoben.

[Stefan F. (stefanus)]

Gustl B. schrieb:
> Firmware ist normalerweis als die Software definiert, die zur Hardware
> gehört. Die vom Hersteller aufgespielt wird und vom Benutzer nicht
> verändert werden kann

Als Softwareentwickler bist du der Hersteller. Dein Programm ist die 
Firmware. Wenn du mit Arduino Arbeitest, hast du Bootloader + Firmware. 
Die Firmware erzeugt die Arduino IDE.

Deine Sichtweise, dass oben drauf noch Anwendungsprogramme laufen passt 
eher zur NodeMCU Firmware. Die installiert man tatsächlich nur einmal 
und lädt dann zusätzlich eigene austauschbare LUA Scripte hoch.

[Gustl B. (-gb-)]

OK, Verstanden. Nun, ESP-12E und ESP-12F sind kompatibel (Abmaße und 
Belegung) zum ESP-12S. Glaubt ihr bei denen funktioniert der Tiefschlaf 
oder sollte ich zum ESP32 wechseln?

[Stefan F. (stefanus)]

Gustl B. schrieb:
> Glaubt ihr bei denen funktioniert der Tiefschlaf

Bei meinen funktioniert er anstandslos.

[Pandur S. (jetztnicht)]

Der Deep Sleep Betriebszustand hat ein paar Begleitumstaende, um den 
ueberhaupt zu ermoeglichen. Es geht darum extrem wenig Power zu 
verbrauchen. Daher sollten alle unbeschalteten Eingaenge auf Ausgang 
geschaltet werden. Wenn man die Wahl eines Pullup oder Pulldown am 
Eingang hat, welcher verbraucht weniger Strom ?
Ein Spannungteiler von 1MOhm zieht auch schon 3uA...
Was geschieht mit der Peripherie ? Die sollte sinnvollerweise auch in 
einen Stromsparzustand gehen. Und das waere dann der eigensichere 
Zustand. Also eben nicht - Heizung Ein, Vollgas oder Dergleichen.

Als Anfaenger, in einem Lernprojekt ... das Datenblatt genau in jedem 
Abschnitt lesen.

[Stefan F. (stefanus)]

Joggel E. schrieb:
> Daher sollten alle unbeschalteten Eingaenge auf Ausgang
> geschaltet werden.

Ich habe das mit dem Ardino Core 2.3.0 überprüft und musste feststellen, 
dass definierte Pegel an den Pins durch externe Beschaltung oder 
Programmierung überhaupt keinen Unterschied machen. Man kann sie alle 
unbeschaltet und als Eingang belassen. Offenbar sorgt entweder Arduino 
oder die Firmware-Teile von Espressif schon dafür, dass die Pins sauber 
still gelegt werden.

[Gustl B. (-gb-)]

So, ESP-12F funktioniert, aber:

Mit

ESP.deepSleep(zeit_ms);
delay(100);

funktioniert der Tiefschlaf nicht, also so wie bei meinem ESP-12S.
Mit der oben geposteten Funktion

nk_deep_sleep(zeit_us);

funktioniert der Tiefschlaf, aber zu beachten ist, dass die Funktion den 
Chip sofort schlafen legt. Wenn man also

Serial.println("Text");
nk_deep_sleep(zeit_us);

macht, dann wird die serielle Übertragung nicht vollständig 
durchgeführt, es kommen nur wenige Bits des ersten Bytes aus dem ESP und 
dann geht der schon schlafen. Das hielt ich beim ESP-12S für einen 
Fehler, jetzt am ESP-12F konnte ich das mit einem Delay dazwischen 
lösen. Also vielleicht geht Tiefschlaf mit

nk_deep_sleep(zeit_us);

auch beim ESP-12S. Habe ich jetzt noch nicht mit Delay getestet weil ich 
jetzt den ESP-12F bestückt habe.

Jedenfalls bin ich jetzt zufrieden.

Edit:
Nein, bin nicht zufrieden ... der zieht im Tiefschlaf fast 3 mA. Habe 
alle Pullups/Pulldowns auf >100 kOhm und der DCDC zieht ohne Last 400 
uA. Man man man ... mal gucken wo da der Strom fließt.

[Stefan F. (stefanus)]

Gustl B. schrieb:
> mit
> ESP.deepSleep(zeit_ms);
> funktioniert der Tiefschlaf nicht

Es sind Mikrosekunden, nicht Millisekunden. Den Fehler habe ich auch mal 
gemacht.

> Wenn man also
> Serial.println("Text");
> nk_deep_sleep(zeit_us);
> macht, dann wird die serielle Übertragung nicht vollständig
> durchgeführt

Logisch, die findet ja Asynchron aus einem Puffer heraus statt.

[Wi P. (wi_p)]

Hallo,
bei mir waren es einige ESP-01s die die Fehlstarts nach einem deep sleep 
hatten.
Nach einem Austausch des Flash-Bausteins traten keine Fehlstarts mehr 
auf.
Eingebaut waren: Noname T25S80 PQ19P1 (1M)
eingebaut wurden: Winbond 25Q32FVSIG  (4M)