Wählen Sie Ihre Cookie-Einstellungen aus

Wir verwenden essentielle Cookies und ähnliche Tools, die für die Bereitstellung unserer Website und Services erforderlich sind. Wir verwenden Performance-Cookies, um anonyme Statistiken zu sammeln, damit wir verstehen können, wie Kunden unsere Website nutzen, und Verbesserungen vornehmen können. Essentielle Cookies können nicht deaktiviert werden, aber Sie können auf „Anpassen“ oder „Ablehnen“ klicken, um Performance-Cookies abzulehnen.

Wenn Sie damit einverstanden sind, verwenden AWS und zugelassene Drittanbieter auch Cookies, um nützliche Features der Website bereitzustellen, Ihre Präferenzen zu speichern und relevante Inhalte, einschließlich relevanter Werbung, anzuzeigen. Um alle nicht notwendigen Cookies zu akzeptieren oder abzulehnen, klicken Sie auf „Akzeptieren“ oder „Ablehnen“. Um detailliertere Entscheidungen zu treffen, klicken Sie auf „Anpassen“.

Demo-Bootloader für die Microchip Curiosity PIC32MZEF - Kostenlos RTOS

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Demo-Bootloader für die Microchip Curiosity PIC32MZEF

Wichtig

Diese Demo wird im Amazon-FreeRTOS-Repository gehostet, das veraltet ist. Wir empfehlen, dass Sie hier beginnen, wenn Sie ein neues Projekt erstellen. Wenn Sie bereits ein vorhandenes FreeRTOS-Projekt haben, das auf dem inzwischen veralteten Amazon-FreeRTOS-Repository basiert, finden Sie weitere Informationen unter. Leitfaden zur Migration des kostenlosen RTOS Github-Repositorys von Amazon

Anmerkung

In Absprache mit Microchip entfernen wir den Curiosity PIC32MZEF (DM320104) aus dem Hauptzweig des FreeRTOS Reference Integration-Repositorys und werden ihn nicht mehr in neuen Releases anbieten. Microchip hat eine offizielle Mitteilung veröffentlicht, dass der PIC32MZEF (DM320104) nicht mehr für neue Designs empfohlen wird. Auf die PIC32MZEF-Projekte und den Quellcode kann weiterhin über die Tags der vorherigen Version zugegriffen werden. Microchip empfiehlt Kunden, das Curiosity PIC32MZ-EF-2.0-Entwicklungsboard (DM320209) für neue Designs zu verwenden. Die PIC32mzV1-Plattform befindet sich immer noch in Version 202012.00 des FreeRTOS Reference Integration-Repositorys. Die Plattform wird jedoch von v202107.00 der FreeRTOS Reference nicht mehr unterstützt.

Dieser Demo-Bootloader implementiert die Überprüfung der Firmware-Version, die Verifizierung der kryptografischenSignatur und einen Selbsttest der Anwendung. Diese Funktionen unterstützen Firmware-Updates over-the-air (OTA) für FreeRTOS.

Die Firmware-Verifizierung beinhaltet die Verifizierung der Authentizität und die Integrität der neuen Firmware, die Over The Air empfangen wurde. Vor einem Neustart verifiziert der Bootloader die kryptografische Signatur der Anwendung. Die Demo verwendet einen Elliptic Curve Digital Signature Algorithm (ECDSA) über SHA256. Die bereitgestellten Dienstprogrammen können zur Erstellung einer signierten Anwendung verwendet werden, die auf dem Gerät geflasht werden kann.

Der Bootloader unterstützt die folgenden für OTA erforderlichen Funktionen:

  • Behält Anwendungsabbilder auf dem Gerät und wechselt zwischen ihnen.

  • Ermöglicht die Ausführung eines Selbsttests eines empfangenen OTA-Images und ein Rollback bei Fehlern.

  • Prüft die Signatur und die Version des OTA-Aktualisierungsabbilds.

Anmerkung

Folgen Sie den Schritten unter, um die FreeRTOS-Demos einzurichten und auszuführen. Jetzt kostenlos durchstarten RTOS

