Oft ist ein in ein Gerät eingebauter STM32 schlecht erreichbar, um ein
Firmware-Update durchzuführen.
Mit dem STM32-OTA-Flasher kann man einen angeschlossenen STM32 über WLAN
flashen. Damit vermeidet man nicht nur unnötigen Kabelsalat, sondern es
erübrigt sich auch, das Gerät, in dem der STM32 eingebaut ist, erst
komplett auseinanderzunehmen.
Außerdem kann man den STM32-OTA-Flasher verwenden, um Protokoll-Ausgaben
des STM32 über UART per telnet (über das WLAN) mitzulesen. Auch kann der
STM32 ferngesteuert resettet werden.
Das Flashen geschieht über eine Web-Oberfläche, welche der ESP8266
bereitstellt, siehe anhängende Bilder. Diese Oberfläche kann auch vom
Entwickler erweitert werden, um den STM32 über einen Browser zu steuern
oder Messwerte/Protokolle abzufragen.
Dabei kann der STM32-OTA-Flasher sowohl als WLAN-AP als auch als
Wifi-Client eines bestehenden WLAN-Netzwerkes arbeiten. Die Firmware des
ESP8266 kann natürlich auch über WLAN aktualisiert werden.
Verwendet wird ein NodeMCU für eine Handvoll Euro. Es kann aber auch ein
"nackter" ESP8266 ESP12-E oder ESP12-F verwendet werden - dann aber mit
etwas Hühnerfutter drumherum. Das NodeMCU-Board hat den Vorteil, dass
ein USB-UART-Umsetzer (i.d.R. ein CP2102) bereits On-Board ist, um den
ESP8266 einmalig zu flashen. Einfach ein USB-Kabel anschließen, einmal
den ESP8266 flashen und fertig. Danach geht alles über WLAN.
Das Flashen des am ESP8266 angeschlossenen STM32 geschieht mit folgenden
Schritten:
- Upload HEX-File
- Flash STM32
- Reset STM32
Optional kann man die hochgeladene HEX-Datei auch vorab vom ESP8266
prüfen lassen, ob die CRCs soweit korrekt sind - okay, das macht der
nachfolgende Flash-Vorgang sowieso, aber sicher ist sicher :-)
Ich habe das Projekt bei github eingestellt:
https://github.com/ukw100/STM32-OTA-Flasher
Die Arduino-Sources sind bereits komplett bei Github abgelegt. Für
Nicht-Arduino-User werde ich auch eine fertige BIN-Datei zur Verfügung
stellen, die einfach durch ein gängiges ESP-Flash-Programm einmalig
geladen werden muss.
Die Dokumentation wird in den nächsten Tagen nachgereicht, vermutlich am
kommenden Wochenende.
wow.... das werde ich in der Tat ausprobieren. Ich bin jetzt mal über
den Code "geflogen" und sehe, dass du den STM32 über den seriellen
Bootloader flasht (sehe ich doch richtig).
Ich bin sehr gespannt ob ich das so an's laufen bekomme.
Gruß, Ralph
Ralph S. schrieb:> Ich bin jetzt mal> über den Code "geflogen" und sehe, dass du den STM32 über den seriellen> Bootloader flasht (sehe ich doch richtig).
Ja, das ist korrekt.
> Ich bin sehr gespannt ob ich das so an's laufen bekomme.
Ja, ich muss endlich die Doku dafür fertigmachen. Ich versuchs in den
nächsten Tagen.
danke dass du deinen Code publiziert hast, genau danach habe ich gesucht.
Leider habe ich das Problem, dass scheinbar meine Hex Datei, die ich aus dem Arduino IDE Temp Verzeichnis heraus kopiere, den Fehler hat dass kein EOF enthalten sei.
Diese Files lassen sich nicht flashen...
Ich steh da komplett aufm Schlauch und weiß nicht weiter.
Hast du oder habt ihr mir vielleicht einen Tipp was ich falsch mache?
Leider habe ich das Problem, dass scheinbar meine Hex Datei, die ich aus
dem Arduino IDE Temp Verzeichnis heraus kopiere, den Fehler hat dass
kein EOF enthalten sei.
Erzeugst Du die Hex-Datei für den STM32 mittels Arduino? Kannst Du so eine hier mal anhängen?
ja, ich habe einen F429ZI Nucleo, den ich mit der Arduino IDE programmiere.
Normalerweise lade ich den Sketch direkt per eingebautem ST-Link hoch, jedoch möchte ich mit Hilfe deinem Projekt die Firmware auch per Web aktualisieren.
Im besten Fall beide, die vom ESP und die vom STM...
Die hex Datei wird beim kompilieren automatisch mit erstellt und liegt dann in dem besagten Temp Verzeichnis.
P.s. kann es sein dass du die Aktualisierung des ESP selbst nicht umgesetzt hast? Da kommt bei mir die Meldung dass er die Webseite "/update" nicht findet...
Die hex Datei wird beim kompilieren automatisch mit erstellt und liegt
dann in dem besagten Temp Verzeichnis.
Ist ein wirklich fettes Teil, mehr als 1MB...
Ich habe Deine Hex-Datei in den OTA-Flasher hochgeladen und anschließend einen Check (per Check-Button) drüberlaufen lassen. Die Datei wird als korrekt eingestuft, Ergebnis siehe Anhang. Allerdings muss ich sagen, dass ich mittlerweile eine weiter entwickelte Version benutze - auch nicht mehr das obsolete SPIFFS, sondern den Nachfolger davon.
Es kann durchaus sein, dass SPIFFS solche großen Dateien gar nicht unterstützt und deshalb u.a. der EOF-Datensatz in der Hex-Datei gar nicht mehr gespeichert werden konnte.
P.s. kann es sein dass du die Aktualisierung des ESP selbst nicht
umgesetzt hast? Da kommt bei mir die Meldung dass er die Webseite
"/update" nicht findet...
Auch das scheint ein Bug in der ca. 1 Jahr alten Version zu sein - ist schon seit längerer Zeit gefixt. Ich lade gleich mal die aktuelle Version hoch und melde mich dann nochmal.
Ich hatte es schon mit mehreren OTA Bespielen von Anderen versucht gehabt und bin fast verzweifelt.
Dein Projekt ist das erste was ich bei mir dann richtig ans Laufen bekommen habe.
Dein Code ist starker Tobak für mich, sehr schlank geschrieben aber für mich als Laie extrem schwer durch zu steigen.
Beim Update des ESP bekomme ich noch die gleiche Meldung im Webbrowser "not found: /update" nachdem ich den Update Button gedrückt habe.
Die bin Datei habe ich mit der Arduino IDE erzeugt, muss ich daran noch was ändern oder liegt es noch an einer anderen Stelle?
Ich mache die ersten 5 Schritte und nach dem Klick auf Update kommt binnen 2 Sekunden die Browsermeldung "not found: /update".
Es scheint dass die .bin Datei nicht hoch geladen wird und dadurch alle weiteren Schritte nicht abgearbeitet werden.
Ich habe die Datei firmware.bin benannt, zumindest habe ich das so im Sketch gelesen, leider ohne Erfolg.
Ich generiere die .bin Datei ebenfalls mit der Arduino IDE. Muss ich dort noch etwas besonderes machen?
Hallo,
Das Projekt gefällt mir sehr, nur dummerweise Flashe ich die meisten Projekte von mir über die swd / jtag pins. Die sio ist meistens nicht erreichbar, oder das ganze funktioniert nicht richtig (f407).
Hast du mal dran gedacht die anderen Schnittstellen einzubauen?
könntest du mir vielleicht deine .bin Datei exemplarisch zukommen lassen, so dass ich ausschließen kann dass ich beim Erstellen der Datei einen Fehler mache.
Zudem die Frage bzw. eine nähere Info:
Ich verwende eine Amica NodeMCU und bin mir nicht sicher ob diese Hardware kompatibel zu deinem Projekt ist bzw. ob ich hier noch irgendeinen Pegel manuell setzen muss (auf dem Board ist ein Button der Flash heißt)...
Zudem die Frage bzw. eine nähere Info:
Ich verwende eine Amica NodeMCU und bin mir nicht sicher ob diese
Hardware kompatibel zu deinem Projekt ist bzw. ob ich hier noch
irgendeinen Pegel manuell setzen muss (auf dem Board ist ein Button der
Flash heißt)...
Keine Ahnung. Ich dachte, NodeMCU heißt NodeMCU?
Der Flash-Button ist normal. Diesen aktiviert die Arduino-IDE beim Flashen über den RTS-Pin des UARTs. Wenn man ein Flash-Programm benutzt, welches zwar den UART benutzt aber den RTS-Pin nicht bedienen kann, muss man den Button selber drücken. Schlag mich nicht, wenns CTS und und nicht RTS ist. So genau weiß ich das auch nicht, was da die Arduino-IDE beim Flashen über den UART genau macht.
Hast du mal dran gedacht die anderen Schnittstellen einzubauen?
Der OTA-Flasher nutzt den internen Bootloader des STM32. Ein Flashen über SWD/JTAG ist eine komplett andere Geschichte. Ist das Flashen über SWD überhaupt irgendwo öffentlich dokumentiert?
Ich denke schon das das Protokoll bekannt ist. Denn irgendwie müssen die ganzen open-source Debugger es ja auch gefunden haben.
Wie gesagt für mich wäre es die beste Lösung weil ich selten an die sio komme, eigentlich nur ein Projekt von gut 27 und das ist dann auch noch ein f407 der Probleme mit dem bootloader hat.
Ist halt bei mir so gebaut und nicht unbedingt so bei den meisten anderen.
Das ist mit libopencm3 gebaut, aber nicht so modular das die Logik einfach in andere Projekte einzubauen ist. Ich habe mir mal einen Remote Debugger auf Basis von Mbed gebaut und die Quellen entsprechend geändert. Das war aber zuviel um das einfach in den main branch zu mergen.
Immerhin ist ein low level Teil als Treiber mit Funktionszeigern drin und libopencm3 wird nicht verwendet wenn es als 'Hosted' Version kompiliert wird, dann wird aber auch einiges andere umgestellt. Also ziemliche Fummelei.
Das lesen der Binärdatei übernimmt bei BMP der gdb, und der sendet dann die zu programmierenden Blöcke an den gdbserver in BMP. Das sind überschaubare Kommandos die eine eigene SW dann aufrufen muss. Komplizierter ist das Debuggen, da gibt es doch jede Menge Sonderbehandlung für die verschiedenen Cortex Kerne und Derivate.
Es gibt wie Anfangs geschrieben auch eine ESP32 Portierung, damit läuft BMP dann wireless. Hatte ich auch mal probiert und es funktionierte gut. BMP ist aber gerade aktuell bei V 1.9, der ESP Port benutzte noch eine V1.7.x. Auch das ist nicht im original Repo sondern in einem Fork, wie aktuell das jetzt ist weiß ich nicht.
https://github.com/Ebiroll/esp32_blackmagic
sieht nicht sehr lebendig aus.
Meinen Remote Debugger habe ich bisher nicht mehr gebraucht, ich habe an dem Remote Platz jetzt einen PC und arbeite von meinem Windows PC über VSCode remote auf einem Linux PC an dem die HW steckt. Das funktioniert absolut transparent und zuverlässig.
Zudem die Frage bzw. eine nähere Info:
Ich verwende eine Amica NodeMCU und bin mir nicht sicher ob diese
Hardware kompatibel zu deinem Projekt ist bzw. ob ich hier noch
irgendeinen Pegel manuell setzen muss (auf dem Board ist ein Button der
Flash heißt)...
Keine Ahnung. Ich dachte, NodeMCU heißt NodeMCU?
Der Flash-Button ist normal. Diesen aktiviert die Arduino-IDE beim
Flashen über den RTS-Pin des UARTs. Wenn man ein Flash-Programm benutzt,
welches zwar den UART benutzt aber den RTS-Pin nicht bedienen kann, muss
man den Button selber drücken. Schlag mich nicht, wenns CTS und und
nicht RTS ist. So genau weiß ich das auch nicht, was da die Arduino-IDE
beim Flashen über den UART genau macht.
Hallo Frank,
ich hab meinen Fehler gefunden...
Ich verwende an meinem Rechner den Opera Browser und scheinbar geht bei dem der Update des ESP mit deinem Sketch nicht.
Ich hab das aber leider erst fest gestellt als ich die Beispiele der Bibliothek getestet habe.
Beim Edge Browser funktioniert der Update wunderbar und auf anhieb.
Hallo, das ist genau das, was ich suche. Ich habe es zur Probe mit einem STM32F0Discovery Board versucht und mit einem F767ZINucleo. Leider bekomme ich bei beiden dasselbe Ergebnis. Sobald ich auf Flashen drücke, startet mein Programm sofort wieder (Blinkende LED) und danach erst kommt das:
Start Bootloader
Trying to enter bootloader mode...
Timeout
Trying to enter bootloader mode...
Timeout
Trying to enter bootloader mode...
Timeout
Trying to enter bootloader mode...
Timeout
End Bootloader
Ich habe Boot0, NRst, PC13 & PC14 angeklemmt und die ST-Link Jumper herausgezogen.
Ich habe es zur Probe mit einem STM32F0Discovery Board versucht und mit
einem F767ZINucleo.
....
Ich habe Boot0, NRst, PC13 & PC14 angeklemmt und die ST-Link Jumper
herausgezogen.
Wenn ich das richtig sehe, ist auf dem STM32F0Discovery Board ein STM32F051xx. Laut AN2606 von STM bietet dieser als Bootloader-Pins lediglich folgende Pins an:
USART 1: TX=PA9, RX=PA10
USART 2: TX=PA14, RX=PA15
Der Der STM32F767 bietet folgende Pins an:
USART 1: TX=PA9, RX=PA10
USART 2: Keine
USART 3: TX=PB10, RX=PB11
USART 3: TX=PC10, RX=PC11
Über PC13 und PC14 als mögliche USART-Bootloader-Pins finde ich da nichts.
Sobald ich auf Flashen drücke, startet mein Programm sofort wieder
Das sieht nach falsch angeschlossenem BOOT0-Pin aus. Oder ist der gar per Jumper auf dem Board auf einen fixen Pegel festgezurrt?
Uff mein Fehler, aber PA9 und PA10 habe ich zuvor auch schon getestet. Und jetzt nochmal (auch PA14 und PA15). Leider keine Änderung. Oder muss ich beim ST vorher bei UART 1 was einstellen?
"Default state of BOOT0 is 0. It can be set to 1 when a jumper is plugged on the pins 5-7 of CN11"
Ziehe mal bitte das Verbindungskabel BOOT0 -> ESP8266 ab und verbinde BOOT0 mit dem direkt daneben liegenden Pin5 (VDD) per Jumper. Wenn Du nun den Reset-Taster drückst, blinkt dann Deine LED noch?
Fall a: Blinkt nicht:
Der STM32 ist jetzt im Bootloader-Mode. Deine Verbindung BOOT0 -> ESP8266 ist aber nicht korrekt. Du könntest in diesem Zustand trotzdem mal im Webinterface des ESP das Flashen probieren. Wenn das dann erfolgreich durchläuft, wird Dein STM32 wg. dem Jumper zwar nicht booten, aber zumindest weisst Du dann, dass es nur noch an der Boot0-Verbindung liegt.
Zwei mögliche Unterfälle:
Kabelverbindung defekt
Falscher Pin am ESP8266
Fallba: Blinkt immer noch:
Du hast evtl. den falschen Pin als BOOT0 auf dem Nucleo ausgemacht.
Sonst wäre noch ein Foto Deines Test-Aufbaus sinnvoll.
Also mein 767 führt irgendwie keinen Code aus und hat wohl ein anderes Problem. Beim F0 ändert sich nichts, wenn ich BOOT0 auf High oder LOW setze. Kable habe ich schon mehrmals getauscht und die Verbindung ist von D2 -> Boot0.
Ja wir bleiben beim STM32F051. Ich habe nun ESP-RX -> PA14 verbunden und ESP-TX -> PA15. Auch ohne Erfolg. Boot0 auf high oder low macht keinen Unterschied. Wenn NRST auf high ist, blinkt es und auf low nicht mehr. Auf dauerhaft low gehts aber auch nicht.
Hier die notwendigen Verbindungen, nachzulesen in stm32flash.cpp:
1
STM32 NodeMCU
2
RST D2 GPIO 4
3
BOOT0 D1 GPIO 5
4
UART-TX D7 GPIO 13 RXD2
5
UART-RX D8 GPIO 15 TXD2
6
GND GND
Die Tabelle kennst Du wahrscheinlich bereits. Im Original fehlt GND <-> GND, aber das hielt ich für selbstverständlich. GND ist verbunden?
Beim F0 ändert sich nichts, wenn ich BOOT0 auf High oder LOW setze.
Dein Blink-Programm läuft nach Drücken von RESET in beiden Fällen weiter? Dann stimmt was mit Deinem BOOT0-Pin nicht. Zeig mal bitte auf einem Foto, wo Du ihn ausgemacht hast.
In UM1525 zum STM32F0-Discovery-Board finde ich auf Seite 19/41:
SB2 (BOOT0) - ON:
BOOT0 signal of the STM32F051R8T6 MCU is held low through a
510 Ohm pull-down resistor.
SB2 (BOOT0) - OFF:
BOOT0 signal of the STM32F051R8T6 MCU can be set high through a
10 KOhm pull-up resistor R27 to solder.
Sorry, das ist ja eine Brücke. Naja, der ESP8266 sollte den Pulldown von 512 Ohm auch bei kurzgeschlossener Brücke überwinden, d.h. auf High-Pegel ziehen können.
Irgendwas stimmt mit Deinem Boot0-Pin trotzdem nicht. Wenn man ihn manuell auf High zieht, darf der STM32F0 eigentlich nicht mehr starten.
Fehler gefunden, und zwar D1 und D2 vertauscht und RX und TX vom ESP genommen statt D7 und D8. Ich hatte zuerst einen anderen Code, bei dem das so war und habe es verwechselt. Sorry Leute, mein Fehler, aber danke für die Hilfe. So die Tage muss ich mal gucken, ob ich das auch auf mein custom Board mit U599 und einem Code der 2,4 MB groß ist über einen ESP8266 Pro mit 16MB läuft.
Wenn ich mir Dein Foto anschaue, benutzt Du am ESP8266 die Pins GPIO1 und GPIO3 für TX/RX. Das ist auf jeden Fall falsch.
Es muss aber GPIO13/15 benutzt werden - wie in meiner Tabelle angegeben. Ich sehe auch, dass das kein NODE-MCU ist, sondern ein ziemlich nackter ESP8266-12F (oder -E).
Ich habe das mal für das kleine ESP-Modul und den STM32F051 aufgemalt, siehe Anhang.
EDIT:
Du warst schneller, trotzdem ist das Bild nützlich hier :-)
Kann man eigentlich einstellen, dass ich im Browser nicht die ip eingeben muss, sondern einen festen Namen? Also wie z. B. bei einer fritzbox, da muss man ja auch nur Fritz.box eingeben. Das wäre auch eine nützliche Funktion.
Kann man eigentlich einstellen, dass ich im Browser nicht die ip
eingeben muss, sondern einen festen Namen?
Zur Zeit kann man das nicht einstellen, ich weiß aber, dass das mit dem ESP über WiFi.hostname() machbar ist. Ich schreibs mir mal auf die Todo-Liste.
Schau mal in der FritzBox nach, welchen Namen die Fritzbox für das verbundene Gerät im WLAN angibt. Es kann sogar sein, dass Du das Gerät dort umbenennen kannst. Der angezeigte Name sollte jedenfalls auch statt der IP im Browser gehen.
Ich persönlich ziehe mir die URL einfach in meine Lesezeichenliste und verpasse dann dem Lesezeichen einen passenden Namen.
Ich bleibe auch weiter dran. Muss noch eine i2C Verbindung zum stm32u5 aufbauen und eine i2S zum DAC für ein Internetradio. Deswegen auch der ESP32, da mir die Pins ausgegangen sind.
Ich habe es nicht mit LittleFS hinbekommen also habe ich SPIFFS eingebunden. So bekomme ich den Code kompiliert und komme auf die seite im Browser. Aber beim Hochladen von einer Datei oder beim Sprung auf die Flash-Seite hängt sich der ESP32 auf.
Es wird wohl noch am Dateisystem hängen.
Zum Flashen habe ich den Serial2 eingestellt. Pin 16,17
boot0 = 32
nRST = 33
Welche Leitungen muss ich eigentlich "mechanisch" aus einer Schaltung rausführen, um einen ESP32 oder esp8266 "per Draht" über z.b. einen USB /Serial Wandler zu programmieren?
Ich mach das zwar immer über ArduinoOTA (leider ohne debuggen zu können), aber wenn das auch nicht mehr funzt, ist die Schaltung hin. Blöde wenn z.b. ein Internetradio ESP32 Lösung in meiner (etwas älteren Stereoanlage) den Geist aufgibt. Dann wäre es schön, "händisch" wieder an das Programm zu kommen (wenn OTA) nicht mehr geht.
Herzliche Grüße
Manfred
Hey,
Ja so weit funktioniert es jetzt bei mir. Ich habe den code für ESP32 und STM32U5 angepasst. Es funktioniert auch OTA Updates für den ESP32. Außerdem startet der ESP32 im WLAN AP Mode und man kann über den Browser sein eigenes WLAN einstellen, was natürlich im EEPROM gespeichert wird. Eine Funktion zum Löschen des Speichers löscht auch nur die STM32 Dateien, die auf dem SPIFFS gelagert sind.
Ich verwende einen ESP32-WROOM-32UE-N16 der fest mit dem STM32U599 auf einem Custom Board sitzt. Bei der Arduino IDE habe ich TTGO T-Watch als Board ausgewählt, weil ich einen großen STM32 code hochladen muss. Es geht auch mit dem ESP32 Dev Module mit 4 MB, aber achte darauf das SPIFFS ausgewählt ist. Ich gebe noch meine Libraries dazu, weil ich da auch ein paar Sachen ändern musste.
Mein code macht nebenbei noch was anderes da ich es für die Arbeit anpassen musste, deswegen gib mir bitte eine Woche um den code zu allgemeinen und hilfreiche Kommentare einzufügen.
Achja wie man einen FTDI232 anklemmt um zu programieren Kann ich dir auch dazuschreiben(Nur programmieren mit flash_download_tool_3.9.5). Nutzt du ein Custom Board oder einen ESP32 Dev Board? Dieser hat ja schon einen fertigen USB-Port zum Debuggen und Programmieren. Und welchen STM32 soll geflasht werden?
network.png
(4,9 KB)
update.png
(3,8 KB)
upload.png
(7,3 KB)
flash.png
(11 KB)
