管理記憶體和延遲考慮

發行項
09/27/2024

重要

這是 Azure Sphere （舊版）檔。 Azure Sphere（舊版）將於 2027 年 9 月 27 日淘汰，且使用者此時必須移轉至 Azure Sphere（整合式）。 使用位於 TOC 上方的版本選取器來檢視 Azure Sphere （整合式）檔。

本主題描述在 MT3620 晶片上執行的即時應用程式的基本記憶體使用和延遲考慮。

注意

如需記憶體設定或 DMA 的詳細資訊，請參閱 MediaTek 已發布的 MT3620 資料工作表;如有問題，您可以透過電子郵件Azure.Sphere@avnet.com從 Avnet 要求 “MT3620 M4 數據工作表”。

即時核心上的記憶體配置

下表摘要說明即時核心上可用的記憶體：

記憶體類型	基底位址
中醫	0x00100000
XIP 快閃	0x10000000
SYSRAM	0x22000000

每個即時核心都有 192 KB 的緊密結合記憶體（TCM），從 0x00100000 開始，會以 64 KB 的三個銀行對應。 TCM 存取速度很快，但只有即時核心可以存取記憶體。 TCM 無法與高層級應用程式或可在不同核心上執行的即時支援應用程式（RTApp）共用。

每個即時核心也有 64 KB 的 SYSRAM，從 0x22000000 開始對應。 DMA 控制器也可以以 SYSRAM 為目標，讓外圍設備可以存取它。從即時核心存取SRAM的速度比存取TCM慢。如同 TCM，SYSRAM 無法與另一個應用程式共用。

就地執行（XIP）快快閃記憶體會與高階應用程式共用。在位址0x10000000的每個核心可以看到快閃的 XIP 對應視窗。如果應用程式的 ELF 檔案包含具有下列屬性的區段，則 OS 會在啟動應用程式之前設定 XIP 對應：

載入位址（如 Program Header 的 VirtAddr 資料行中所指定）等於0x10000000
檔案位移和大小（如 Program Header 中的 FileSiz 和 MemSiz 欄位所指定）符合應用程式的 ELF 檔案

如果具有這些屬性的程序標頭存在於應用程式的 ELF 檔案中，則會放置 XIP 視窗，讓區段顯示在0x10000000。檔案不能有一個以上的 XIP 區段，而且必須指向 0x10000000;無法指定任何其他位址。

ELF 部署

RTApp 映像必須是 ELF 檔案。 ELF 映像會包裝在 Azure Sphere 映像套件中，並部署為應用程式。若要載入應用程式，Azure Sphere OS 會啟動在即時核心上執行的 ELF 載入器。載入器會處理 ELF 檔案中的每個 LOAD 區段，並將它載入程式標頭中虛擬位址所指示的記憶體類型。

使用 arm-none-eabi-readelf.exe -l （小寫 L），這是 GNU Arm Embedded Toolchain 的一部分，以顯示您應用程式的程式標頭。出現在標頭中的虛擬地址資料列（VirtAddr）表示載入區段的目的地位址。這並不表示處理器本身會執行任何其他轉譯。 Azure Sphere ELF 載入器不會使用實體位址（PhysAddr）。

請考慮此範例：

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

0x00100000的區段是以緊密結合的記憶體（TCM）為目標。載入器會將映像套件中的數據複製到 RAM，或視需要將 TCM 初始化為零。
0x10000000的區段會對應至核心的 XIP 視窗。在運行時間，存取權 0x10000000 + offset 會在離開即時核心時轉譯為 <address-of-XIP-segment-in-flash> + offset 。
虛擬位址0x00100e78的數據區段會對應至 TCM。

ELF 運行時間考慮

ELF 載入器會執行原始二進位檔（或鏈結式開機載入器）在啟動時執行的一些工作。具體來說，它會根據程序標頭，以零初始化區塊啟動符號（BSS）數據，並將初始化但可變的數據從只讀快閃複製到 RAM。然後，應用程式會啟動並執行自己的初始化函式。在大部分情況下，不需要變更現有的應用程式。將應用程式中的 BSS 資料歸零是不必要的，但無害，因為載入器已經將記憶體歸零。

