Hantera minnes- och svarstidsöverväganden

Artikel
08/09/2023

I det här avsnittet beskrivs grundläggande minnesanvändning och svarstidsöverväganden för realtidsprogram som körs på MT3620-kretsen.

Observera

Mer information om minneskonfiguration eller DMA finns i det publicerade MT3620-databladet från MediaTek. om frågor kvarstår kan du begära "MT3620 M4-datablad" från Avnet genom att Azure.Sphere@avnet.comskicka ett e-postmeddelande till .

Minneslayout i kärnorna i realtid

I följande tabell sammanfattas det tillgängliga minnet i realtidskärnorna:

Minnestyp	Basadress
TCM	0x00100000
XIP-blixt	0x10000000
SYSRAM	0x22000000

Varje realtidskärna har 192 kB tätt kopplat minne (TCM), som mappas i tre banker med 64 KB från och med 0x00100000. TCM-åtkomst är snabb, men bara realtidskärnan kan komma åt minnet. TCM kan inte delas med ett program på hög nivå eller med ett rtapp-program (real-time capable application) som körs på en annan kärna.

Varje realtidskärna har också 64 kB SYSRAM, som mappas med början från 0x22000000. DMA-styrenheten kan även rikta in sig på SYSRAM så att kringutrustning kan komma åt den. Åtkomsten till SYSRAM från realtidskärnan är långsammare än åtkomsten till TCM. Precis som med TCM kan SYSRAM inte delas med ett annat program.

Xip-flashminnet (Execute-in-Place) delas med program på hög nivå. Ett fönster i XIP-mappningen av blixten visas för varje kärna på adressen 0x10000000. Operativsystemet konfigurerar XIP-mappningen innan programmet startas om programmets ELF-fil innehåller ett segment som har följande egenskaper:

Inläsningsadressen (enligt specifikationen i kolumnen VirtAddr i programhuvudet) är lika med 0x10000000
Filförskjutning och filstorlek (enligt specifikationen i fälten FileSiz och MemSiz i programhuvudet) får plats i programmets ELF-fil

Om ett programhuvud med dessa egenskaper finns i programmets ELF-fil placeras XIP-fönstret så att segmentet visas på 0x10000000. Filen får inte ha mer än ett XIP-segment och den måste peka på 0x10000000. den kan inte ange någon annan adress.

ELF-distribution

RTApp-avbildningar måste vara ELF-filer. ELF-avbildningen radbryts i ett Azure Sphere-avbildningspaket och distribueras som ett program. För att läsa in programmet startar Azure Sphere-operativsystemet en ELF-inläsning som körs på realtidskärnan. Inläsningsprogrammet bearbetar varje LOAD-segment i ELF-filen och läser in det i den typ av minne som anges av den virtuella adressen i programhuvudet.

Använd arm-none-eabi-readelf.exe -l (gemener L), som är en del av GNU Arm Embedded Toolchain, för att visa programrubrikerna för programmet. Den virtuella adresskolumnen (VirtAddr) som visas i rubriken anger måladressen för inläsningssegmentet. Det innebär inte att själva processorn utför någon ytterligare översättning. Azure Sphere ELF-inläsaren använder inte den fysiska adressen (PhysAddr).

Tänk på det här exemplet:

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

Segmentet vid 0x00100000 är avsett för tätt kopplat minne (TCM). Inläsaren kopierar antingen data från avbildningspaketet till RAM-minne eller nollinitierar TCM efter behov.
Segmentet vid 0x10000000 mappas till XIP-fönstret för kärnan. Vid körningen översätts <address-of-XIP-segment-in-flash> + offset åtkomst till 0x10000000 + offset när de lämnar kärnan i realtid.
Datasegmentet vid den virtuella adressen 0x00100e78 mappas till TCM.

Att tänka på när det gäller ELF-körning

ELF-inläsningsprogrammet utför några av de uppgifter som en binär raw-fil (eller kedjad startladdare) utför vid start. Specifikt nollinitierar BSS-data (block-started-by-symbol) och kopierar initierade men muterbara data från skrivskyddad flash till RAM, enligt programrubrikerna. Programmet startar sedan och kör sina egna initieringsfunktioner. I de flesta fall krävs inte ändringar i befintliga program. Att nollställa BSS-data i programmet är onödigt men ofarligt, eftersom inläsaren redan har nollat minnet.

