Wie werden Bootloader und Firmware während der Produktion hochgeladen? [geschlossen]

Wenn es ein Produkt mit 5 MCUs (STM32303) und einer Haupt-CPU, die ein AM5718 ist, gäbe, wie würde der Bootloader auf jeden Chip hochgeladen?

Die gleiche Frage zur Firmware, wie würde die Firmware jeweils hochgeladen werden.

Würde es gemacht werden, bevor die Chips gelötet werden, gäbe es Pads auf der Leiterplatte für Sonden oder etwas anderes?

Mich interessiert nur, was in der Produktion passieren würde. Jedes Upgrade und Hochladen in der Zukunft würde über die Haupt-CPU über UART erfolgen

Alles das oben Genannte. Dies kommt einer doppelten Frage gefährlich nahe ...
Es gibt Auftragsfertigungsdienste, die die Geräteprogrammierung auf einer Charge von Chips durchführen können, bevor sie an Bord montiert werden. Es wird etwas kompliziert, weil jeder Chip ein Etikett mit der Versionsnummer haben sollte, und es sollte CRC oder eine ähnliche Prüfsumme geben, um das korrekte Firmware-Image zu verifizieren. Wenn sich die Firmware noch in der Entwicklung befindet oder möglicherweise aktualisiert werden muss und Speicherplatz verfügbar ist, ist es eine gute Idee, In-Circuit-Programmierung/Debugging, JTAG oder was auch immer das Gerät unterstützt, einzubeziehen.
Meine andere Frage bezog sich auf das Hochladen und Aktualisieren nach der Produktion wie im Betrieb. Mich würde interessieren, wie das in der Produktion umgesetzt wird.
Ist der Bootloader nicht dem STM32 inhärent?
Ich habe beide Fragen bearbeitet, meine vorherige Frage bezieht sich auf das Hochladen und Aktualisieren von Firmware, wenn das Produkt im Einsatz ist.

Antworten (2)

Ich habe an einem Produkt gearbeitet, das insgesamt sieben MCUs enthielt. Das von uns erstellte Design umfasste einen als RS485 implementierten zweiadrigen seriellen Bus, der per Multi-Drop zu jeder MCU-Platine ging und an den TxD- und RxD-Leitungen jedes UARTs der MCU endete.

Jede MCU wurde mit einem Bootloader programmiert, der auf RS485-Verkehr reagiert, der die Neuprogrammierung des "Anwendungscodes" FLASH der MCU unterstützen könnte. Der Eintritt in den Bootloader-Modus beim Einschalten wurde durch die analoge Spannung an einem bestimmten A/D-Eingang gesteuert. Bei normalem Systembetrieb würde der Pin in der Nähe von GND liegen. Etwas zwischen 2,5 und 4 V würde als "Kalibrierungsmodus" angesehen, während ein A/D-Wert über 4,5 V verwendet wurde, um den Bootloader-Modus zu signalisieren. Die A/D-Eingänge wurden über einen Spannungsteiler vorgespannt, so dass die extern angelegte Spannung auf der CAL/BOOT-Leitung extern über 20 V liegen musste, um in den Bootloader-Modus zu gelangen. Diese analoge Signalleitung wurde auch mit allen sieben MCUs verbunden.

Ein externer PC war mit einem speziellen Firmware-Update-Dienstprogramm ausgestattet, das das CAL/BOOT-Signal steuern und dann nacheinander über die RS485-Kommunikationsverbindung mit jeder MCU interagieren konnte, um die Software-Updates durchzuführen. Derselbe Computer wurde auch mit einem speziellen Kalibrierdienstprogramm eingerichtet, das dieselbe RS485-Kommunikationsverbindung verwendete, um die Kalibrierung und Leistungsdatenprotokollierung für das Produkt durchzuführen.

Beachten Sie, dass, da alle MCUs die gleiche Chipfamilie des Herstellers waren, in allen MCUs genau derselbe Bootloader-Code verwendet wurde. Die MCUs wurden mit den Bootloadern von einem Programmierservice beim Elektronikhändler vorinstalliert. Der Produktanwendungscode wurde beim anfänglichen Test auf Platinenebene in jede MCU geladen, um gegenüber dem Funktionstest auf Produktebene Zeit zu sparen. Jedes nachfolgende Update wurde am Paket auf Produktebene durchgeführt, ohne dass etwas geöffnet werden musste.

Ein letzter Kommentar ist, dass jede MCU in dieser Controller-Familie über eine SPI-Schnittstelle In-Circuit-programmiert werden könnte. Wir stellten Pads auf jeder Leiterplatte bereit, auf die über Pogo-Pins auf einer Platinenbefestigung zugegriffen werden konnte, die Zugang zu dieser Schnittstelle ermöglichte. Dadurch war es möglich, das fertige FLASH der MCU samt Bootloader neu zu programmieren. Sobald die sieben MCUs im vollständigen Produkt vorhanden waren, war dieser Zugriffsmodus nicht mehr verfügbar, da alle Elektronikplatinen vergossen waren.

In einem Projekt, an dem ich vor etwa einem Jahr gearbeitet habe, war die MCU ein USB 2.0-Host und daher gab es einen USB-Anschluss auf der Platine, um sie mit Peripheriegeräten zu verbinden. Obwohl der Prozessor auf USB 2.0 beschränkt war, habe ich einen USB 3.0-Anschluss mit fünf zusätzlichen Drähten entworfen. Ich habe dies verwendet, um die MCU über eine ICD-Schnittstelle (In-Circuit-Debugging) zu programmieren.

Die Schaltung war normalerweise deaktiviert (wenn also jemand ein echtes USB 3.0-Kabel einsteckte, würde kein Schaden angerichtet), wurde jedoch mit einer bestimmten Spannung über die GND_DRAIN-Leitung (Pin 7) der USB 3.0-Schnittstelle aktiviert (innerhalb der Kabel ist GND_DRAIN nicht verbunden zum Haupt-GND-Pin 4).

Durch Aktivieren der Schnittstelle (unter Verwendung eines Komparators) wurden vier Drähte der ICD-Schnittstelle über einen 4066-Quad-Analogschalter geschaltet. Der fünfte Draht (Masse) verwendet die normale GND-Leitung der USB 2.0-Schnittstelle.

Die Programmierung erfolgte in der Fabrik in China unter Verwendung spezieller, von mir entworfener Testvorrichtungen, die auch zum Testen auf Platinenebene verwendet wurden. Danach konnte die Platine immer noch über denselben Stecker umprogrammiert werden. Nachdem die Einheiten im Feld waren, konnten sie, da sie ein GSM-Modem in sich hatten, mit FOTA (Firmware Over the Air) aktualisiert werden.