Bootloader-Zustände

Der Bootloader-Prozess wird in der folgenden Zustands-Engine gezeigt.

Starten Sie die Bootloader-Zustandsmaschine mit den Status Initialisierung, Überprüfung, Ausführung und Fehler mit der Option Fehler benachrichtigen.

Die folgende Tabelle beschreibt die Bootloader-Zustände.

Bootloader-Zustand Beschreibung

Initialisierung

Der Bootloader befindet sich im Initialisierungszustand.

Verifizierung

Der Bootloader verifiziert die auf dem Gerät vorhandenen Abbilder.

Abbildung ausführen

Der Bootloader startet das ausgewählte Abbild.

Standard ausführen

Der Bootloader startet das Standard-Abbild.

Fehler

Der Bootloader befindet sich im Fehlerzustand.

In der obigen Abbildung werden sowohl Execute Image als auch Execute Default als Execution-Zustand angezeigt.

Bootloader-Ausführungszustand

Der Bootloader befindet sich im Execution-Zustand und ist zum Starten des ausgewählten verifizierten Abbilds bereit. Wenn sich das zu startende Abbild in der oberen Bank befindet, werden die Banken ausgetauscht, bevor das Abbild ausgeführt wird, da die Anwendung immer für die untere Bank erstellt wird.

Bootloader-Standard-Ausführungszustand

Wenn die Konfigurationsoption zum Starten des Standard-Abbilds aktiviert ist, startet der Bootloader die Anwendung von einer Standard-Ausführungsadresse. Diese Option muss außer beim Debuggen deaktiviert sein.

Bootloader-Fehlerzustand

Der Bootloader befindet sich in einem Fehlerzustand und es sind keine gültigen Abbilder auf dem Gerät vorhanden. Der Bootloader muss den Benutzer benachrichtigen. Die Standardimplementierung sendet eine Protokollnachricht an die Konsole und löst für eine unbestimmte Zeit ein schnelles Blinken der LED auf der Tafel aus.

Flash-Gerät

Die Microchip Curiosity PIC32MZEF-Plattform enthält einen internen Programm-Flash von zwei Megabyte (MB), der in zwei Banken aufgeteilt ist. Sie unterstützt den Austausch von Memory Maps zwischen diesen beiden Banken und Live-Updates. Der Demo-Bootloader wird in einer separaten niedrigeren Boot-Flash-Region programmiert.

Das Speicherlayoutdiagramm zeigt die Regionen „Lower Boot Flash“, „Lower Program Flash“ von 1 MB und „Upper Program Flash“ von 2 MB, die jeweils Bootloader, Application Bank 0 und Application Bank 1 zugeordnet sind.

Struktur des Anwendungsabbilds

OTA-Bildstruktur mit Kopfzeile, Deskriptor, Anwendungsbinärdatei (signiert vom Signierdienst) und Trailer-Abschnitten mit Feldern wie magischem Code, Sequenznummern, Start- und Endadressen, Ausführungsadresse und Hardware-ID.

Das Diagramm zeigt die Hauptkomponenten des Anwendungsabbilds, die in jeder Bank des Geräts gespeichert sind.

Komponente Größe (in Bytes)

Abbild-Header

8 Bytes

Abbild-Deskriptor

24 Bytes

Binärcode der Anwendung

< 1 MB - (324)

Trailer

292 Bytes

Abbild-Header

Die Anwendungsabbilder auf dem Gerät müssen mit einem Header beginnen, der aus einem magischen Code und Abbild-Flags besteht.

Header-Feld Größe (in Bytes)

Magischer Code

7 Bytes

Abbild-Flags

1 Byte

Magischer Code

Das Abbild auf dem Flash-Gerät muss mit einem magischen Code beginnen. Der standardmäßige magische Code lautet @AFRTOS. Der Bootloader prüft, ob ein gültiger magischer Code vorhanden ist, bevor das Abbild gestartet wird. Dies ist der erste Schritt der Verifizierung.

