メモリと待機時間に関する考慮事項の管理
重要
これは Azure Sphere (レガシ) のドキュメントです。 Azure Sphere (レガシ) は 2027 年 9 月 27 日に 再提供されておりユーザーは現時点で Azure Sphere (統合) に移行する必要があります。 TOC の上にある Version セレクターを使用して、Azure Sphere (統合) のドキュメントを表示します。
このトピックでは、MT3620 チップ上で実行されるリアルタイム アプリケーションの基本的なメモリの使用と待機時間に関する考慮事項について説明します。
Note
メモリ構成または DMA の詳細については、MediaTek から発行された MT3620 データシートを参照してください;質問が残っている場合は、 Azure.Sphere@avnet.com電子メールで Avnet から "MT3620 M4 データシート" を要求できます。
リアルタイム コアでのメモリ レイアウト
次の表は、リアルタイム コアで使用できるメモリについてまとめたものです。
| メモリの種類 | ベース アドレス |
|---|---|
| TCM | 0x00100000 |
| XIP フラッシュ | 0x10000000 |
| SYSRAM | 0x22000000 |
リアルタイム コアにはそれぞれ 192 KB の密結合メモリ (TCM) があり、0x00100000 から始まる 64 KB の 3 つのバンクでマップされています。 TCM へのアクセスは高速ですが、メモリにアクセスできるのはリアルタイム コアのみとなります。 TCM は、高度なアプリケーションや、別のコアで実行されるリアルタイム対応アプリケーション (RTApp) で共有することはできません。
また、リアルタイム コアにはそれぞれ 64 KB の SYSRAM があります。これは、0x22000000 から始まり、マップされます。 DMA コントローラーでも SYSRAM をターゲットにすることができるため、周辺機器からそれにアクセスできます。 リアルタイム コアからの SYSRAM へのアクセスは、TCM へのアクセスよりも時間がかかります。 TCM と同様、SYSRAM を別のアプリケーションと共有することはできません。
インプレース実行 (XIP) フラッシュ メモリは、高度なアプリケーションと共有されます。 フラッシュの XIP マッピングのウィンドウは、アドレス 0x10000000 のコアごとに表示されます。 アプリケーションの ELF ファイルに次のプロパティを持つセグメントが含まれている場合、OS では、アプリケーションを起動する前に XIP マッピングが構成されます。
- 読み込みアドレス (プログラム ヘッダーの VirtAddr 列で指定) が 0x10000000 と等しい
- ファイル オフセットとサイズ (プログラム ヘッダーの FileSiz および MemSiz フィールドで指定) がアプリケーションの ELF ファイルに収まる
これらのプロパティを持つプログラム ヘッダーがアプリケーションの ELF ファイルに存在する場合、セグメントが 0x10000000 で表示されるように、XIP ウィンドウが位置付けされます。 ファイルでは、XIP セグメントを 1 つのみ含めることができ、0x10000000 をポイントする必要があります。その他のアドレスを指定することはできません。
ELF のデプロイ
RTApp イメージは ELF ファイルである必要があります。 ELF イメージは Azure Sphere のイメージ パッケージ内にラップされ、アプリケーションとしてデプロイされます。 アプリケーションを読み込むために、リアルタイム コアで実行される ELF ローダーが Azure Sphere OS によって起動されます。 ローダーでは、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 (block-started-by-symbol) データがゼロに初期化され、プログラム ヘッダーに応じて、読み取り専用フラッシュから RAM に、初期化されているが変更可能なデータがコピーされます。 その後、アプリケーションが起動し、独自の初期化関数が実行されます。 ほとんどの場合、既存のアプリケーションの変更は必要ありません。 アプリケーションの BSS データをゼロに設定する必要はありませんが、行っても問題はありません。これは、ローダーで既にメモリがゼロに設定されているためです。
フラッシュから RAM に変更可能なデータをコピーすると、ELF ファイルのレイアウト方法によっては問題が発生する場合があります。ELF ローダーは、ファイル内のセグメントの全体的なレイアウトを変更せずに、プログラム ヘッダーを順番に処理します。 その後、0x10000000 に XIP セグメント自体だけでなく、後続のセグメントも順にマップします。 ELF ファイル内のセグメントが位置調整やギャップなしで順に並んでいる場合、OS スタートアップ コードではポインター算術演算を使用してデータ セグメントの先頭を見つけることができます。 ただし、ELF ファイルのレイアウトが異なる場合、ポインター算術演算では正しいアドレスが得られないため、アプリケーション スタートアップ コードでデータ セクションのコピーを試すことはできません。 アプリケーションまたは RTOS でチェーンされたブートローダーを使用する場合や、BSS をゼロに設定するか変更可能なデータを初期化する前にスタックにカナリアを設定する必要がある場合、これにより問題が発生する可能性があります。
メモリ ターゲット
ご利用のアプリケーション用に linker.ld スクリプトを編集することで、TCM、XIP フラッシュ、または SYSRAM をコードのターゲットにすることができます。 Azure Sphere サンプル アプリケーションは TCM から実行されますが、各アプリケーションの linker.ld スクリプト ファイルでは、代わりに XIP フラッシュをターゲットとする方法について説明されています。 以下の例に示されているように、既定の TCM ではなく、CODE_REGION と RODATA_REGION を FLASH にエイリアス化することで、XIP で実行するようにサンプルを変更できます。
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 バイト以上の 2 のべき乗の境界に合わせられ、「ARMv7-M アーキテクチャ リファレンス マニュアル」で説明されているように、テーブルのサイズ以上である必要があります。 MT3620 の各 I/O RT コアでは、100 個の外部割り込みがサポートされます。 そのため、スタック ポインターや 15 の標準の例外を含め、テーブルには合計サイズ 464 バイトに対して 116 個の 4 バイト エントリがあります (切り上げて 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
...
}
リアルタイムおよび待機時間に関する考慮事項
RTApp と高度なアプリケーションは、相互通信しない場合でも、フラッシュ メモリへのアクセスのために競合します。 その結果、XIP フラッシュから実行される RTApp では予測できない長い待機時間が発生する場合があります。 更新時など、フラッシュへの書き込みで、待機時間が数百ミリ秒まで急増する場合があります。 アプリケーションの要件に応じて、これをいくつかの方法で管理できます。
TCM ですべてのコードとデータを配置する。 TCM から実行されるコードは、フラッシュの競合に対して脆弱ではありません。
コードをクリティカル セクションと非クリティカル セクションに分割し、フラッシュから非クリティカル コードを実行する。 ウォッチドッグ タイマーなど、リアルタイムの要件があるコードは、他のコードでフラッシュにアクセスするときに実行する必要はありません。 TCM ではなく、XIP フラッシュをターゲットとする方法については、「Memory targets」(メモリ ターゲット) で説明しています。
キャッシュを使用する。 アプリケーションでは、XIP キャッシュとして、最も低い 32 KB の TCM を使用することができます。 この方法では、キャッシュ ミスが発生した場合にハード リアルタイム保証は提供されませんが、RAM へのすべてのコードの移動を必要とすることなく、一般的なパフォーマンスが向上します。 XIP キャッシュの構成については、"MT3620 M4 データシート" を参照してください。