Hallo,
ich habe hier 5 NodeMCU clones aus drei verschiedenen Quellen vor mir
liegen, die alle die gleichen Probleme haben. Beschriftet sind alle drei
auf der Rückseite mit: "wemos.cc LoLin new NodeMcu V3"
Ich kann alle sowohl mit der NodeMcu-Firmware als auch mit der aktuellen
MicroPython-Firmware flashen, die --verify-Option teilt mir auch mit,
dass alles OK ist.
Wrote 458752 bytes at 0x0 in 10.7 seconds (344.5 kbit/s)...
15
Leaving...
16
Verifying just-written flash...
17
Verifying 0x6f603 (456195) bytes @ 0x00000000 in flash against nodemcu-master-12-modules-2016-11-23-12-42-57-integer.bin...
18
-- verify OK (digest matched)
Jedoch kann ich auf keines der Boards zugreifen. Der Zustand hängt von
der verwendeten Firmware ab.
Nach einem Erase_Flash bleiben die Boards im Flash-Modus, der COM-Port
ist im OS (Linux und Windows) verfügbar.
Wenn danach Micropyton geflasht wird, meldet sich das Board nach einem
Reset nicht mehr zurück, es wird kein COM-Port mehr erkannt, es sei
denn, man drückt wieder Reset und den Flash-Button.
Wenn NodeMCU geflasht wird, meldet sich das Board wieder mit einem
COM-Port zurück, die blaue LED auf dem eigentlichen ESP-Modul beginnt
hektisch zu blinken. Auf dem COM-Port bekommt man mit den üblichen
Baudraten jedoch nur Müll zu sehen. Wenn man den COM-Port jedoch auf
unübliche 78440 8N1 setzt, bekommt man fortlaufend folgenden Output:
1
ets Jan 8 2013,rst cause:2, boot mode:(3,4)
2
3
load 0x40100000, len 24104, room 16
4
tail 8
5
chksum 0x83
6
load 0x3ffe8000, len 2264, room 0
7
tail 8
8
chksum 0xb2
9
load 0x3ffe88d8, len 8, room 0
10
tail 8
11
chksum 0x76
12
csum 0x76
13
rf_cal[0] !=0x05,is 0xFF
Recherchen zeigen, dass 78440 baud wohl die originale Boot-Datenrate
eines ESP8266 sind. Mein Eindruck ist, dass nach dem Flashen der Chip
in einem Endlos-Loop hängt.
Sobald ich die Firmware auf ein Witty-Modul oder einen Wemos D1 oder
einen Wemos D1 mini (alle auch mit CH360 Chipset) flashe, läuft die
Firmware ohne Probleme.
Das Resultat ist unabhängig von USB-Kabeln, Betriebssystem und Rechner
immer identisch. Die genannten Vergleichsboards funktionieren unter
allen getesteten Kombinationen.
Hat jemand irgendwelche weiteren Ideen?
Damit flashe ich meine NodeMCU DevKit v3 und hatte bislang noch nie
Probleme.
EDIT: Ah, das Problem liegt offenbar eher daran:
http://nodemcu.readthedocs.io/en/master/en/flash/#upgrading-firmware
Du musst die Datei esp_init_data_default.bin entpacken und flashen.
War bei mir bislang noch nie nötig, aber ich habe auch noch nie einen
erase_flash gemacht.
Danke für die Hinweise, hab das auch mal ausprobiert. Sowohl die
angegebene Firmware als auch das zusätzliche Flashen von
esp_init_data_default.bin helfen leider nicht.
Bislang habe ich auch nie ein esp_init_data_default.bin geflasht, und
prinzipiell das Flash gelöscht, da dies zum Flashen von Micropython
empfohlen wird und die ESPs haben alle getan.
esp32-Bastler schrieb:> Danke für die Hinweise, hab das auch mal ausprobiert. Sowohl die> angegebene Firmware als auch das zusätzliche Flashen von> esp_init_data_default.bin helfen leider nicht.>> Bislang habe ich auch nie ein esp_init_data_default.bin geflasht, und> prinzipiell das Flash gelöscht, da dies zum Flashen von Micropython> empfohlen wird und die ESPs haben alle getan.
Schade, dann fällt mir auf die Schnelle nix mehr ein, was Du probieren
könntest.
Schon merkwürdig, das Ganze. Wenn das jetzt nur bei einem Board
aufgetreten wäre, könnte man das ja noch mit einem defekten Board
erklären. Aber bei fünf Boards aus drei verschiedenen Quellen kann das
ja eigentlich nicht sein... Ich selbst habe auch gleich mehrere dieser
"LoLin v3"-Boards, die funktionieren allesamt einwandfrei.
Noch ein Ergebnis:
Ich kann die Boards mit der Arduino-IDE programmieren (Blink-Sketch,
basic Access-Point) und sehe die onboard LED (pin2) blinken, bzw. die
SSID des Accesspoints.
Allerdings ist in diesen Fällen der COM-Port auch nicht verfügbar.
Der Blink-Sketch läuft nicht, sobald ich im Blink-Loop eine serielle
Ausgabe versuche. In dem Fall passiert einfach nichts.
Bin etwas ratlos. Es scheint eher ein Problem mit dem Initialisieren der
seriellen Schnittstelle sein.
Meine Lolin V3 zeigen solch ein Verhalten nicht. Lassen sich ganz normal
mit aktueller NodeMCU-Firmware flashen. Das wird ja aber auch nur via
dem eingebauten USB-zu-Seriell-Wandler direkt an das ESP8266-Board
durchgereicht.
Hast du deine Firmware mal mit einem zB FTDI-USB-zu-Seriell-Wandler
direkt an einem ESP-12E/F probiert? Klingt ein wenig so, also ob die
Firmwares einen Hau weg haben.
Dirk K. schrieb:> Hast du deine Firmware mal mit einem zB FTDI-USB-zu-Seriell-Wandler> direkt an einem ESP-12E/F probiert? Klingt ein wenig so, also ob die> Firmwares einen Hau weg haben
Wie im Eingangspost geschrieben, laufen die verwendeten Firmwares auf
drei anderen Boards. An der Firmware an sich kann es daher nicht liegen:
> Sobald ich die Firmware auf ein Witty-Modul oder einen Wemos D1> oder einen Wemos D1 mini (alle auch mit CH360 Chipset) flashe,> läuft die Firmware ohne Probleme.
Nochmals Hallo,
ich bin am Überlegen, was eigentlich die Ursache sein kann, dass der
COM-Port während des Flashens zu 100% verfügbar ist, sobald die CPU
jedoch die Firmware startet verschwindet.
Wenn ich einen externen USB-Adapter verwende, ist der COM-Port sofort
verfügbar, sobald der Adapter in den USB-Port des Rechners gesteckt
wird. Es spielt dabei keine Rolle, ob TX und RX angeschlossen sind, und
welche Baudrate der angeschlossene Microcontroller verwendet, oder ob
die Pins überhaupt als Schnittstelle verwendet werden.
Hier meldet sich der CH340 nur dann am Computer an, wenn der
dahinterliegende Mikrocontroller im Flash-Mode ist, sobald der eine
Firmware startet, verschwindet der COM-Port. Sobald der Controlle in
den Reset geht (auch noch bevor der Flash-Mode startet!), erscheint die
serielle Schnittstelle.
Hallo,
ich habe scheinbar ein ähnliches Problem. Mein LoLin-Modul zeigt immer
nur
ets Jan 8 2013,rst cause:2, boot mode:(3,6)
load 0x40100000, len 27064, room 16
tail 8
chksum 0xef
load 0x00000000, len 0, room 0
tail 0
chksum 0xef
load 0x00000000, len 0, room 8
tail 0
chksum 0xef
csum 0xef
csum err
an und bootet auch nicht vernünftig hoch. Hast Du das Problem lösen
können?
Das Problem habe ich doch relativ schnell beheben können und wollte -
der Vollständigkeit halber - mein Ergebnis für die Nachwelt festhalten.
Im Internet findet man diverse angefangene Threads, aber eine direkte
Lösung habe ich nicht gefunden. Aus Zeitgründen konnte ich bisher noch
nicht die Ursache eingrenzen, insofern schreibe ich einfach, was ich
geändert habe:
1. Aus Bequemlichkeit habe ich zuerst die esptool.exe benutzt und im
Laufe der Fehlersuche dann auf das python-Script gewechselt.
2. Beim Aufstarten der AT-Kommando-Firmware habe ich folgendes entdeckt:
2nd boot version : 1.5
SPI Speed : 40MHz
SPI Mode : DIO
SPI Flash Size & Map: 32Mbit(512KB+512KB)
jump to run user1 @ 1000
Also habe ich dem python-Script noch den Parameter --flash_mode dio
mitgegeben.
3. Die Flash-Frequenz kann man ohne Probleme verringern, das habe ich
sicherheitshalber mit dem Parameter --flash_freq 20m getan.
Danach ist die selbstgebaute NodeMcu-Firmware sofort und ohne Fehler im
Bootloader aufgestartet.
Thread beobachten
Seitenaufteilung abschalten