Verwalten der Überlegungen zu Arbeitsspeicher und Wartezeit

Artikel
11/05/2024

Wichtig

Dies ist die Dokumentation zu Azure Sphere (Legacy). Azure Sphere (Legacy) wird am 27. September 2027 eingestellt, und Benutzer müssen bis zu diesem Zeitpunkt zu Azure Sphere (integriert) migrieren. Verwenden Sie die Versionsauswahl oberhalb des Inhaltsverzeichniss, um die Dokumentation zu Azure Sphere (Integriert) anzuzeigen.

In diesem Thema werden grundlegende Überlegungen zur Arbeitsspeichernutzung sowie zur Wartezeit für Echtzeitanwendungen beschrieben, die auf dem MT3620-Chip ausgeführt werden.

Hinweis

Weitere Details zur Speicherkonfiguration oder DMA finden Sie im veröffentlichten MT3620-Datenblatt von MediaTek. Wenn Fragen bestehen, können Sie das "MT3620 M4-Datenblatt" von Avnet per E-Mail Azure.Sphere@avnet.comanfordern.

Arbeitsspeicherlayout für die Echtzeitkerne

Die folgende Tabelle enthält eine Zusammenfassung des für die Echtzeitkerne verfügbaren Arbeitsspeichers:

Speichertyp	Basisadresse
TCM	0x00100000
XIP-Flash	0x10000000
SYSRAM	0x22000000

Jeder Echtzeitkern verfügt über 192 KB TCM (Tightly-Coupled Memory). Dieser ist in drei Bänke mit jeweils 64 KB unterteilt und beginnt bei 0x00100000. TCM-Zugriffe sind schnell, aber nur der Echtzeitkern kann auf den Arbeitsspeicher zugreifen. TCM kann nicht mit einer allgemeinen Anwendung oder mit einer Echtzeitanwendung (RTApp) geteilt werden, die auf einem anderen Kern ausgeführt wird.

Jeder Echtzeitkern verfügt auch über 64 KB SYSRAM, der ab 0x22000000 zugeordnet wird. Der DMA-Controller kann auch SYSRAM als Ziel verwenden, sodass Peripheriegeräte darauf zugreifen können. SYSRAM-Zugriffe des Echtzeitkerns sind langsamer als TCM-Zugriffe. Genau wie TCM kann auch SYSRAM nicht mit einer anderen Anwendung geteilt werden.

Flashspeicher vom Typ XIP (Execute-In-Place) wird mit allgemeinen Anwendungen gemeinsam genutzt. Ein XIP-Zuordnungsfenster des Flashs ist für jeden Kern unter der Adresse 0x10000000 sichtbar. Das Betriebssystem konfiguriert die XIP-Zuordnung vor dem Starten der Anwendung, wenn die ELF-Datei der Anwendung ein Segment mit folgenden Eigenschaften enthält:

Die Ladeadresse (gemäß Angabe in der Spalte „VirtAddr“ des Programmheaders) lautet 0x10000000.
Dateioffset und -größe (gemäß Angabe in den Feldern „FileSiz“ und „MemSiz“ im Programmheader) passen in die ELF-Datei der Anwendung.

Wenn die ELF-Datei der Anwendung einen Programmheader mit diesen Eigenschaften enthält, wird das XIP-Fenster so positioniert, dass das Segment bei 0x10000000 sichtbar ist. Die Datei darf nur ein einzelnes XIP-Segment enthalten, und dieses muss auf 0x10000000 verweisen. Die Angabe einer anderen Adresse ist nicht zulässig.

ELF-Bereitstellung

Bei RTApp-Images muss es sich um ELF-Dateien handeln. Das ELF-Image wird in ein Azure Sphere-Imagepaket eingeschlossen und als Anwendung bereitgestellt. Zum Laden der Anwendung startet das Azure Sphere-Betriebssystem ein ELF-Ladeprogramm, das auf dem Echtzeitkern ausgeführt wird. Das Ladeprogramm verarbeitet die einzelnen LOAD-Segmente in der ELF-Datei und lädt sie jeweils in den Arbeitsspeichertyp, der durch die virtuelle Adresse im Programmheader angegeben ist.

Die Programmheader für Ihre Anwendung können Sie mithilfe von arm-none-eabi-readelf.exe -l (klein geschriebenes L) anzeigen, das zu GNU Arm Embedded Toolchain gehört. Die im Header enthaltene Spalte mit der virtuellen Adresse (VirtAddr) gibt die Zieladresse für das Ladesegment an. Das bedeutet nicht, dass der Prozessor selbst eine zusätzliche Übersetzung durchführt. Das ELF-Ladeprogramm von Azure Sphere verwendet nicht die physische Adresse (PhysAddr).