Abbild-Flags

Die Abbild-Flags werden verwendet, um den Status der Abbilder der Anwendung zu speichern. Die Flags werden im OTA-Prozess verwendet. Die Abbild-Flags beider Banken bestimmen den Zustand des Geräts. Wenn das ausführende Abbild als schwebender Commit markiert ist, bedeutet dies, dass sich das Gerät in der OTA-Selbsttest-Phase befindet. Selbst wenn Abbilder auf den Geräten als gültig markiert sind, durchlaufen sie bei jedem Start dieselben Verifizierungsschritte. Wenn ein Abbild als neu markiert ist, wird es vom Bootloader als schwebender Commit markiert und nach der Überprüfung zum Selbsttest gestartet. Der Bootloader initialisiert und startet außerdem den Watchdog-Timer, sodass das Gerät einen Neustart durchführt, wenn das neue OTA-Abbild den Selbsttest nicht besteht. Der Bootloader weist dann die Abbildung durch Löschen dieser zurück und führt das vorherige gültige Abbild aus.

Das Gerät kann nur ein gültiges Abbild haben. Das andere Abbild kann ein neues OTA-Abbild oder ein schwebender Commit (Selbsttest) sein. Nach einem erfolgreichen OTA-Update wird das alte Abbild vom Gerät gelöscht.

Status Wert Beschreibung

Neues Abbild

0xFF

Das Abbild der Anwendung ist neu und wurde noch nie ausgeführt.

Schwebender Commit

0xFE

Das Abbild der Anwendung ist für die Testausführung gekennzeichnet.

Valid

0xFC

Das Abbild der Anwendung ist als gültig und übernommen markiert.

Ungültig

0xF8

Das Abbild der Anwendung ist als ungültig markiert.

Abbild-Deskriptor

Das Abbild der Anwendung auf dem Flash-Gerät muss den Abbild-Deskriptor nach dem Abbild-Header enthalten. Der Abbild-Deskriptor wird von einem Post-Build-Dienstprogramm erstellt, das die Konfigurationsdateien (ota-descriptor.config) verwendet, um den entsprechenden Deskriptor zu generieren, und stellt diesen dem Binärcode der Anwendung voran. Die Ausgabe dieses Post-Build-Schrittes ist das Binary-Abbild, das für OTA verwendet werden kann.

Feld-Deskriptor Größe (in Bytes)

Sequenznummer

4 Bytes

Startadresse

4 Bytes

Endadresse

4 Bytes

Ausführungsadresse

4 Bytes

Hardware-ID

4 Bytes

Reserved Instances

4 Bytes

Sequenznummer

Die Sequenznummer muss erhöht werden, bevor ein neues OTA-Abbild erstellt wird. Siehe Datei ota-descriptor.config. Der Bootloader ermittelt anhand dieser Nummer das zu startende Abbild. Gültige Werte liegen zwischen 1 und 4294967295.

Startadresse

Die Startadresse des Anwendungsabbilds auf dem Gerät. Da der Abbild-Deskriptor der Binärdatei der Anwendung vorangestellt ist, ist diese Adresse der Start des Abbild-Deskriptors.

Endadresse

Die Endadresse des Anwendungsabbilds auf dem Gerät, ohne Abbild-Trailer.

Ausführungsadresse

Die Ausführungsadresse des Abbilds.

Hardware-ID

Eine vom Bootloader verwendete eindeutige Hardware-ID zur Überprüfung, ob das OTA-Abbild für die korrekte Plattform erstellt wurde.

Reserved Instances

Dies ist für die zukünftige Verwendung reserviert.

Abbild-Trailer

Der Abbild-Trailer wird an den Binärcode der Anwendung angehängt. Er enthält die Signaturtyp-Zeichenfolge, die Signaturgröße und die Signatur des Abbilds.

Trailer-Feld Größe (in Bytes)

Signaturtyp

32 Bytes

Signaturgröße

4 Bytes

Signature

256 Byte

Signaturtyp