視 ELF 檔案設定方式而定，在某些情況下，將可變數據從快閃複製到 RAM 可能會導致問題。ELF 載入器會循序處理程式標頭，而不會變更檔案中區段的整體配置。然後，它不僅會將 XIP 區段本身對應至0x10000000，也會依序對應任何後續區段。如果 ELF 檔案中的區段是循序順序且沒有任何對齊或間距，則 OS 啟動程式代碼可以使用指標算術來尋找數據區段的開頭。不過，如果 ELF 檔案有不同的版面配置，指標算術不會產生正確的位址，因此應用程式啟動程式代碼不得嘗試複製數據區段。如果應用程式或 RTOS 使用鏈結的開機載入器，或需要在零 BSS 或初始化可變動資料之前設定堆疊 Canary，這可能會造成問題。

記憶體目標

您可以編輯應用程式的 linker.ld 腳本，以 TCM、XIP 快閃或 SYSRAM 為目標的程式碼。 Azure Sphere 範例應用程式會從 TCM 執行，但每個應用程式的 linker.ld 腳本檔案會描述如何改為以 XIP 快閃為目標。如下列範例所示，您可以將CODE_REGION和RODATA_REGION別名變更為在 XIP 上執行的範例，而不是預設的 TCM：

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

若要判斷編譯的應用程式是否從 TCM 或 XIP 快閃執行，請使用 arm-none-eabi-readelf.exe，這是 GNU Arm Embedded Toolchain 的一部分。在與映像套件位於相同目錄中的 .out 檔案上執行它，並指定 -l （小寫 L）旗標來查看程式代碼和只讀資料的位置。快快閃記憶體中的程式代碼和唯讀資料會載入位址0x10000000;TCM 中的程式碼和資料會在 TCM 區域中載入。

下列範例顯示從快快閃記憶體執行的應用程式。

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

向量數據表位置

在ARMv7-M裝置上，向量數據表必須在至少128個字節且小於數據表大小的兩個界限上對齊，如ARMv7-M架構參考手冊中所述。 MT3620 上的每個 I/O RT 核心都支援 100 個外部中斷。因此，包括堆棧指標和 15 個標準例外狀況，數據表有 116 個 4 位元組的專案，總大小為 464 個字節，四捨五入至 512 個字節。

從 XIP 快閃執行程式碼時，向量數據表必須放在0x10000000，且必須對齊 ELF 檔案內的 32 位元組界限。當程式代碼不是從 XIP 快閃執行時，數據表通常會放在 TCM0 開頭，也就是0x100000。在任一情況下，若要確保數據表的虛擬位址正確對齊，請將向量數據表放在專用區段中，並將CODE_REGION設定為適當的位址。

Azure Sphere 範例存放庫中的 MT3620 BareMetal 範例會示範如何執行這項操作。 main.c 中向量資料表的宣告會將其 section 屬性設定為 .vector_table。鏈接器腳本別名CODE_REGION TCM 或 XIP 開頭，而 ALIGN 屬性會設定 ELF 檔案中文字區段的對齊方式，如下所示：

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

即時和延遲考慮

RTApps 和高階應用程式會爭相存取快快閃記憶體，即使它們不會彼此通訊也一樣。因此，從 XIP 快閃執行的 RTApp 可能會遇到高且無法預測的延遲。寫入快閃，例如在更新期間，可能牽涉到延遲尖峰高達數百毫秒。視應用程式的需求而定，您可以透過數種方式來管理此專案：

將所有程式代碼和數據放在 TCM 中。從 TCM 執行的程式代碼並不容易爭用快閃。
將程式代碼分割成重大和非關鍵區段，然後從 flash 執行非關鍵程式代碼。具有即時需求的程序代碼，例如監視程式定時器，不應該在其他程式代碼存取快閃時執行。記憶體目標描述如何以 XIP 快閃而非 TCM 為目標。
使用快取。應用程式可以使用最低 32 KB 的 TCM 作為 XIP 快取。此方法不會在發生快取遺漏時提供硬式實時保證，但可改善一般效能，而不需要您將所有程式代碼移至 RAM。如需 XIP 快取設定的相關信息，請參閱「MT3620 M4 數據工作表」。

共用方式為