Betrachten Sie das folgende Beispiel:

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x000098 0x00100000 0x00100000 0x00000 0x00e78 RW  0x8
  LOAD           0x0000a0 0x10000000 0x10000000 0x03078 0x03078 RWE 0x10
  LOAD           0x003118 0x00100e78 0x10003078 0x000f0 0x000f0 RW  0x4

Das Segment bei 0x00100000 ist auf TCM (Tightly-Coupled Memory) ausgerichtet. Das Ladeprogramm kopiert entweder Daten aus dem Imagepaket in den Arbeitsspeicher oder führt nach Bedarf eine Nullinitialisierung des TCM durch.
Das Segment bei 0x10000000 wird dem XIP-Fenster für den Kern zugeordnet. Zur Laufzeit werden Zugriffe auf 0x10000000 + offset in <address-of-XIP-segment-in-flash> + offset übersetzt, wenn sie den Echtzeitkern verlassen.
Das Datensegment unter der virtuellen Adresse 0x00100e78 wird TCM zugeordnet.

ELF-Laufzeitüberlegungen

Das ELF-Ladeprogramm führt einige der Aufgaben aus, die eine unformatierte Binärdatei (oder ein verketteter Bootloader) beim Start ausführen würde. Es führt insbesondere eine Nullinitialisierung von BSS-Daten (Block Started by Symbol) durch und kopiert initialisierte, aber änderbare Daten aus schreibgeschütztem Flashspeicher in den Arbeitsspeicher (gemäß den Programmheadern). Anschließend wird die Anwendung gestartet und führt ihre eigenen Initialisierungsfunktionen aus. In den meisten Fällen sind keine Änderungen an vorhandenen Anwendungen erforderlich. Die Nullung der BSS-Daten in der Anwendung ist unnötig, aber unbedenklich, da das Ladeprogramm bereits die Nullung des Arbeitsspeichers durchgeführt hat.

Das Kopieren von änderbaren Daten aus Flash in RAM kann unter bestimmten Umständen zu Problemen führen, je nachdem, wie die ELF-Datei ausgelegt ist. Das ELF-Ladeprogramm verarbeitet die Programmheader sequenziell, ohne das Gesamtlayout der Segmente in der Datei zu ändern. Anschließend ordnet es nicht nur das XIP-Segment der Adresse 0x10000000 zu, sondern nacheinander auch alle nachfolgenden Segmente. Wenn die Segmente in der ELF-Datei in sequenzieller Reihenfolge ohne Ausrichtung oder Lücken vorliegen, kann der Betriebssystem-Startcode per Zeigerarithmetik den Anfang des Datensegments ermitteln. Besitzt die ELF-Datei dagegen ein anderes Layout, liefert die Zeigerarithmetik nicht die korrekte Adresse, und der Anwendungsstartcode darf nicht versuchen, den Datenabschnitt zu kopieren. Dies kann zu Problemen führen, wenn die Anwendung oder das Echtzeitbetriebssystem (Real-Time Operating System, RTOS) einen verketteten Bootloader verwendet oder vor der BSS-Nullung oder der Initialisierung änderbarer Daten einen Stack-Canary einrichten muss.

Arbeitsspeicherziele

Sie können Code für TCM, Flash-XIP oder SYSRAM als Ziel verwenden, indem Sie das Skript „linker.ld“ für Ihre Anwendung bearbeiten. Die Azure Sphere-Beispielanwendungen werden zwar über TCM ausgeführt, in der Skriptdatei „linker.ld“ für die jeweilige Anwendung ist jedoch beschrieben, wie Sie stattdessen XIP-Flash als Ziel verwenden. Das folgende Beispiel zeigt, wie Sie ein Beispiel für die Ausführung über XIP ändern. Dies erreichen Sie mittels Aliasing von „CODE_REGION“ und „RODATA_REGION“ in „FLASH“ (anstelle des Standardwerts TCM):

REGION_ALIAS("CODE_REGION", FLASH);
REGION_ALIAS("RODATA_REGION", FLASH);