Der Signaturtyp ist eine Zeichenfolge, die den verwendeten kryptografischen Algorithmus darstellt und als Markierung für den Trailer dient. Der Bootloader unterstützt den ECDSA-Signaturalgorithmus (Elliptic Curve Digital Signature Algorithm). Der Standardwert ist sig-sha256-ecdsa.

Signaturgröße

Die Größe der kryptografischen Signatur in Bytes.

Signatur

Die kryptografische Signatur des Binärcodes der Anwendung mit dem Abbild-Deskriptor.

Bootloader-Konfiguration

Die grundlegenden Bootloader-Konfigurationsoptionen finden Sie unter freertos/vendors/microchip/boards/curiosity_pic32mzef/bootloader/config_files/aws_boot_config.h. Einige Optionen werden nur für Debuggingzwecke angeboten.

Aktivieren des Standardstarts

Aktiviert die Ausführung der Anwendung von der Standardadresse und darf nur für Debugging-Zwecke aktiviert werden. Das Abbild wird ohne Verifizierung von der Standardadresse aus ausgeführt.

Aktivieren der kryptischen Signaturverifizierung

Aktiviert die kryptografische Signaturverifizierung beim Booten. Die fehlgeschlagene Abbilder werden vom Gerät gelöscht. Diese Option steht nur für Debugging-Zwecke zur Verfügung und muss in der Produktivumgebung aktiviert sein.

Löschen eines ungültigen Abbilds

Ermöglicht das vollständige Löschen der Bank, falls die Abbild-Verifizierung für diese Bank fehlschlägt. Diese Option steht nur für Debugging-Zwecke zur Verfügung und muss in der Produktivumgebung aktiviert sein.

Aktivieren der Hardware-ID-Verifizierung

Ermöglicht die Verifizierung der Hardware-ID im Deskriptor des OTA-Abbilds und der Hardware-ID, die im Bootloader programmiert ist. Dies ist optional und kann deaktiviert werden, wenn die Verifizierung der Hardware-ID nicht erforderlich ist.

Aktivieren der Adressenverifikation

Ermöglicht die Überprüfung der Start-, End- und Ausführungsadresse im Deskriptor des OTA-Abbilds. Wir empfehlen, dass Sie diese Option aktiviert lassen.

Entwickeln des Bootloaders

Der Demo-Bootloader ist als ladbares Projekt in dem aws_demos Projekt enthalten, das sich im FreeRTOS-Quellcode-Repository befindet. freertos/vendors/microchip/boards/curiosity_pic32mzef/aws_demos/mplab/ Wenn das aws_demos-Projekt erstellt wurde, wird zuerst der Bootloader, gefolgt von der Anwendung, erstellt. Die endgültige Ausgabe ist ein einheitliches Hex-Abbild für den Bootloader und die Anwendung. Das factory_image_generator.py-Dienstprogramm wird zum Generieren eines einheitlichen Hex-Abbilds mit kryptografischer Signatur bereitgestellt. Die Skripts des Bootloader-Dienstprogramms befinden sich in freertos/demos/ota/bootloader/utility/.

Schritt vor dem Bootloader-Build

Dieser Schritt vor dem Build führt ein Dienstprogramm-Skript mit dem Namen codesigner_cert_utility.py aus, das den öffentlichen Schlüssel aus dem Codesignierungszertifikat extrahiert und eine C-Header-Datei generiert, die den öffentlichen Schlüssel im Abstract Syntax Notation One (ASN.1)-codierten Format enthält. Dieser Header ist in das Bootloader-Projekt kompiliert. Der generierte Header enthält zwei Konstanten: ein Array des öffentlichen Schlüssels und die Länge des Schlüssels. Das Bootloader-Projekt kann auch ohne aws_demos erstellt und als normale Anwendung debuggt werden.

DatenschutzNutzungsbedingungen für die WebsiteCookie-Einstellungen
© 2025, Amazon Web Services, Inc. oder Tochtergesellschaften. Alle Rechte vorbehalten.