Dela via

Hantera överväganden för minne och svarstid

  • Artikel

Viktigt!

Det här är dokumentationen om Azure Sphere (Legacy). Azure Sphere (Legacy) upphör den 27 september 2027 och användarna måste migrera till Azure Sphere (integrerad) vid den här tiden. Använd versionsväljaren ovanför TOC för att visa dokumentationen om Azure Sphere (integrerad).

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

Kommentar

Mer information om minneskonfiguration eller DMA finns i det publicerade MT3620-databladet från MediaTek. Om frågor kvarstår Azure.Sphere@avnet.comkan du begära MT3620 M4-databladet från Avnet via e-post.

Minneslayout på realtidskärnorna

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-åtkomster är snabba, men endast realtidskärnan kan komma åt minnet. TCM kan inte delas med ett högnivåprogram eller med ett realtidskompatibelt program (RTApp) som körs på en annan kärna.

Varje realtidskärna har också 64 KB SYSRAM, som mappas från och med 0x22000000. DMA-styrenheten kan också rikta in sig på SYSRAM, så att kringutrustningen 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-minne (Execute-in-place) delas med program på hög nivå. Ett fönster i XIP-mappningen av blixten är synligt 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 (som anges i kolumnen VirtAddr i programhuvudet) är lika med 0x10000000
  • Filförskjutning och storlek (som anges i fälten FileSiz och MemSiz i programhuvudet) passar 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 måste peka på 0x10000000. Det går inte att ange någon annan adress.

ELF-distribution

RTApp-avbildningar måste vara ELF-filer. ELF-avbildningen omsluts i ett Azure Sphere-avbildningspaket och distribueras som ett program. För att läsa in programmet startar Azure Sphere OS en ELF-inläsare som körs i realtidskärnan. Inläsaren 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 (gement L), som är en del av GNU Arm Embedded Toolchain, för att visa programrubrikerna för ditt program. Den virtuella adresskolumnen (VirtAddr) som visas i rubriken anger måladressen för inläsningssegmentet. Det innebär inte att processorn själv utför någon ytterligare översättning. Azure Sphere ELF-inläsaren använder inte den fysiska adressen (PhysAddr).

Ta 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 på 0x00100000 är avsett för nära kopplat minne (TCM). Inläsaren kopierar antingen data från avbildningspaketet till RAM-minne eller nollinitierar TCM efter behov.

  • Segmentet på 0x10000000 mappas till XIP-fönstret för kärnan. Vid körning översätts <address-of-XIP-segment-in-flash> + offset åtkomst till 0x10000000 + offset när de lämnar realtidskärnan.

  • Datasegmentet på den virtuella adressen 0x00100e78 mappas till TCM.

Överväganden vid ELF-körning

ELF-inläsaren utför några av de uppgifter som en rå binär fil (eller länkad startladdare) skulle utföra vid start. Mer specifikt nollinitierar den block-started-by-symbol-data (BSS) och kopierar initierade men föränderliga data från skrivskyddad blixt till RAM,enligt programhuvudena. 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 nollställt minnet.

Kopiering av föränderliga data från flash till RAM kan i vissa fall leda till problem, beroende på hur ELF-filen har lagts ut. ELF-inläsaren bearbetar programrubrikerna sekventiellt, utan att ändra den övergripande layouten för segmenten i filen. Sedan mappas inte bara XIP-segmentet till 0x10000000, utan även eventuella efterföljande segment i ordning. Om segmenten i ELF-filen är i sekventiell ordning utan justering eller luckor kan os-startkoden använda pekararitmetik för att hitta början av datasegmentet. Om ELF-filen har en annan layout resulterar pekarens aritmetik dock inte i rätt adress, så programmets startkod får inte försöka kopiera dataavsnittet. Detta kan orsaka problem om programmet eller RTOS använder en länkad startladdare eller behöver konfigurera en stackkanarie innan du nollar BSS eller initierar föränderliga data.

Minnesmål

Du kan rikta kod på TCM, XIP flash eller SYSRAM genom att redigera linker.ld-skriptet för ditt program. Azure Sphere-exempelprogrammen körs från TCM, men skriptfilen linker.ld för varje program beskriver hur man riktar XIP-flash i stället. Som följande exempel visar kan du ändra ett exempel så att det körs på XIP genom att CODE_REGION alias 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-blixten 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 (gemen -l L) för att se var koden och skrivskyddade data har placerats. Kod och skrivskyddade data som finns i flashminne läses in på adressen 0x10000000; kod och data i TCM läses in i TCM-regionen.

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

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

Vektortabellplats

På ARMv7-M-enheter måste vektortabellen justeras efter en power-of-two-gräns som är minst 128 byte och inte mindre än tabellens storlek, enligt beskrivningen i referenshandboken för ARMv7-M-arkitektur. 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-bytesposter för en total storlek på 464 byte, vilket avrundar upp till 512 byte.

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

MT3620 BareMetal-exemplen på Azure Sphere Samples-lagringsplatsen visar hur du gör detta. Deklarationen av vektortabellen i main.c anger dess section attribut till .vector_table. Linker-skriptaliasen 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 högnivåprogram 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 stöta på höga och oförutsägbara svarstider. Skrivningar till flash, till exempel under en uppdatering, kan innebära svarstidstoppar på upp till flera hundra millisekunder. Beroende på programmets krav kan du hantera detta på flera sätt:

  • Placera all kod och alla data i TCM. Kod som körs från TCM är inte sårbar för konkurrens om blixt.

  • Dela upp kod i kritiska och icke-kritiska avsnitt och kör den icke-kritiska koden från flash. Kod som har realtidskrav, till exempel en timer för vakthund, ska inte behöva köras när annan kod kommer åt blixten. Minnesmål beskriver hur man riktar in sig på XIP-blixt i stället för TCM.

  • Använd cacheminne. Ett program kan använda de lägsta 32 KB TCM som XIP-cacheminne. Den här metoden ger inga hårda realtidsgarantier i händelse av en cachemiss, men förbättrar typiska prestanda utan att du behöver flytta all kod till RAM-minnet. Se "MT3620 M4 Datasheet" för information om XIP-cachekonfiguration.