Mit arm-none-eabi-readelf.exe (aus der GNU Arm Embedded Toolchain) können Sie ermitteln, ob eine kompilierte Anwendung über TCM oder über XIP-Flash ausgeführt wird. Führen Sie den Befehl für die OUT-Datei (befindet sich im gleichen Verzeichnis wie das Imagepaket) aus, und geben Sie das Flag -l (klein geschriebenes L) an, um zu sehen, wo der Code und die schreibgeschützten Daten platziert wurden. Code und schreibgeschützte Daten im Flashspeicher werden unter der Adresse 0x10000000 geladen. Code und Daten in TCM werden in die TCM-Region geladen.

Das folgende Beispiel zeigt eine Anwendung, die über Flashspeicher ausgeführt wird:

arm-none-eabi-readelf.exe -l UART_RTApp_MT3620_BareMetal.out

Elf file type is EXEC (Executable file)
Entry point 0x10000000
There are 2 program headers, starting at offset 52

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x000074 0x00100000 0x00100000 0x00284 0x003c0 RW  0x4
  LOAD           0x000300 0x10000000 0x10000000 0x013b9 0x013b9 R E 0x10

 Section to Segment mapping:
  Segment Sections...
   00     .data .bss
   01     .text .rodata

Speicherort der Vektortabelle

Auf ARMv7-M-Geräten muss die Vektortabelle auf eine Zweierpotenzgrenze ausgerichtet sein, die mindestens 128 Bytes und nicht weniger als die Größe der Tabelle beträgt, wie im Referenzleitfaden zur ARMv7-M-Architektur beschrieben. Jeder I/O RT-Kern auf dem MT3620 unterstützt 100 externe Unterbrechungen. Daher weist die Tabelle einschließlich des Stapelzeigers und 15 Standardausnahmen 116 4-Byte-Einträge für eine Gesamtgröße von 464 Bytes auf, aufgerundet 512 Bytes.

Wenn der Code vom XIP-Flash ausgeführt wird, muss die Vektortabelle bei 0x10000000 positioniert und auf eine 32 Byte große Grenze in der ELF-Datei ausgerichtet werden. Wenn der Code nicht über XIP-Flash ausgeführt wird, wird die Tabelle in der Regel am Anfang von TCM0 (0x100000) positioniert. Um sicherzustellen, dass die virtuelle Adresse der Tabelle richtig ausgerichtet ist, platzieren Sie die Vektortabelle in beiden Fällen in einem dedizierten Abschnitt, und legen Sie CODE_REGION auf die entsprechende Adresse fest.

Die MT3620 BareMetal-Beispiele im Azure Sphere-Beispielrepository zeigen, wie dies funktioniert. Die Deklaration der Vektortabelle in „main.c“ legt deren section-Attribut auf .vector_table fest. Das Linkerskript legt CODE_REGION als Alias am Anfang von TCM oder XIP fest, und das ALIGN-Attribut legt die Ausrichtung des Textabschnitts in der ELF-Datei wie folgt fest:

SECTIONS
{
    .text : ALIGN(32) {
        KEEP(*(.vector_table))
        *(.text)
    } >CODE_REGION
...
}

Überlegungen zu Echtzeit und Wartezeit

RTApps und allgemeine Anwendungen konkurrieren um Zugriff auf Flashspeicher, auch wenn sie nicht miteinander kommunizieren. Daher kommt es bei RTApps, die über XIP-Flash ausgeführt werden, unter Umständen zu hohen und unvorhergesehenen Wartezeiten. Schreibvorgänge im Flashspeicher (etwa während eines Updates) können Wartezeitspitzen von mehreren hundert Millisekunden verursachen. Dies kann abhängig von den Anforderungen Ihrer Anwendung auf unterschiedliche Weise behandelt werden:

Sie können den gesamten Code und sämtliche Daten in TCM platzieren. Über TCM ausgeführter Code muss nicht um Flashspeicher konkurrieren.
Sie können Code in kritische und nicht kritische Abschnitte unterteilen und den nicht kritischen Code über Flashspeicher ausführen. Code mit Echtzeitanforderungen (etwa ein Watchdog-Timer) sollte nicht ausgeführt werden müssen, wenn anderer Code auf den Flashspeicher zugreift. Unter Arbeitsspeicherziele wird beschrieben, wie Sie XIP-Flash anstelle von TCM als Ziel verwenden.
Sie können Cache verwenden. Eine Anwendung kann die niedrigsten 32 KB von TCM als XIP-Cache verwenden. Dieser Ansatz bietet im Falle eines Cachefehlers keine festen Echtzeitgarantien, verbessert aber die typische Leistung, ohne dass der gesamte Code in den Arbeitsspeicher verschoben werden muss. Informationen zur XIP-Cachekonfiguration finden Sie im "MT3620 M4-Datenblatt".

Teilen über