ESP-WROOM-02U - Flashen funktioniert nicht

[Mo (Gast)]

Hi da.

Ich habe ein ESP-WROOM-02U auf einem Board sitzen und würde diesen gerne 
einmal flashen.
Automatisches Flashen tat nicht, daher dann BootPin hart auf GND gezogen 
und Reset betätigt. Nun über die Uart0 und Platformio ein leeres 
Programm versucht hoch zu laden.

Laut LogicAnalyzer sendet der PC auch ein paar Bytes rüber, was das 
Modul aber scheinbar nicht sonderlich interessiert.
Alle 150ms wiederholt der PC die Bytes dann wieder.

Spannungsversorgung ist da und auch anständig gepuffert. 3v3 kommen 
direkt vom Netzteil. Enable ist oben.

Nach dem Reset sendet er mit mit irgendwas um die 88kbaud folgenden 
Hallo-Text:
ets Jan 8 2013,rst cause:2, boot mode:(5,6) waiting for host

Danach versucht das Programm dann mit 115200baud hoch zu laden.

Folgende Chars wiederholen sich dann stetig:

'192'
'0'
'8'
$
'0'
'0'
'0'
'0'
'0'
'7'
'7'
'18'
' '
U
U
U
U
U
U...

Hat jemand eine Idee, was es noch sein kann?
Versuche morgen mal eine andere PCB mit neuem Modul - Evtl. hat das hier 
ja nen Knax...

Grüße, Mo

[Matthias L. (lindner8712)]

Hallo,

So wird es nicht funktionieren... Welches Board hast du denn? Gibt ja ca 
1500 verschiedene.

Normal wird der autoprog so eingeleitet:

RESET LOW
BOOT LOW
RESET HIGH
->UPLOAD KANN STARTEN

Der ESP wird dadurch in den Bootloader gezogen und kann dann 
programmiert werden..

Grüße

[Stefan F. (Gast)]

Matthias hat es korrekt beschrieben.

Hier hast du eine Beschreibung, wie der Upload beim ESP8266 generell 
funktioniert: http://stefanfrings.de/esp8266/index.html#fwupdate

[Helmut -. (dc3yc)]

Bootmode (5,6) kann nicht gehen. Deine GPIOs 0, 2 und 15 haben falschen 
Pegel. Mode (3,6) wäre richtiger. Der Pegel von GPIO2 muss H sein und 
der von 15 Low.

[Mo (Gast)]

Hi!
Danke erst einmal für Eure Antworten.
<Aaaaaaach Du sch... - Es tut!>

Matthias L. schrieb:
> So wird es nicht funktionieren... Welches Board hast du denn? Gibt ja ca
> 1500 verschiedene.>
> Normal wird der autoprog so eingeleitet:
> RESET LOW
> BOOT LOW
> RESET HIGH
> ->UPLOAD KANN STARTEN
Ich habe kein "Board" - Das Modul sitzt wie geschrieben auf meiner 
eigenen Platine. Genau wie Du beschreibst, hatte ich es eingeleitet...

Stefan ⛄ F. schrieb:
> Hier hast du eine Beschreibung, wie der Upload beim ESP8266 generell
> funktioniert: http://stefanfrings.de/esp8266/index.html#fwupdate
Hi Stefan.
Erst mal Glückwunsch zu Deiner wirklich informativen Homepage!
Da war ich des Öfteren schon vorbei gekommen :)
Du ziehst GPIO15 auf GND? Öhm okay...
Direkt mal getestet und voila. Wird dadurch das Senden der U0 
deaktiviert wegen dem RTS auf dem Pin?
Vielen vielen Dank! Ich habe in alle Richtungen gesucht - Das aber nie 
irgendwo gelesen. Wahrscheinlich aber eher überlesen.

Helmut -. schrieb:
> Bootmode (5,6) kann nicht gehen. Deine GPIOs 0, 2 und 15 haben
> falschen
> Pegel. Mode (3,6) wäre richtiger. Der Pegel von GPIO2 muss H sein und
> der von 15 Low.
Hallo Helmut.
Volltreffer - Der GPIO15 wars.
Hast Du eine Aufschlüsselung was die Codes bedeuten?
Würde ich gerne in meine Unterlagen packen.

