Announcement: there is an English version of this forum on Hallo liebes Forum, ich plane eine Anwendung, bei der lediglich UART zum flashen der Firmware eines MCU vorhanden ist. Das Ganze soll per UART Pins "over the air" gemacht werden. Ich habe einen Testaufbau mit einem ESP32 erstellt, welchen ich per UART erfolgreich flashen konnte. Jedoch habe ich zwei zusätzliche Pins (für Boot und Reset) benötigt, um nicht händisch auf die Buttons drücken zu müssen. In meiner Anwendung würden diese beiden zusätzlichen Pins jedoch nicht zur Verfügung stehen. Gibt es eine Lösung von der Stange, welche nicht darauf angewiesen ist, dass Signale für Boot und Reset abgefragt werden? Ich stelle es mir so vor, dass mein Host dem MCU per UART einen Befehl inkl. Firmware schickt. Der MCU sollte sich dann die Firmware in den Flash schreiben und sich neu starten. Bevorzugt würde ich den MCU gerne in Rust programmieren. Ich würde mich sehr über euren Input freuen :-)!
Bootloader endenn meist in einer Endlosschleife, die zum Auslösen des Watchdogs und damit zu einem Reset führen. Man muss halt dafür sorgen, dass der Bootloader angesprungen wird, der prüft, ob neue Software vorliegt, diese dann ggf. installiert.
Die RS232 hat noch RTS und DTR, mit denen sich zusätzlichen Pins ansteuern lassen.
Andreas B. schrieb: > Die RS232 hat noch RTS und DTR, mit denen sich zusätzlichen Pins > ansteuern lassen. Alex schrieb: > In meiner Anwendung würden diese beiden zusätzlichen Pins jedoch nicht > zur Verfügung stehen. Was der TO wohl damit meint? RTS und DTR verwendet man bei UARTs inzwischen nur noch, wenn die per USB-Controller ("FTDIs") aufgebaut wird. I.d.R. verwendet man doch nur noch RXD und TXD.
Sind denn ESP32 und UART fest vorgeschrieben? Übliche ARMe können über SWD programmiert werden, das sind auch nur drei Pins (und einer davon ist Masse). Ist das eine Übung in freiwilliger Selbstbeschränkung?
Du musst den Code zum Updaten des Flash in deine eigene Firmware integrieren, damit das im laufenden Betrieb möglich wird. Dazu wird der Flash partitioniert. Eine Partition enthält das alte laufende Programm. Die andee wird mit dem neuen Programm befüllt. Danach konfiguriert man den ESP so, dass er die neue Partition booted. Siehe https://docs.espressif.com/projects/esp-idf/en/stable/esp32/api-guides/bootloader.html
Alex schrieb: > Bevorzugt würde ich den MCU gerne in Rust programmieren. Mache es dir nicht unnötig schwer, nutze das IDF des Herstellers.
Alex schrieb: > Hallo liebes Forum, > > ich plane eine Anwendung, bei der lediglich UART zum flashen der > Firmware eines MCU vorhanden ist. Das Ganze soll per UART Pins "over the > air" gemacht werden. Was möchtest du denn mit deinem ESP32 nun wirklich machen? a) mittels USART (Bootloader) flashen b) mittels over the air (OTA)
Rahul D. schrieb: > Was der TO wohl damit meint? Pins von der ESP Seite wäre merkwürdig, die kann man schwer abschneiden. Ich ging daher davon aus das er keine Taster hat. Aber wer weiss ..... Rahul D. schrieb: > RTS und DTR verwendet man bei UARTs inzwischen nur noch, wenn die per > USB-Controller ("FTDIs") aufgebaut wird. > I.d.R. verwendet man doch nur noch RXD und TXD. Nur dann wenn man DTR und RTS nicht braucht. Ich nutze die auch, um LPCs per Uart zu flashen. Das spart Tastendrücken.
:
Bearbeitet durch User
Andreas B. schrieb: > Pins von der ESP Seite wäre merkwürdig, die kann man schwer abschneiden. > Ich ging daher davon aus das er keine Taster hat. > Aber wer weiss ..... Oder man verwendet sie für was anderes?! > Nur dann wenn man DTR und RTS nicht braucht. Ich nutze die auch, um LPCs > per Uart zu flashen. Das spart Tastendrücken. Man spart noch mehr, wenn man sie nicht verwendet: Kabel, Leitungen. Unsere Software wird i.d.R. durch einen Befehl dazu gebracht, den Controller neu zu starten. Dadurch wird der Bootloader als erstes ausgeführt, der dann prüft, ob ein Firmeware-Update durchgeführt werden soll (Das kann auch per USB-Stick erfolgen). Oder man führt einen Kaltstart durch... Die DTR/RTS-Version zum Programmieren ist doch nur ein Hilfskonstrukt, um nicht die Tasten drücken zu müssen.
Rahul D. schrieb: > Unsere Software wird i.d.R. durch einen Befehl dazu gebracht, und wie loest du diesen Befehl aus? Per Taster? ;-) Viele Wege fuehren nach Rom.
Andreas B. schrieb: > Die RS232 hat noch RTS und DTR, mit denen sich zusätzlichen Pins > ansteuern lassen. RTS und DTR OTA dürften ein kleines Problem sein. Alex schrieb: > Das Ganze soll per UART Pins "over the air" gemacht werden.
Rainer W. schrieb: > TS und DTR OTA dürften ein kleines Problem sein. > > Alex schrieb: >> Das Ganze soll per UART Pins "over the air" gemacht werden. dazu braucht man kein Uart. Daher: Veit D. schrieb: > Was möchtest du denn mit deinem ESP32 nun wirklich machen? > a) mittels USART (Bootloader) flashen > b) mittels over the air (OTA)
Andreas B. schrieb: > und wie loest du diesen Befehl aus? Per Taster? ;-) Durch den Host, der sich mit dem Modul unterhält?
Wow, schon mal vielen Dank vorab für die zahlreichen Antworten :-)! Harald K. schrieb: > Sind denn ESP32 und UART fest vorgeschrieben? > > Übliche ARMe können über SWD programmiert werden, das sind auch nur drei > Pins (und einer davon ist Masse). > > Ist das eine Übung in freiwilliger Selbstbeschränkung? Nein, der Host ist auf einem industriellen Carrierboard, welches nur wenige Schnittstellen bereit stellt. Es muss nicht unbedingt ein ESP32 sein. Andreas B. schrieb: > Die RS232 hat noch RTS und DTR, mit denen sich zusätzlichen Pins > ansteuern lassen. Tatsächlich bietet das Carrierboard RS232. Hat man diese Pins grundsätzlich bei RS232? Sherlock 🕵🏽♂️ schrieb: > Alex schrieb: >> Bevorzugt würde ich den MCU gerne in Rust programmieren. > > Mache es dir nicht unnötig schwer, nutze das IDF des Herstellers. Rust ist kein Muss. Das Projekt bietet sich an, um mit Rust erste Erfahrungen zu sammeln. Veit D. schrieb: > Alex schrieb: >> Hallo liebes Forum, >> >> ich plane eine Anwendung, bei der lediglich UART zum flashen der >> Firmware eines MCU vorhanden ist. Das Ganze soll per UART Pins "over the >> air" gemacht werden. > > Was möchtest du denn mit deinem ESP32 nun wirklich machen? > a) mittels USART (Bootloader) flashen > b) mittels over the air (OTA) Ich möchte (a) mittels UART den Bootloader flashen. Es soll Remote passieren (also ohne, dass händisch Buttons gedrückt werden). Deswegen habe ich "over the air" geschrieben :-). Es geht um eine Lösung, welche lediglich mit TX,RX und GND auskommt, weil der Host (welcher den MCU flasht) nur diese Pins bietet.
:
Bearbeitet durch User
Alex schrieb: > Das Projekt bietet sich an, um mit Rust erste Erfahrungen zu sammeln. Nee, dafür bietet sich ein PC an. Der Hersteller des ESP32 bietet nur sein IDF unc einen Arduino Core an. Nichts für Rust. Inoffizielle Ports "kleiner" Hobbyautoren kommen nur selten weit.
:
Bearbeitet durch User
Rahul D. schrieb: > Andreas B. schrieb: >> Pins von der ESP Seite wäre merkwürdig, die kann man schwer abschneiden. >> Ich ging daher davon aus das er keine Taster hat. >> Aber wer weiss ..... > Oder man verwendet sie für was anderes?! > >> Nur dann wenn man DTR und RTS nicht braucht. Ich nutze die auch, um LPCs >> per Uart zu flashen. Das spart Tastendrücken. > > Man spart noch mehr, wenn man sie nicht verwendet: Kabel, Leitungen. > > Unsere Software wird i.d.R. durch einen Befehl dazu gebracht, den > Controller neu zu starten. Dadurch wird der Bootloader als erstes > ausgeführt, der dann prüft, ob ein Firmeware-Update durchgeführt werden > soll (Das kann auch per USB-Stick erfolgen). > Oder man führt einen Kaltstart durch... > > Die DTR/RTS-Version zum Programmieren ist doch nur ein Hilfskonstrukt, > um nicht die Tasten drücken zu müssen. Das hört sich genau nach dem an, was ich suche :-). Welchen MCU benutzt du denn dafür? Wie hast du das Laden der Firmware realisiert?
Angehängte Dateien:
-
boot-ohne-taster.png
4,6 KB
Alex schrieb: > Ich möchte (a) mittels UART den Bootloader flashen. Auch bei einem fabrikneuen Chip? Dazu muss erstmal ein Bootloader laufen... Deshalb haben manche(!) STM32 einen UART-Bootloader im ROM, der bei leerem Flash automatisch (ohne BOOT-Pin) startet. In der AN2606 gibt es für jeden Typ ein Flussdiagramm für den Start des Bootloaders und in der Tabelle 2 steht dann "both banks do not contain valid code" oder "main flash empty" oder so. "leeres Flash" ist übertrieben. Es wird nur geprüft, ob in Adresse 0 (aka 0x08000000) ein gültiger Wert für den Stack Pointer steht. Wenn man die Adresse nicht flasht, startet immer der Bootloader. Dann muss das Carrierboard einen GO-Befehl senden, damit die Anwendung startet. So wären auch Updates ohne Taster und DTR/RTS möglich. Man kann diese Signale auch seriell übertragen. Dazu muss eine Hardware ein Break erkennen und BOOT und RESET leicht versetzt aktivieren. Ich benutze dazu einen 74HC4060 und einen Transistor. Ja, das kostet 6 Bauteile, spart aber einen eigenen Bootloader und die Taster und funktioniert auch mit RS-422.
Hallo, @ TO: Du musst einmal ein Programm inkl. OTA und den Bootloader flashen. Einmal! Danach verbauste den ESP irgendwo und kannst ab dem Zeitpunkt mittels OTA dein Programm jederzeit aktualisieren.
Alex schrieb: > Ich habe einen Testaufbau mit einem ESP32 erstellt, welchen ich per UART > erfolgreich flashen konnte. Jedoch habe ich zwei zusätzliche Pins (für > Boot und Reset) benötigt, um nicht händisch auf die Buttons drücken zu > müssen. Es ist nicht ganz klar, was Du flashst. Ein unbekanntes Board (MCU, A), dass 2 Eingänge/Buttons hat. Dein "Host" wäre dann (B). Du müsstest Dein MCU (A) genauer beschreiben. Ein µC hat entweder Platz für 2 Applikationen (um eine neu zu laden während es läuft) oder einen Bootloader, der die Applikation löscht und dann nix anderes kann als eine neue Applikation zu empfangen. Wenn es 2 Knöpfe zu drücken gibt, gibt es dazu viele Möglichkeiten/Alternativen. Ein Uart-Befehl, eine Power-ON-Verzögerung, 2 Ausgänge an (B), ein absichtlicher Fehler, ein Timeout, ... . Dazu müsstest Du (A) genauer beschreiben (verbal, link, Typenbezeichnung).
Rahul D. schrieb: > Bootloader endenn meist in einer Endlosschleife, die zum Auslösen des > Watchdogs und damit zu einem Reset führen. Nö. Das tun üblicherweise nur die Bootloader von MCUs, die keine Möglichkeit bieten, per Software einen vollständigen HW-Reset auszulösen. Die Classic-AVR8 solche MCUs. Zwar recht verbreitet, aber nicht so verbreitet, dass sie in der Lage gewesen wären, in dieser Hinsicht einen Standard vorzugeben... > Man muss halt dafür sorgen, dass der Bootloader angesprungen wird, der > prüft, ob neue Software vorliegt, diese dann ggf. installiert. ??? Bei dem Mechanismus mit dem Reset-Workaround geht es im Bootloader vor allem darum, zu einem frühen Zeitpunkt zu entscheiden, ob einfach die bereits installierte Firmware angesprungen wird (ohne erneuten Reset). Alles andere würde nämlich unweigerlich zu eine Endlos-Bootschleife führen...
Rahul D. schrieb: > Andreas B. schrieb: >> und wie loest du diesen Befehl aus? Per Taster? ;-) > > Durch den Host, der sich mit dem Modul unterhält? soweit ja logisch, aber auch dort muss es ja irgendwie ausgeloest werden Alex schrieb: > Andreas B. schrieb: >> Die RS232 hat noch RTS und DTR, mit denen sich zusätzlichen Pins >> ansteuern lassen. > > Tatsächlich bietet das Carrierboard RS232. Hat man diese Pins > grundsätzlich bei RS232? Nein, nur wenn es ordentlich implementiert wird. Aber ich vermute es wird wohl eher darauf hinauslaufen: Veit D. schrieb: > @ TO: > Du musst einmal ein Programm inkl. OTA und den Bootloader flashen. > Einmal! Danach verbauste den ESP irgendwo und kannst ab dem Zeitpunkt > mittels OTA dein Programm jederzeit aktualisieren.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.