Kopiering av mutable data från flash till RAM kan under vissa omständigheter resultera i problem, beroende på hur ELF-filen läggs ut. ELF-inläsningen bearbetar programrubrikerna i följd utan att ändra den övergripande layouten för segmenten i filen. Det kartlägger därefter inte endast XIP-segment sig själv till 0x10000000, men också några efterföljande segment i ordning. Om segmenten i ELF-filen är i sekventiell ordning utan justering eller mellanrum kan startkoden för operativsystemet använda pekaren aritmetik för att hitta början av datasegmentet. Om ELF-filen har en annan layout resulterar dock inte pekarens aritmetiska adress i rätt adress, så programstartkoden får inte försöka kopiera dataavsnittet. Det kan orsaka problem om programmet eller RTOS använder en kedjad startläsare eller behöver konfigurera en stapelkanarie innan BSS nollställs eller när mutable data initieras.

Minnesmål

Du kan ange målkod på TCM, XIP flash eller SYSRAM genom att redigera skriptet linker.ld för programmet. Azure Sphere-exempelprogrammen körs från TCM, men skriptfilen linker.ld för varje program beskriver istället hur xip-blixten ska riktas. Som visas i följande exempel kan du ändra ett exempel så att det körs på XIP genom att aliasera CODE_REGION och RODATA_REGION till FLASH i stället för standard-TCM:

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

För att avgöra om ett kompilerat program körs från TCM eller XIP flash använder du arm-none-eabi-readelf.exe, som är en del av GNU Arm Embedded Toolchain. Kör den på .out-filen, som finns i samma katalog som avbildningspaketet, och ange flaggan (gemener -l L) för att se var koden och skrivskyddade data har placerats. Kod och skrivskyddade data som finns i flashminnet läses in vid adress 0x10000000. kod och data i TCM läses in i TCM-regionen.

I följande exempel visas ett program som körs från flashminnet.

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

Vektortabellens placering

På ARMv7-M-enheter måste vektortabellen justeras mot en potens av två gränser som är minst 128 byte och inte mindre än tabellens storlek, enligt beskrivningen i referenshandboken för arkitekturen ARMv7-M. Varje I/O RT-kärna på MT3620 stöder 100 externa avbrott. Därför, inklusive stackpekaren och 15 standardundantag, har tabellen 116 4-byteposter, för en total storlek på 464 byte, som avrundar upp till 512 byte.

När koden körs från XIP-blixt måste vektortabellen placeras på 0x10000000 och justeras mot en gräns på 32 byte i ELF-filen. När koden inte körs från XIP flash placeras tabellen vanligtvis i början av TCM0, som är 0x100000. I båda fallen, för att säkerställa att tabellens virtuella adress är korrekt justerad, placera vektortabellen i ett dedikerat avsnitt och ange CODE_REGION till lämplig adress.

MT3620 BareMetal-exemplen i Azure Sphere Samples-databasen visar hur du gör detta. Deklarationen av vektortabellen i main.c anger dess section attribut till .vector_table. Länkskriptaliasen CODE_REGION till början av TCM eller XIP, och attributet ALIGN anger justeringen av textavsnittet i ELF-filen enligt följande:

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

Överväganden i realtid och svarstid

RTApps och program på hög nivå kämpar för åtkomst till flashminne, även om de inte kommunicerar med varandra. Därför kan RTApps som körs från XIP flash få höga och oförutsägbara svarstider. Skrivningar som ska blinka, till exempel under en uppdatering, kan innebära fördröjningar på upp till flera hundra millisekunder. Beroende på programmets krav kan du hantera det på flera olika sätt:

Placera all kod och alla data i TCM. Kod som körs från TCM är inte sårbar för strid för blixt.
Dela upp kod i kritiska och icke-kritiska avsnitt och kör den icke-kritiska koden från flash. Kod som har realtidskrav, t.ex. en timer för vakthund, ska inte behöva köras när annan kod använder blixten. Minnesmål beskriver hur man riktar XIP flash i stället för TCM.
Använd cacheminne. Ett program kan använda de lägsta 32 KB TCM som XIP-cache. Den här metoden ger inte några hårda realtidsgarantier om cacheminnet skulle missas, men förbättrar typiska prestanda utan att du behöver flytta all kod till RAM-minne. Se "MT3620 M4-databladet" för information om XIP-cachekonfiguration.

Share via