So, dann kanns ja nun endlich weiter gehen :)

Schönen Abend noch!

[Stefan F. (Gast)]

Mo schrieb:
> Wird dadurch das Senden der U0
> deaktiviert wegen dem RTS auf dem Pin?

Ich verstehe die Frage nicht. Der ESP8266 kennt kein RTS Signal. Was ist 
U0? Wer sendet wohin?

Mo schrieb:
> Hast Du eine Aufschlüsselung was die Codes bedeuten?

https://www.espressif.com/sites/default/files/documentation/esp8266_reset_causes_and_common_fatal_exception_causes_en.pdf

[Mo (Gast)]

Stefan ⛄ F. schrieb:
> Mo schrieb:
>> Wird dadurch das Senden der U0
>> deaktiviert wegen dem RTS auf dem Pin?
>
> Ich verstehe die Frage nicht. Der ESP8266 kennt kein RTS Signal. Was ist
> U0? Wer sendet wohin?
Scheinbar schon so, siehe Anhang.
Mein Firmware-Upload scheiterte ja scheinbar daran, dass das Feedback zu 
den einzelnen Datenabschnitten vom Controller nicht am PC an kam.
Daher gehe ich einmal davon aus, dass der RTS vom UART0, den ich eben 
nicht beschaltet hatte, daran schuld war.

> Mo schrieb:
>> Hast Du eine Aufschlüsselung was die Codes bedeuten?
> 
https://www.espressif.com/sites/default/files/documentation/esp8266_reset_causes_and_common_fatal_exception_causes_en.pdf
Jau, genial.
Das kommt in die Doku.

[Stefan F. (Gast)]

Mo schrieb:
> Daher gehe ich einmal davon aus, dass der RTS vom UART0, den ich eben
> nicht beschaltet hatte, daran schuld war.

Ach so, jetzt habe ich es verstanden. Eigentlich bestimmt die Software, 
die den virtuellen COM-Port öffnet, ob sie diese Hardware-Handshake 
Leitungen benutzen will. Wenn nicht, muss man sie auch nicht beschalten. 
Normalerweise.

[Mo (Gast)]

Oups, Anhang dann doch nicht hinzu gefügt.

Naja, jetzt läuft er ja :)

[Stefan F. (Gast)]

Ich dachte du meinst den RTS Pin von deinem USB-UART Adapter am PC.

In deinem Fall hat der Pin nicht die RTS Funktion, sondern er steuert 
den Bootloader für irgendwas, was nicht zu deiner Anwendung passt. Der 
Bootloader nutzt kein Hardware Handshake.

[Mo (Gast)]

Stefan ⛄ F. schrieb:
> ...er steuert
> den Bootloader für irgendwas, was nicht zu deiner Anwendung passt.
Das verstehe ich nun nicht.
An der Stelle läuft meine Anwendung noch nicht, denn ich bin am Flashen.
Ich glaube wir reden aneinander vorbei :)
Ist aber ja auch funktionierend nun, wenn der Pin runter gezogen ist.

Schönen Tag noch!

[Stefan F. (Gast)]

Mo schrieb:
> An der Stelle läuft meine Anwendung noch nicht, denn ich bin am Flashen.

Der Bootloader ist fest installiert und nicht veränderbar. Bei einem 
Neustart wird immer zuerst der Bootloader gestartet. Abhängig vom Pegel 
an einigen Pins lädt er das eigentliche Programm von Unterschiedlichen 
Quellen oder geht in den Firmware-Download Modus.

[Helmut -. (dc3yc)]

Mo schrieb:
> Hast Du eine Aufschlüsselung was die Codes bedeuten?

Dies hier ist in meinem Ordner abgelegt:
https://riktronics.wordpress.com/2017/10/02/esp8266-error-messages-and-exceptions-explained/