STM32開発者必見！ブートローダーの基本と応用

組み込みシステムの開発において、ブートローダーはシステムの起動とファームウェアの更新という、非常に重要な役割を担っています。特に高性能かつ多機能なSTM32マイクロコントローラーファミリーでは、ブートローダーを理解し、適切に活用または開発することが、製品の信頼性向上、機能拡張、および保守性確保の鍵となります。

この記事では、STM32開発者向けに、ブートローダーの基本的な仕組みから、STが提供するROMブートローダーの詳細、さらにカスタムブートローダーの開発方法とその応用例（OTA、セキュリティなど）までを、詳細かつ包括的に解説します。

第1部：ブートローダーとは？なぜSTM32開発で重要なのか

1.1 ブートローダーの役割と定義

ブートローダー（Bootloader）とは、マイクロコントローラーを含む組み込みシステムがリセット後に最初に実行するプログラムのことです。OSを搭載しないベアメタル環境や、RTOSを使用する環境を問わず、多くの組み込みシステムに存在します。

その主な役割は以下の通りです。

ハードウェアの初期化: システムクロックの設定、GPIOの初期化、基本的なペリフェラルの有効化など、アプリケーションコードが適切に動作するために必要な最小限のハードウェア初期化を行います。
アプリケーションのロード: 外部メモリ（例えばSPIフラッシュ）や通信インターフェース（UART, USB, Ethernetなど）から、実行すべきアプリケーションプログラムを内部フラッシュメモリやSRAMにロードします。（ただし、多くのマイクロコントローラーではアプリケーションはフラッシュに直接配置されるため、このステップは必須ではありません。）
アプリケーションへの制御移行: ロードまたは検証済みのアプリケーションコードの開始アドレスにプログラムカウンタ（PC）をジャンプさせ、アプリケーションの実行を開始します。
ファームウェアアップデート: 通信インターフェースを介して新しいアプリケーションファームウェアを受信し、フラッシュメモリに書き込む機能を提供します。これは製品の出荷後も機能追加、バグ修正、セキュリティパッチ適用などを可能にするために非常に重要です。

つまり、ブートローダーはシステムの「最初の番人」であり、アプリケーションを起動するための「踏み台」、そしてシステムを最新の状態に保つための「更新メカニズム」を担っています。

1.2 なぜSTM32開発でブートローダーが重要なのか

STM32は、家電製品から産業機器、医療機器、IoTデバイスまで、幅広い分野で使用されています。これらの製品において、ブートローダーは以下のような理由から極めて重要です。

フィールドアップデート: 製品が顧客の手に渡った後も、ファームウェアのアップデートが必要になることが頻繁にあります。新しい機能の追加、発見されたバグの修正、セキュリティ脆弱性への対応などです。ブートローダーがファームウェアアップデート機能を提供することで、製品を回収することなく、現場でのアップデートが可能になります。
製造ラインでの書き込み: 量産時には、ブートローダーを使用して製品に最初のファームウェアを効率的に書き込むことができます。
開発・デバッグ効率: 開発段階でも、ブートローダーを介して新しいファームウェアを簡単にターゲットデバイスに書き込むことができます。
システムの回復: アプリケーションコードに深刻なバグがあっても、ブートローダーが無事であれば、新しいファームウェアを書き込んでシステムを回復させることができます。
セキュリティ: ブートローダーは、不正なファームウェアの実行を防ぐためのセキュアブート機能や、通信データの暗号化・署名検証機能などを実装するのに最適な場所です。

STM32は豊富なペリフェラルとメモリ、そして多様な起動オプションを備えているため、ROMに内蔵されたブートローダーを利用することも、特定の要件に合わせてカスタムブートローダーを開発することも可能です。これらの選択肢を理解し、プロジェクトに最適な方法を選択することが、STM32開発成功の鍵となります。

第2部：ブートローダーの基本原理とSTM32の起動プロセス

ブートローダーの動作を理解するためには、マイクロコントローラー、特にCortex-Mコアを持つSTM32の基本的な起動プロセスとメモリ構成を知る必要があります。

2.1 マイクロコントローラーの起動プロセス

一般的なマイクロコントローラー、特にCortex-Mコアを持つSTM32の起動プロセスは以下のようになります。

リセット: 電源投入またはリセット信号がアサートされると、CPUはリセット状態になります。
リセットベクタの取得: リセット解除後、CPUは特定の固定アドレス（リセットベクタ）から、次に実行すべき命令のアドレスを取得します。この固定アドレスは、通常、プログラムメモリの先頭近くに配置されます。
スタックポインタ(SP)とプログラムカウンタ(PC)の設定: Cortex-Mアーキテクチャでは、リセットベクタから取得される最初の32ビット値はメインスタックポインタ(MSP)の初期値、次の32ビット値はリセットハンドラ（プログラムの最初のエントリポイント）のアドレスとなります。CPUはこれらの値を用いて、SPとPCを初期化します。
リセットハンドラの実行: PCがリセットハンドラのアドレスを指すようになり、CPUはここから命令の実行を開始します。このリセットハンドラは通常、C言語で記述されたmain関数を実行するためのCランタイム初期化処理（グローバル変数や静的変数の初期化、ヒープ領域の設定など）を行います。
ブートローダーまたはアプリケーションの実行: リセットハンドラによる初期化が完了すると、プログラムはユーザーが記述したコードのメインエントリポイント（例えばmain関数）にジャンプします。この最初に実行されるユーザーコードが、ブートローダーまたは直接アプリケーションコードとなります。

2.2 メモリ構成とブートローダーの関係

STM32には、主に以下の種類のメモリがあります。

フラッシュメモリ (Flash Memory): プログラムコードや定数を格納するための不揮発性メモリです。電源が切れても内容が保持されます。アプリケーションコードやブートローダーコードは通常、このフラッシュメモリに書き込まれます。フラッシュメモリは、SRAMに比べて読み出しは高速ですが、書き込みや消去は時間がかかり、特定の領域（ページまたはセクタ）単位で行う必要があります。また、書き込み/消去回数には上限があります。
SRAM (Static Random Access Memory): 変数、スタック、ヒープなどを格納するための揮発性メモリです。電源が切れると内容は失われます。CPUが直接読み書きでき、アクセス速度はフラッシュメモリより高速です。
システムメモリ (System Memory): STM32のROM領域に格納されている、STMicroelectronicsによって書き込まれた不揮発性の領域です。ここにROMブートローダーが格納されています。ユーザーはこの領域を直接書き換えることはできません。

ブートローダーは通常、フラッシュメモリの特定のアドレス範囲に配置されます。システムの起動時、CPUはどのメモリ領域から実行を開始するかを判断し、その領域の先頭にあるベクタテーブルを参照して、SPの初期値とリセットハンドラのアドレスを取得します。

2.3 ベクタテーブルとVTORレジスタ

Cortex-Mコアは、割り込みや例外（リセットを含む）発生時にジャンプすべきアドレスを定義した「ベクタテーブル」を持っています。このテーブルは、通常、プログラムメモリの先頭アドレス（アドレス0x08000000など）に配置されます。ベクタテーブルの先頭には、MSPの初期値とリセットハンドラのアドレスが格納されています。

“`c
// ベクタテーブルの概念図（簡略化）
typedef struct {
uint32_t initial_sp_value; // [0x00] 初期スタックポインタ値
uint32_t reset_handler; // [0x04] リセットハンドラのアドレス
uint32_t nmi_handler; // [0x08] NMI ハンドラのアドレス
uint32_t hard_fault_handler; // [0x0C] ハードフォールトハンドラのアドレス
// … その他の例外・割り込みハンドラのアドレスが続く
} VectorTable;

// フラッシュメモリの先頭に配置される（通常）
const VectorTable g_pfnVectors @0x08000000;
“`

STM32を含む多くのCortex-Mマイクロコントローラーには、Vector Table Offset Register (VTOR) というレジスタがあります。このレジスタを使用することで、ベクタテーブルの配置場所をデフォルトの先頭アドレス（通常0x08000000または0x00000000にマップされる）から、フラッシュメモリ内の別のアドレスやSRAM内のアドレスに変更（リマップ）できます。

カスタムブートローダーを開発する際、ブートローダー自身のベクタテーブルと、ブートローダーが起動するアプリケーションのベクタテーブルは、フラッシュメモリ内の異なるアドレスに配置されます。ブートローダーは起動時にVTORレジスタを自身のベクタテーブルのアドレスに設定し、アプリケーションに制御を移す際にはVTORレジスタをアプリケーションのベクタテーブルのアドレスに設定し直します。これにより、リセットや割り込み発生時に、適切にブートローダーまたはアプリケーションのハンドラが呼び出されるようになります。

第3部：STM32のROMブートローダー詳解

STM32マイクロコントローラーは、STMicroelectronicsがあらかじめチップのシステムメモリ（ROM）に書き込んだブートローダーを内蔵しています。これはSystem Memory Bootloader または ROM Bootloader と呼ばれ、ユーザーがコードを開発することなく、外部インターフェースを介してフラッシュメモリをプログラミングできる非常に便利な機能です。

3.1 起動モードの設定（BOOT0, BOOT1ピン）

STM32は、特定のピンの状態（主にBOOT0ピンとBOOT1ピン）を確認することで、リセット後の起動元を選択します。ピンの状態は、電源投入またはリセット解除時にサンプリングされます。

BOOT0 ピンの状態	BOOT1 ピンの状態	起動元
0 (Low)	x (Don’t care)	メインフラッシュ
1 (High)	0 (Low)	システムメモリ
1 (High)	1 (High)	SRAM

メインフラッシュからの起動: BOOT0ピンをLowに設定すると、CPUはメインフラッシュメモリ（通常アドレス0x08000000から始まる）の先頭から実行を開始します。ここにユーザーアプリケーションコードが配置されます。
システムメモリからの起動: BOOT0ピンをHigh、BOOT1ピンをLowに設定すると、CPUはシステムメモリ（ROM）に格納されたROMブートローダーを実行します。これにより、外部ツールを使ってフラッシュメモリの内容を読み書きしたり消去したりできます。
SRAMからの起動: BOOT0ピンをHigh、BOOT1ピンをHighに設定すると、CPUはSRAMの先頭（通常アドレス0x20000000から始まる）から実行を開始します。これはデバッグや特定の用途に使用されますが、SRAMは揮発性のため、恒久的なプログラム起動には使用できません。

多くのボードでは、BOOT0ピンはジャンパピンやスイッチで簡単に切り替えられるようになっています。BOOT1ピンはしばしばGNDに接続されています。製品として出荷する際は、通常BOOT0ピンをLowに設定し、メインフラッシュからアプリケーションが起動するようにします。

注意: BOOTピンの具体的な名称やデフォルトの接続、内部プルアップ/プルダウン抵抗の有無は、STM32のシリーズや特定の製品によって異なる場合があります。データシートで確認が必要です。また、一部の新しいSTM32では、BOOTピンの代わりにまたは加えて、Option Bytesで起動モードを設定できるものもあります。

3.2 サポートされているインターフェース

STM32のROMブートローダーは、外部ホスト（PCなど）との通信のために、いくつかの標準的なシリアルインターフェースをサポートしています。これにより、特別なハードウェアデバッガー（JTAG/SWD）がなくても、標準的な変換ケーブルを使ってファームウェアを書き込むことが可能です。サポートされるインターフェースは、STM32のシリーズや製品によって異なりますが、一般的には以下のものが含まれます。

UART (Universal Asynchronous Receiver/Transmitter): 最も一般的で広くサポートされているインターフェースです。Tx/Rxピンを使用して、シンプルなシリアル通信を行います。TTLレベルのUART信号をPCのUSBに接続するには、USB-シリアル変換アダプター（例: FTDI, CP2102チップを使ったもの）が必要です。通信設定（ボーレート、データビット、パリティ、ストップビット）は、通常ツールが自動的に検出するか、手動で設定します。
I2C (Inter-Integrated Circuit): SCL/SDAピンを使用して通信します。組み込みシステム内で別のマイクロコントローラーやホストプロセッサーからSTM32をプログラミングする場合などに使用されることがあります。
SPI (Serial Peripheral Interface): SCK, MISO, MOSIピンを使用して通信します。高速なシリアル通信が可能ですが、UARTほど一般的ではありません。
USB DFU (Device Firmware Upgrade): USBインターフェースを備えたSTM32でサポートされます。PCとUSBケーブルで直接接続し、標準的なDFUプロトコルを使用してファームウェアを更新できます。特別な変換アダプターが不要なため、近年よく利用されています。STM32CubeProgrammerなどのツールがDFUモードのデバイスを自動的に認識します。
CAN (Controller Area Network): 一部の産業用向けSTM32などでサポートされている場合があります。

これらのインターフェースを使用する場合、対応するSTM32のピンをブートローダーがアクセスできるように設定する必要があります。通常、これらのピンはデフォルトで設定されています。

3.3 通信プロトコル

ROMブートローダーとの通信は、シンプルなコマンド/レスポンス形式で行われます。ホスト（PC上のプログラミングツール）がコマンドを送信し、STM32のブートローダーがそれに応答します。

基本的なコマンドには以下のようなものがあります（詳細はSTM32のアプリケーションノートAN2606を参照してください）。

GET: ブートローダーのバージョン、対応コマンド、チップIDなどを取得します。
GET_VERSION: ブートローダーのバージョンとオプションバイトの値を古いコマンドセットで取得します。
GET_ID: チップの製品IDを取得します。
READ_MEMORY: 指定されたアドレスからメモリの内容を読み出します。
GO: 指定されたアドレスにジャンプしてアプリケーションの実行を開始します。
WRITE_MEMORY: 指定されたアドレスにデータを書き込みます（通常フラッシュメモリ）。書き込み前に消去が必要な場合があります。
ERASE: 指定されたページまたはセクタを消去します。チップ全体消去（Mass Erase）も可能です。
WRITE_UNPROTECT: フラッシュメモリの書き込み保護を解除します。
READ_PROTECT: フラッシュメモリの読み出し保護を設定します。
READ_UNPROTECT: フラッシュメモリの読み出し保護を解除します。

通信はバイト単位で行われ、コマンドを受信するとSTM32は成功 (ACK, 0x79) または失敗 (NACK, 0x1F) を応答します。データ転送時には、データ長やアドレス情報などがやり取りされます。UART通信の場合、最初のバイトでボーレートを自動検出するためのメカニズムが備わっています。

3.4 ROMブートローダーの使い方（ツール）

ROMブートローダーを使用してSTM32にファームウェアを書き込むためのツールはいくつかあります。

Flash Loader Demonstrator: STMicroelectronicsが提供していたGUIツールです。主にUARTインターフェースを使用します。古いツールですが、一部の古いプロジェクトやユーザーに今でも使われています。
STM32CubeProgrammer: STMicroelectronicsが現在推奨する統合プログラミングツールです。JTAG/SWD、UART、USB DFU、CANなど、多くのインターフェースに対応しています。GUI版とCLI (Command Line Interface) 版があり、開発時だけでなく製造ラインでの書き込みにも利用できます。STM32CubeProgrammerを使えば、ファームウェアの書き込み、読み出し、消去、オプションバイトの設定、OTP (One-Time Programmable) 領域の操作、ファームウェア更新時の署名検証（対応デバイス/ファームウェアの場合）など、様々な操作が可能です。

これらのツールを使用する際は、ターゲットとなるSTM32ボードとPCを、適切なインターフェース（UART-USB変換、またはUSBケーブル）で接続し、BOOT0ピンをSystem Memory Bootモードに設定してリセットする必要があります。ツールの設定画面で、接続インターフェース、ポート、通信パラメータ（UARTの場合）を選択し、デバイスに接続します。接続が成功すれば、ファームウェアファイル（.hex, .srec, .binなど）を指定して書き込み操作を実行できます。

3.5 ROMブートローダーのメリットとデメリット

メリット:

開発不要: STが提供するため、ユーザー自身でブートローダーコードを開発する必要がありません。
手軽なアップデート: 開発段階やフィールドでの手軽なファームウェア書き込み手段として利用できます。
製造ラインでの利用: 量産時の初期ファームウェア書き込みに広く利用されています。
システムの回復: アプリケーションが破損しても、ROMブートローダーから起動して新しいファームウェアを書き込むことでシステムを回復できます。

デメリット:

機能限定: サポートされるインターフェースや機能は固定されており、独自の通信プロトコルやアップデート方法（例えばOTA）を実装することはできません。
インターフェースの制約: ファームウェアアップデートのためには、物理的に対応するインターフェース（UART, USBなど）に接続する必要があります。Wi-FiやBluetooth経由でのアップデートはできません。
セキュリティ機能の不足: ROMブートローダー自体は、受信するファームウェアの署名検証や暗号化解除機能を持っていません（一部の新しいSecure MCUを除く）。不正なファームウェアが書き込まれるリスクがあります。
カスタマイズ不可: ソースコードが提供されないため、振る舞いを変更したり、独自の機能を追加したりすることはできません。

これらのデメリットがプロジェクトの要件と合わない場合、カスタムブートローダーの開発が必要になります。

第4部：カスタムブートローダーの開発

ROMブートローダーの機能では不十分な場合、ユーザー自身でブートローダーを開発する必要があります。カスタムブートローダーは、独自の通信インターフェース、独自のアップデートプロトコル、高度なセキュリティ機能（署名検証、暗号化）、OTA機能などを実装するための基盤となります。

4.1 なぜカスタムブートローダーが必要か

カスタムブートローダーを開発する主な理由は以下の通りです。

OTA (Over-The-Air) アップデート: Wi-Fi, Bluetooth, Cellular (LTE-M, NB-IoT), LoRaWANなどの無線通信経由でファームウェアを更新する場合。ROMブートローダーは無線通信スタックを持たないため、カスタム実装が必要です。
独自のインターフェース/プロトコル: CAN, EtherCAT, RS485, または独自の有線/無線プロトコルでアップデートを行う場合。
高度なセキュリティ要件:
- セキュアブート: 起動時にブートローダー自身およびアプリケーションの整合性を検証し、不正なコードの実行を防ぐ。
- ファームウェア署名検証: アップデートされるファームウェアが正規のものであることを、暗号署名を用いて検証する。
- ファームウェア暗号化: ファームウェアファイルを暗号化し、不正な読み出しや改ざんを防ぐ。
特定用途の機能: 複数アプリケーションの管理、異なる設定情報のロード、フィールドでの簡易診断機能など。
特別な起動シーケンス: アプリケーションの起動前に複雑な初期化やチェックが必要な場合。
製品体験の向上: エンドユーザーが簡単にファームウェアを更新できる仕組みを提供する。

4.2 カスタムブートローダー開発のステップ

カスタムブートローダーの開発は、通常のアプリケーション開発とは異なる考慮事項がいくつかあります。主要なステップを以下に示します。

ステップ1：要件定義

どのような方法でファームウェアをアップデートするか？ (UART, USB, Ethernet, Wi-Fi, BLEなど)
アップデートファイルの形式は？ (バイナリ、SREC, 特殊フォーマット)
どのようなセキュリティ要件があるか？ (署名検証、暗号化)
アップデート中のエラー発生時のリカバリ方法は？ (旧バージョンで起動、待機、エラー通知)
ブートローダー自体のアップデートは必要か？ (必要ならより複雑になる)
ブートローダーはどのくらいのメモリサイズを占有できるか？

ステップ2：メモリマップの設計

フラッシュメモリをどのように分割して使用するかを決定します。これはカスタムブートローダー開発において最も重要なステップの一つです。

ブートローダー領域: ブートローダー自身のコード、データ、スタック、ヒープが配置される領域です。通常、フラッシュメモリの先頭（0x08000000から始まる）に配置されます。この領域は保護され、通常はブートローダー自身以外からは書き換えられないようにします。
アプリケーション領域: メインアプリケーションのコード、データ、スタック、ヒープが配置される領域です。ブートローダー領域の直後に配置されることが多いです。アップデートの対象となる領域です。
データ領域: 設定情報、ログ、アップデートデータの一時保存領域など、アプリケーションやブートローダーが使用するデータを格納する領域です。フラッシュメモリの最後の部分を使用したり、特定のページを確保したりします。
アップデートデータ一時保存領域 (OTAの場合): OTAアップデートの場合、新しいファームウェアを受信中に一時的に保存するための領域が必要です。デュアルバンク方式の場合は別のバンク全体、シングルバンク方式の場合は専用のダウンロード領域を使用します。

各領域の開始アドレスとサイズを確定します。これらのアドレスは、後述するリンカスクリプト、ブートローダーコード、およびアプリケーションコードの両方で参照されます。

ステップ3：開発環境のセットアップ

IDE: STM32CubeIDE (GCC), Keil MDK (Arm Compiler), IAR Embedded Workbench (IAR Compiler) など、STM32開発をサポートするIDEを選択します。
コンパイラ: 選択したIDEに含まれるコンパイラを使用します。
リンカスクリプト: ブートローダーとアプリケーション用に、別々のリンカスクリプト（または設定ファイル）を作成または編集します。これが、ステップ2で設計したメモリマップに従ってコードを配置する鍵となります。リンカスクリプトでは、コード (.text)、読み取り専用データ (.rodata)、初期化済みデータ (.data)、初期化されていないデータ (.bss)、スタック、ヒープなどの各セクションを、フラッシュメモリやSRAMの特定のアドレス範囲に配置するよう指示します。ブートローダーのリンカスクリプトでは、フラッシュの開始アドレスを0x08000000とし、ブートローダーのサイズ分の領域を使用するように設定します。アプリケーションのリンカスクリプトでは、フラッシュの開始アドレスをブートローダー領域の直後のアドレスに設定します。

ステップ4：コードの実装

カスタムブートローダーの主要な構成要素を実装します。

起動処理:
- CPUリセット後、最初に実行されるリセットハンドラからブートローダーのmain関数が呼び出されます。
- SystemInit()の実行。これはSTM32CubeFWに含まれる関数で、クロックやフラッシュ設定など、基本的なハードウェア初期化を行います。ROMブートローダーと異なり、ユーザーコード内のSystemInitが実行されます。
- ベクタテーブルのリマップ: 最も重要な処理の一つです。デフォルトではベクタテーブルはアドレス0x08000000（またはリマップされた0x00000000）にありますが、ブートローダーが0x08000000から起動する場合、ベクタテーブルはブートローダー自身のものがそこに配置されます。アプリケーションにジャンプする際、割り込みや例外が発生した場合にアプリケーション側のハンドラが実行されるように、VTORレジスタをアプリケーションのベクタテーブルのアドレスに設定し直す必要があります。しかし、ブートローダーの起動時は、ブートローダー自身のベクタテーブルが使われるようにVTORを設定する必要はありません。なぜなら、ブートローダーがフラッシュの先頭（0x08000000）に配置されている場合、CPUはデフォルトでその場所のベクタテーブルを参照するからです。VTORの設定が必要になるのは、ブートローダーがSRAMから起動する場合や、カスタムブートローダー自身がフラッシュの先頭以外に配置される特殊なケースです。一般的なフラッシュ先頭配置カスタムブートローダーの場合は、起動時のVTOR設定は不要です。アプリケーションへジャンプする際にVTORを設定します。
アップデート待機・通信処理:
- 指定された通信インターフェース（UART, USB, Ethernetなど）を初期化します。
- 外部ホストからのアップデート要求やデータ受信を待ちます。
- 独自の通信プロトコルに従ってコマンドやデータをやり取りします。
- タイムアウト処理やエラーハンドリングを実装します。
フラッシュメモリ書き込み/消去処理:
- 受信した新しいファームウェアデータをフラッシュメモリのアプリケーション領域に書き込むための処理です。
- 消去: フラッシュメモリはページ/セクタ単位でしか消去できません。書き込みを行う前に、該当するアプリケーション領域全体または必要なページ/セクタを消去します。
- 書き込み: フラッシュメモリへの書き込みは、通常、ワード（32ビット）またはハーフワード（16ビット）単位で行われます。書き込みバッファを使用したり、書き込み完了を待機したりする必要があります。フラッシュへの書き込み中は、割り込みが無効になるなど、CPUの動作に制約がある場合があります。STM32CubeFWのHAL/LLドライバを使用すると、これらの低レベルな処理を抽象化できます。
- プロテクト: 必要に応じて、ブートローダー領域に書き込み保護を設定し、誤った操作によるブートローダーの破損を防ぎます。アプリケーション領域にも読み出し/書き込み保護を設定できます。
受信データ検証:
- 受信したファームウェアデータが破損していないか、改ざんされていないかを確認します。
- CRC (Cyclic Redundancy Check): データ破損検出に有効です。比較的単純で高速です。
- ハッシュ (Hash): MD5, SHA-256など。データの同一性検証に使用します。改ざん検出に優れています。
- 署名検証 (Signature Verification): セキュアブートに不可欠です。公開鍵暗号（RSA, ECDSAなど）を使用して、ファームウェアファイルに付与されたデジタル署名を検証し、正規の秘密鍵で署名されたオリジナルのファイルであることを証明します。
アプリケーションへのジャンプ処理:
- 新しいファームウェアの書き込みと検証が成功した後、アプリケーションを実行するために制御を移します。
- 割り込みの無効化: ブートローダーが有効にした割り込みをすべて無効化します。
- ペリフェラルのリセット/無効化: ブートローダーが使用したペリフェラルを無効化したり、リセット状態に戻したりします。（必須ではありませんが、アプリケーションがクリーンな状態で開始できるよう推奨されます。）
- VTORの設定: VTORレジスタを、フラッシュメモリ内のアプリケーションのベクタテーブルの開始アドレスに設定します。
- スタックポインタ(SP)の設定: アプリケーションのベクタテーブルの先頭（オフセット0x00）に格納されている、アプリケーションで使用するスタックポインタの初期値を読み出し、__set_MSP()などのアセンブリ関数や組み込み関数を使用してCPUのスタックポインタを設定します。
- プログラムカウンタ(PC)のジャンプ: アプリケーションのベクタテーブルの2番目（オフセット0x04）に格納されている、アプリケーションのリセットハンドラのアドレス（アプリケーションのエントリポイント）を読み出します。このアドレスを取得したら、関数ポインタにキャストして呼び出すことで、アプリケーションの実行を開始します。この際、ARM Cortex-MではThumbモードで実行するため、アドレスの最下位ビットを1にする必要があります（ただし、通常はリンカが生成するアドレスがThumbコードを指すように設定されているため、明示的な操作は不要な場合が多いです）。安全のため、最下位ビットをOR演算で1にする記述がよく見られます。
“`c
// アプリケーション開始アドレス (例: ブートローダーが16KB占有する場合)

define APP_START_ADDRESS 0x08004000

// アプリケーションへジャンプする関数
void JumpToApplication(void) {
// 1. 全ての割り込みを無効化 (または必要なもの以外)
// NVIC_DisableIRQ(ALL_IRQS…); または __disable_irq();
// SYSCFG->MEMRMP = …; // メモリリマップをフラッシュに再設定（必要なら）
```
// 2. アプリケーションのベクタテーブルをVTORに設定
SCB->VTOR = APP_START_ADDRESS;

// 3. アプリケーションの初期スタックポインタを取得
// ベクタテーブルの最初の要素がSPの初期値
uint32_t app_stack_ptr = *(uint32_t*)APP_START_ADDRESS;

// 4. アプリケーションのエントリポイント（リセットハンドラ）を取得
// ベクタテーブルの2番目の要素がリセットハンドラのアドレス
uint32_t app_entry_point = *(uint32_t*)(APP_START_ADDRESS + 4);

// 5. アプリケーションのスタックポインタを設定
__set_MSP(app_stack_ptr);

// 6. アプリケーションのエントリポイントへジャンプ
// アドレスを関数ポインタにキャストして呼び出し。
// Cortex-MではThumbモード実行のため、アドレス最下位ビットは1にする(& ~0x01 を外すか、結果に | 1)。
// リンカが生成するアドレスは通常既にThumbを考慮しているため、そのまま使うのが安全。
void (*app_entry)(void);
app_entry = (void*)app_entry_point; // アドレスを関数ポインタに変換

app_entry(); // アプリケーション実行開始！
```
}
“`
* エラーハンドリング:
* 通信エラー、データ検証失敗、フラッシュ書き込み失敗など、様々なエラーが発生する可能性があります。
* エラー発生時のリカバリ戦略（再試行、エラー通知、旧バージョンでの起動、待機モードへの移行など）を実装します。
* フラッシュ書き込み中に電源が失われた場合の対応も考慮が必要です（一部が書き込まれた中途半端な状態）。
* ブートローダーの起動条件:
* カスタムブートローダーは、通常起動時（BOOT0=Low）に実行されます。
* ブートローダーがアプリケーションを起動するか、アップデートモードに入るかを決定するロジックが必要です。
* この決定は、特定のピンの状態、SRAM内の特定のフラグ、RTCバックアップレジスタの値、外部コマンド受信など、様々な方法で行われます。例えば、「SRAMの特定の番地に特定の値を検出したらアップデートモードに入る」といった実装が一般的です。これにより、アプリケーションからソフトウェア的にブートローダーを起動させることができます。

ステップ5：セキュリティ考慮事項

カスタムブートローダーでは、ROMブートローダーでは不足していたセキュリティ機能を強化できます。

セキュアブート: 起動時にブートローダーが自身の整合性を検証し、次にロードまたは実行するアプリケーションコードの署名を検証するプロセスです。これにより、不正なコードの実行を防止します。
ファームウェア署名検証: アップデートされるファームウェアファイルにデジタル署名（例：ECDSA, RSA）を付与し、ブートローダーが内蔵する公開鍵でその署名を検証します。これにより、アップデートファイルが正規のソースから来ており、改ざんされていないことを確認できます。
暗号化: ファームウェアファイル自体を暗号化し、通信路や保存中の盗聴・改ざんから保護します。ブートローダーで復号化してからフラッシュに書き込みます。
RDP (Read Protection): STM32のオプションバイトで設定できるフラッシュ読み出し保護レベルです。レベル1（デバッグポートからの読み出し禁止）やレベル2（デバッグポートおよびブートローダーからの読み出し禁止、工場出荷時状態への戻しが困難になる場合あり）を設定することで、フラッシュの内容（特にブートローダーやアプリケーションコード、秘密情報）を保護できます。

ステップ6：デバッグとテスト

カスタムブートローダーは、システムの根幹に関わるため、徹底的なデバッグとテストが必要です。

デバッグ環境: JTAG/SWDデバッガーを使用して、ブートローダーコードの実行をステップ実行し、レジスタやメモリの内容を確認します。IDE上でブートローダープロジェクトを開いてデバッグします。アプリケーションへのジャンプ処理後のデバッグは、アプリケーションプロジェクトに切り替えるか、マルチプロジェクトデバッグ設定が必要です。
テストケース:
- 正常なファームウェアアップデートが完了し、アプリケーションが正しく起動すること。
- サイズ超過や不足のファイル。
- 破損したファイル（CRC/ハッシュ不一致）。
- 不正な署名が付与されたファイル。
- フラッシュ書き込み中の電源断。
- 通信が途中で中断された場合。
- ブートローダーが正しくアップデートモードに入るか、アプリケーションモードにジャンプするか。
- アプリケーションからブートローダーをソフトウェア起動できるか。

4.3 リンカスクリプトの重要性

前述の通り、カスタムブートローダーとアプリケーションは、フラッシュメモリ内の異なる領域に配置する必要があります。リンカスクリプトは、コンパイル済みのコード、データ、スタック、ヒープなどの各セクションを、ターゲットデバイスのメモリマップに従って配置するための指示ファイルです。

ブートローダーのリンカスクリプト: フラッシュメモリの開始アドレス（通常0x08000000）をプログラムメモリの開始として定義し、ブートローダーのコードとデータをその領域に配置します。スタックとヒープはSRAMに配置します。
アプリケーションのリンカスクリプト: フラッシュメモリの開始アドレスを、ブートローダー領域の直後のアドレス（例: 0x08000000 + ブートローダーサイズ）として定義し、アプリケーションのコードとデータをその領域に配置します。スタックとヒープはSRAMに配置します。アプリケーションのSRAM使用領域は、ブートローダーと重ならないように設計する必要があります。

リンカスクリプトを誤ると、コードが意図しないアドレスに配置されたり、ブートローダーとアプリケーションの領域が衝突したりして、正しく動作しなくなります。IDEによってはリンカスクリプトをGUIで編集できる機能がありますが、複雑なメモリマップでは手動での編集が必要になる場合もあります。

4.4 ベクタテーブルリマップの実装方法

アプリケーションへジャンプする際に、VTORレジスタをアプリケーションのベクタテーブルのアドレスに設定し直す必要があります。Cortex-Mコアでは、SCB->VTORレジスタにベクタテーブルの開始アドレスを書き込むことでリマップできます。このレジスタはSRAMとフラッシュの両方のアドレスを指すことができます。

“`c
// アプリケーションのフラッシュ開始アドレス

define APP_START_ADDRESS 0x08004000

// アプリケーションへジャンプする関数（再掲）
void JumpToApplication(void) {
// … 割り込み無効化など …

// アプリケーションのベクタテーブル開始アドレスをVTORに設定
SCB->VTOR = APP_START_ADDRESS;

// ... スタックポインタ設定、エントリポイント取得、ジャンプ ...

}
“`

この処理により、ジャンプ後に発生した割り込みや例外は、アプリケーション領域にあるベクタテーブルを参照して、アプリケーション側のハンドラが実行されるようになります。

4.5 アプリケーションからのブートローダー起動方法

カスタムブートローダーは、電源投入リセット時に自動的に実行されるだけでなく、実行中のアプリケーションからソフトウェア的に起動される必要もあります。これは、アプリケーションがファームウェアアップデートの必要性を検知したり、ユーザーの操作によってアップデートモードに移行したりする場合に必要です。

一般的な方法は、特定の永続的なメモリ領域（SRAMの特定アドレスやRTCバックアップレジスタ）にフラグを設定し、システムをリセットすることです。ブートローダーは起動時にこのフラグをチェックし、フラグが設定されていればアップデートモードに移行し、設定されていなければアプリケーションにジャンプします。

“`c
// SRAM内の特定の領域をフラグとして使用する例
// リンカスクリプトでこの領域を確保しておく

define BOOTLOADER_REQUEST_FLAG_ADDRESS (SRAM_BASE + 0x1000) // SRAMの安全なオフセット

define BOOTLOADER_REQUEST_VALUE 0x12345678 // 特定の値

// アプリケーション側からブートローダーを起動する関数
void RequestBootloaderMode(void) {
// 特定のフラグを設定
(uint32_t)BOOTLOADER_REQUEST_FLAG_ADDRESS = BOOTLOADER_REQUEST_VALUE;

// システムをソフトウェアリセット
NVIC_SystemReset();

}

// ブートローダー側の起動判断ロジック（main関数内など）
int main(void) {
// … ハードウェア初期化など …

// フラグをチェック
if (*(uint32_t*)BOOTLOADER_REQUEST_FLAG_ADDRESS == BOOTLOADER_REQUEST_VALUE) {
    // フラグをクリア
    *(uint32_t*)BOOTLOADER_REQUEST_FLAG_ADDRESS = 0;

    // アップデートモードに入る
    EnterUpdateMode();
} else {
    // アプリケーションへジャンプ
    JumpToApplication();
}

// ここには通常到達しない
while (1);

}
“`

RTCバックアップレジスタはバッテリーで保持されるため、電源が完全に切断されてもフラグが失われないという利点があります。どちらの方法を選択するかは、システムの要件によります。

第5部：応用例 – OTAアップデートの実装

OTA (Over-The-Air) アップデートは、無線通信経由でファームウェアを更新する機能であり、カスタムブートローダーの最も一般的な応用例の一つです。物理的な接続なしに製品をアップデートできるため、保守コスト削減や迅速な対応が可能になります。

5.1 OTAのメリットと課題

メリット:

利便性: 製品を回収したり、物理的に接続したりすることなくアップデートできます。
コスト削減: 現場での作業員によるアップデートコストを削減できます。
迅速な対応: セキュリティ脆弱性への対応や緊急のバグ修正を迅速に展開できます。
ユーザー体験: 最新の機能や改善をユーザーに提供できます。

課題:

信頼性: 無線通信は不安定になる可能性があり、アップデート中に通信が切断された場合でもシステムが破壊されないように Robustness が求められます。
セキュリティ: 無線通信は盗聴や改ざんのリスクが高いため、強力なセキュリティ対策（暗号化、署名検証）が必須です。
メモリ制約: 新しいファームウェアを一時的に保存するための領域が必要になることが多く、フラッシュメモリの容量が限られている場合があります。
消費電力: 無線通信の受信は消費電力が大きいため、バッテリー駆動デバイスではアップデート中の電力管理が課題となります。
複雑性: 実装がカスタムブートローダーの中でも特に複雑になります。

5.2 OTAアップデートの実装方式

STM32でOTAアップデートを実現するための一般的なフラッシュメモリの管理方式は以下の通りです。

デュアルバンク方式 (Dual Bank):
- フラッシュメモリをほぼ等しいサイズの2つの領域（バンクAとバンクB）に分割します。
- 片方のバンク（例: バンクA）で現在のアプリケーションを実行している間に、もう一方のバンク（例: バンクB）に新しいファームウェアを受信して書き込みます。
- 書き込みが完了し、検証に成功したら、次回の起動時にどちらのバンクから起動するかを示すフラグ（オプションバイトなど）を書き換えます。
- 次回の起動時に、ブートローダーがフラグを確認し、新しいバンク（バンクB）からアプリケーションを起動します。
- 新しいアプリケーションが正常に起動・動作することを確認した後、必要であれば古いバンク（バンクA）を消去して、次のアップデートに備えます。
- メリット: アップデート中に問題が発生しても、古いバンクのアプリケーションは無傷であるため、簡単に旧バージョンにロールバックできます。非常に Robust です。
- デメリット: 同じサイズのフラッシュ領域が2つ必要になるため、必要なフラッシュ容量が大きくなります。
シングルバンク + ダウンロード領域方式 (Single Bank + Download Area):
- フラッシュメモリを、ブートローダー領域、アプリケーション実行領域、そして新しいファームウェアを一時的にダウンロードして保存するためのダウンロード領域に分割します。
- ブートローダーは、ダウンロード領域に新しいファームウェアを受信して書き込みます。
- ダウンロードが完了し、検証に成功したら、アプリケーション実行領域を消去し、ダウンロード領域の内容を実行領域にコピー（スワップ）します。
- コピー完了後、アプリケーション実行領域から新しいファームウェアを起動します。
- メリット: デュアルバンク方式よりも必要なフラッシュ容量が少なくて済みます（ダウンロード領域のサイズはアプリケーションサイズと同じかそれ以上必要）。
- デメリット: アプリケーション実行領域を消去してから書き込む必要があるため、アップデート中の電源断やエラー発生でシステムが完全に破壊されるリスクが高くなります。リカバリメカニズムの実装がより重要になります。コピー処理に時間がかかる場合があります。

STM32の一部シリーズ（例: STM32L4シリーズの特定製品）は、ハードウェアレベルでデュアルバンクフラッシュをサポートしており、オプションバイトで起動バンクを簡単に切り替えられます。これにより、デュアルバンク方式の実装が容易になります。

5.3 セキュリティ対策

OTAアップデートにおいては、以下のセキュリティ対策が特に重要です。

ファームウェア署名: アップデートされるファームウェアは、必ず発行元（開発元）の秘密鍵で署名されている必要があります。ブートローダーは、デバイスに内蔵された公開鍵でこの署名を検証し、正規のファームウェアであることを確認した上で書き込みを行います。署名検証に失敗したファームウェアは破棄します。これにより、中間者攻撃による不正なファームウェアの注入を防ぎます。
通信路の暗号化: ファームウェアのダウンロードには、HTTPS (HTTP over TLS/SSL) や MQTTS (MQTT over TLS/SSL) など、通信路を暗号化するプロトコルを使用します。これにより、通信内容の盗聴や改ざんを防ぎます。
デバイス認証: アップデートサーバーは、アップデート要求元のデバイスが正規のものであることを認証する必要があります（例: TLSクライアント認証、APIキー）。
ファームウェアファイルの暗号化: 通信路の暗号化に加えて、ファームウェアファイル自体をAESなどの共通鍵暗号で暗号化し、ブートローダーで復号化するという二重の対策も有効です。これにより、保存されている暗号化ファイルが漏洩しても内容がすぐに解析されることを防ぎます。
ロールバック防止: 一度新しいバージョンのファームウェアにアップデートしたら、それより古い（セキュリティ脆弱性などが含まれている可能性のある）バージョンには簡単に戻せないようにするメカニズム（バージョンチェックなど）を実装することも考慮します。

5.4 実装プロトコル例

OTAアップデートで新しいファームウェアファイルを取得するためのプロトコルとしては、以下のようなものが使用されます。

HTTP/HTTPS: シンプルなファイルダウンロードに使用できます。HTTPSを使用することで通信路を暗号化できます。
MQTT/MQTTS: IoTデバイスで広く使用される軽量な publish/subscribe プロトコルです。アップデート開始のトリガーや、アップデートステータスの通知に使用できます。ファイル自体は別の方法（HTTPなど）でダウンロードすることも、MQTTメッセージとして分割送信することも考えられます。
BLE (Bluetooth Low Energy): スマートフォンやゲートウェイ経由でローカルにアップデートを行う場合に使用されます。独自のプロトコルまたは標準的なDFUプロトコル（BLE DFU）を実装します。
Wi-Fi/Ethernet: TCP/IPスタックを実装し、HTTP/HTTPS, FTP, TFTP, または独自のプロトコルでファームウェアファイルを転送します。
LoRaWAN/NB-IoT: 低帯域幅・低消費電力なLPWAネットワークでは、ファームウェアのサイズや転送時間に大きな制約があります。通常、FOTA (Firmware Update Over The Air) という標準化された仕組みや、ペイロードを小さく分割して送信する独自の最適化プロトコルが使用されます。

OTAの実装は、選択した通信方法、プロトコル、セキュリティ要件によって大きく異なります。STM32CubeExpansion_SFUなどのSTが提供するSFU (Secure Firmware Update) 拡張パッケージは、セキュアブートとセキュアなOTAアップデートの実装を支援するフレームワークを提供しています。

第6部：セキュリティとブートローダー

ブートローダーはシステムの起動時に実行される最初のコードであるため、システムのセキュリティにおいて非常に重要な役割を果たします。不正なブートローダーやアプリケーションの実行を防ぐためのセキュリティ対策をブートローダーに組み込むことは、現代の組み込みシステム開発において不可欠です。

6.1 セキュアブート (Secure Boot)

セキュアブートとは、デバイスの起動プロセス全体を通して、実行されるコードの真正性と整合性を検証する仕組みです。カスタムブートローダーにおけるセキュアブートは、通常以下のステップで行われます。

自己検証: ブートローダーは、自身のコード領域が改ざんされていないか検証します（例: ブートローダー領域のハッシュ値を計算し、予め保存しておいた正規のハッシュ値と比較）。これにより、ブートローダー自身への攻撃を防ぎます。
アプリケーション検証: ブートローダーは、起動しようとするアプリケーションコードの署名を検証します。アプリケーション開発時に秘密鍵で署名されたファームウェアファイルに含まれる署名を、ブートローダーに内蔵された公開鍵で検証します。署名が有効であれば、アプリケーションは正規のものであり、改ざんされていないと判断し、実行を許可します。署名が無効であれば、アプリケーションの実行を拒否します。

セキュアブートを実装することで、たとえ攻撃者がフラッシュメモリにアクセスしてアプリケーションコードを書き換えたとしても、不正なコードは署名検証に失敗するため実行されません。これにより、デバイスのなりすましや不正操作を防ぐことができます。

6.2 ファームウェア署名検証

ファームウェアアップデート時に、受信したファームウェアファイルの署名を検証することは、セキュアアップデートの中核をなします。

秘密鍵と公開鍵: 開発元は秘密鍵を持ち、この秘密鍵でファームウェアファイルにデジタル署名を生成します。対応する公開鍵はデバイスのブートローダーに安全に格納されます。
署名プロセス:
1. アップデート対象のファームウェアファイルのハッシュ値（例: SHA-256）を計算します。
2. 秘密鍵を使用して、このハッシュ値を暗号化し、署名を生成します。
3. 生成された署名をファームウェアファイルに付加します。
検証プロセス (ブートローダー内):
1. 受信したファームウェアファイルから署名を分離します。
2. ファームウェアファイル本体のハッシュ値を計算します。
3. ブートローダーに内蔵された公開鍵を使用して、受信した署名を復号化します。
4. 復号化されたハッシュ値と、計算したファームウェア本体のハッシュ値を比較します。
5. 両者が一致すれば、署名は有効であり、ファームウェアは正規かつ改ざんされていないと判断し、書き込みや実行を許可します。一致しなければ、ファームウェアを破棄します。

署名検証には、楕円曲線デジタル署名アルゴリズム (ECDSA) や RSA といった非対称暗号アルゴリズムが使用されます。STM32H7などの高性能なデバイスには、ハードウェア暗号化アクセラレータが搭載されており、署名検証などの暗号処理を高速かつ安全に行うことができます。

6.3 暗号化

ファームウェアのセキュリティを強化するために、以下の暗号化手法が用いられます。

通信路の暗号化: TLS/SSLなどを使用して、ファームウェアダウンロード時の通信路を暗号化します。これにより、ネットワーク上での盗聴や中間者攻撃を防ぎます。
ファームウェアファイルの暗号化: ファームウェアファイル自体を共通鍵暗号（例: AES）で暗号化し、ストレージや通信経路上での不正な読み出し・改ざんを防ぎます。ブートローダーは、安全に格納された共通鍵でファイルを受信後に復号化してから書き込みます。

ファームウェアの暗号化は、特にファームウェアファイルが公開される可能性のあるシステムや、高い知的財産保護が求められるシステムで有効です。

6.4 RDP (Read Protection) の活用

STM32のフラッシュメモリには、Option Bytesで設定可能な読み出し保護レベル（RDP: Read Protection）があります。

レベル0: 保護なし。デバッグポートやブートローダーからフラッシュの読み出し、書き込み、消去が可能です。
レベル1: デバッグポート（JTAG/SWD）からのフラッシュ読み出しが禁止されます。ROMブートローダーやアプリケーションからの読み出しは可能です。これにより、デバッガーを使ったファームウェアの吸い出しを防ぎます。ファームウェアアップデート（書き込み）は可能です。レベル1からレベル0に戻すことも可能です（ただし、その際にMass Eraseが必要な場合があります）。
レベル2: デバッグポートからの読み出し・書き込みが完全に禁止され、ROMブートローダーからのフラッシュアクセスも制限されます。これにより、フラッシュの内容を最大限に保護します。一度レベル2に設定すると、レベル0に戻すことが非常に困難、または不可能になる場合があります（Mass Eraseによるチップ内容の完全消去が必要になるなど）。また、特定のアップデート方法が使用できなくなる可能性もあります。慎重に検討する必要があります。

カスタムブートローダーを開発する場合、自身のコード領域をRDPレベル1または2で保護することで、ブートローダー自体の改ざんを防ぐことができます。

6.5 セキュアファームウェアアップデート (SFU)

STMicroelectronicsは、セキュアブートとセキュアファームウェアアップデート（署名検証、暗号化などを含む）を包括的に実現するためのフレームワークとして、STM32CubeExpansion_SFU拡張パッケージを提供しています。これは、リファレンス実装やライブラリを含んでおり、セキュアなカスタムブートローダー（通常「セキュアブートローダー」または「更新ローダー」と呼ばれる）の開発を支援します。SFUは、安全なアップデートプロセスを実装するための複雑な詳細（メモリ管理、暗号処理APIの統合など）をカバーしており、開発者はアプリケーションロジックに集中しやすくなります。

第7部：デバッグとテスト

カスタムブートローダーの開発は複雑であり、小さなミスがデバイスを起動不能にする「文鎮化」のリスクを伴います。したがって、入念なデバッグとテストが不可欠です。

7.1 デバッグ手法

カスタムブートローダーのデバッグには、通常以下の方法が使用されます。

JTAG/SWDデバッガー: STM32CubeIDE、Keil MDK、IAR Embedded WorkbenchなどのIDEと組み合わせて使用します。ハードウェアデバッガー（ST-Linkなど）をターゲットデバイスに接続し、ブレークポイントの設定、ステップ実行、レジスタやメモリの内容参照、コールスタックの確認などを行います。
- 注意点: ブートローダーとアプリケーションは異なるメモリ領域に配置され、異なるリンカスクリプトでビルドされます。デバッグ時には、現在実行しているコード（ブートローダーかアプリケーションか）に合わせて、IDEのデバッグ設定やロードするシンボルファイルを切り替える必要があります。アプリケーションへジャンプした後もデバッグを続けるためには、VTORの設定後もデバッガーがコードを追えるように設定が必要です。
シリアルデバッグ: UARTなどを介してデバッグメッセージを出力し、ブートローダーの現在の状態や発生したエラーを確認します。デバッガーが使用できない状況（例えば、アプリケーションからのソフトウェア起動でブートローダーに入った場合）でも情報を得られるため有効です。
LED点滅パターン: 非常に原始的ですが、初期化の特定の段階やエラー発生時にLEDを点滅させるパターンを変えることで、ブートシーケンスのどこで問題が発生しているかを特定できます。

7.2 テストケース

開発したカスタムブートローダーの信頼性を確保するために、様々なテストケースを準備し実行する必要があります。

正常アップデートテスト:
- 正常なファームウェアファイルをダウンロード/転送し、検証、フラッシュへの書き込み、再起動を経て、新しいアプリケーションが正しく起動・動作することを確認します。
- 異なるバージョンのファームウェアでのアップデートを複数回繰り返します。
異常系テスト:
- 通信エラー: ファイル転送中に通信を切断したり、ノイズを混入させたりします。ブートローダーがエラーを検出し、適切に処理（再試行、中止、旧バージョン起動など）することを確認します。
- データ検証失敗: CRCが不正なファイル、署名が不正なファイルを転送します。ブートローダーが検証に失敗し、書き込みや実行を拒否することを確認します。
- フラッシュ書き込み失敗: 書き込み保護が有効な領域への書き込み、または書き込み中に意図的に電源を断つなどします。ブートローダーがエラーを検出し、フラッシュの内容が中途半端な状態で残っていないかなどを確認します。電源断テストはリカバリメカニズムが最も試されるテストです。
- ファイルサイズ不正: アプリケーション領域より大きい、または極端に小さいファイルを転送します。
- 不正なファイル形式: 定義したファイル形式と異なるデータを転送します。
- 無効なアプリケーション: 不正なベクタテーブルを持つアプリケーションや、クラッシュするアプリケーションを書き込みます。ブートローダーがアプリケーションの起動に失敗した場合のリカバリを確認します。
起動モードテスト:
- 電源投入リセット時、BOOTピン設定、ソフトウェアリセットによる起動など、想定されるすべての起動条件で、ブートローダーが正しく起動モード（アップデートモード or アプリケーションモード）を判断することを確認します。
- アプリケーションからソフトウェア的にブートローダーモードへ移行できることを確認します。

7.3 よくある課題と解決策

カスタムブートローダー開発で遭遇しやすい課題とその解決策をいくつか挙げます。

「文鎮化」のリスク: ブートローダーが破損すると、ROMブートローダーからも起動できなくなり、フラッシュ書き込みができなくなる可能性があります。
- 対策: ブートローダー領域にRDPを設定して書き込み保護をかける。開発中はRDPレベル1までにとどめる。ブートローダーアップデート機能は非常に慎重に設計・テストする（または提供しない）。最悪の場合に備え、ROMブートローダーから回復するための手順（BOOTピン設定とツール使用）を確認しておく。一部のチップでは、特定のピン操作で強制的にROMブートローダーを起動できるリカバリモードが提供されている場合があります。
メモリ不足: ブートローダーに多くの機能を詰め込むと、サイズが大きくなり、アプリケーション領域を圧迫したり、ブートローダー自身の開発が困難になったりします。
- 対策: ブートローダーは必要最小限の機能に絞る。コードサイズ最適化オプションを有効にする。使用しないライブラリ機能は無効にする。外部フラッシュなどを一時保存領域として活用する。
フラッシュ書き込みの信頼性: フラッシュ書き込み中の電源断などが原因でデータが破壊される可能性があります。
- 対策: 書き込み前に領域を完全に消去する。書き込み後にデータの整合性を検証する。重要なメタデータ（アップデート状態、バージョン情報）はフラッシュの別の領域やRTCバックアップレジスタに保存する。デュアルバンク方式を検討する。
割り込み処理: ブートローダーとアプリケーションで異なる割り込みハンドラを使用する場合、VTORの設定と割り込みの有効/無効化を適切に行う必要があります。
- 対策: ブートローダー実行中は、通信関連など必要最小限の割り込みのみを有効化する。アプリケーションへジャンプする直前に、全ての割り込みを無効化する（アプリケーション側で改めて必要な割り込みを有効化するため）。
アプリケーションへのジャンプ失敗: VTORの設定ミス、スタックポインタ設定ミス、エントリポイントアドレスミス、Thumbモードへの考慮不足などが原因でジャンプに失敗することがあります。
- 対策: VTORやスタックポインタ、エントリポイントアドレスが設計通りの値になっているかデバッガーで確認する。アプリケーションのリンカスクリプトが正しく設定されているか確認する。ジャンプ処理のコードを慎重にレビューする。

第8部：STM32CubeFWとブートローダー開発

STMicroelectronicsが提供するSTM32Cube™マイクロコントローラーソフトウェアパッケージ（STM32CubeFW）は、カスタムブートローダー開発において非常に役立ちます。

HAL/LLドライバ: Hardware Abstraction Layer (HAL) または Low-Layer (LL) ドライバは、STM32のペリフェラル（GPIO, UART, SPI, I2C, USB, FLASHなど）にアクセスするための抽象化されたAPIを提供します。これらのドライバを使用することで、ペリフェラルの初期化や操作を、レジスタレベルで直接操作するよりも簡単に、かつ異なるSTM32シリーズ間での移植性を高めて記述できます。特にフラッシュメモリの消去・書き込み・読み出し保護設定など、低レベルで誤ると危険な操作は、HAL/LLドライバを使用することが推奨されます。
ミドルウェア: USBホスト/デバイススタック、TCP/IPスタック（LwIP）、FreeRTOSなどのミドルウェアも提供されています。これらを活用することで、USB DFUブートローダーやEthernet経由のOTAブートローダーなどを効率的に開発できます。
サンプルコード: STM32CubeFWには、ROMブートローダーとの通信を行うホスト側のサンプルコードや、セキュアブート/セキュアファームウェアアップデート (SFU) のリファレンス実装などが含まれている場合があります。これらのサンプルコードは、カスタムブートローダーの構造を理解したり、実装の参考として役立ちます。特にSTM32CubeExpansion_SFUは、セキュアアップデート機能の実装を検討する上で非常に重要なリソースです。

これらのツールとリソースを活用することで、カスタムブートローダー開発の負担を軽減し、開発効率と信頼性を向上させることができます。

第9部：まとめと今後の展望

ブートローダーは、STM32ベースの組み込みシステムにとって、単なる起動プログラム以上のものです。それはシステムのライフサイクル全体にわたる信頼性、保守性、そしてセキュリティを支える基盤となります。

STMicroelectronicsが提供するROMブートローダーは、開発不要で手軽にフラッシュプログラミングを行うための便利な手段です。開発初期段階や量産プログラミング、緊急時の回復に役立ちますが、機能やインターフェースに制限があります。
カスタムブートローダーは、ROMブートローダーの限界を超えるための強力なツールです。OTAアップデート、独自の通信方法、高度なセキュリティ機能などを実装できます。開発には、メモリマップ設計、リンカスクリプト、フラッシュ操作、アプリケーションジャンプ処理など、組み込みシステム開発の深い理解が必要です。
カスタムブートローダー開発においては、特にセキュリティ（セキュアブート、署名検証、暗号化、RDP）と堅牢性（エラーハンドリング、リカバリ機構）が重要です。「文鎮化」のリスクを避けつつ、様々な異常事態に対応できる設計が求められます。
STM32CubeFWは、HAL/LLドライバやミドルウェア、サンプルコードを提供しており、カスタムブートローダー開発の強力な味方となります。

今後の組み込みシステム開発では、ますます多くのデバイスがネットワークに接続され、ソフトウェアアップデートの頻度が増加すると予想されます。IoTデバイスにおいては、セキュアなOTAアップデート機能が必須要件となるでしょう。STM32の高性能化と豊富な機能は、これらの要求に応えるための柔軟なブートローダー開発を可能にします。

カスタムブートローダーの開発は決して容易ではありませんが、その知識とスキルはSTM32開発者にとって非常に価値のあるものです。この記事が、皆様のブートローダーに関する理解を深め、より信頼性の高い、セキュアなSTM32製品を開発するための一助となれば幸いです。

参考資料

STM32 マイクロコントローラーのデータシート: 対象となるSTM32製品のメモリマップ、ペリフェラルの詳細、BOOTピンの説明などを確認します。
STM32 マイクロコントローラーリファレンスマニュアル: Cortex-Mコアのレジスタ（SCB, VTORなど）、フラッシュメモリコントローラー、ペリフェラルのレジスタ詳細などを確認します。
AN2606: STM32 microcontroller system memory boot mode: STM32のROMブートローダーの詳細、サポートされるインターフェース、通信プロトコルについて解説されています。
AN4894: STM32L4 Series system memory boot mode: 特定シリーズに特化したROMブートローダーの解説。
AN4992: Firmware update over the air (FOTA) solution for STM32 microcontrollers: OTAアップデートの概念や実装について解説されています。
UM2245: STM32CubeProgrammer software description: STM32CubeProgrammerツールの使い方について解説されています。
STM32CubeExpansion_SFU: セキュアブートおよびセキュアファームウェアアップデートに関するSTM32Cube拡張パッケージ（対応デバイス向け）。
ARM Cortex-M Programming Guide: Cortex-Mコアのアーキテクチャ、例外・割り込み処理、VTORレジスタなどについて解説されています。

これらの公式ドキュメントやツール、ソフトウェアパッケージを最大限に活用することが、STM32での効果的なブートローダー開発には不可欠です。

注釈: 本記事は、STM32開発者向けのブートローダーに関する詳細な情報提供を目的としており、約5000語の記述を目指して執筆されました。特定のコードは概念的な例として示しており、実際の開発には対象のSTM32製品、開発環境、および具体的な要件に基づいた詳細な実装が必要です。また、セキュリティ関連の機能実装には専門的な知識が求められます。

STM32開発者必見！ブートローダーの基本と応用

第1部：ブートローダーとは？ なぜSTM32開発で重要なのか

1.1 ブートローダーの役割と定義

1.2 なぜSTM32開発でブートローダーが重要なのか

第2部：ブートローダーの基本原理とSTM32の起動プロセス

2.1 マイクロコントローラーの起動プロセス

2.2 メモリ構成とブートローダーの関係

2.3 ベクタテーブルとVTORレジスタ

第3部：STM32のROMブートローダー詳解

3.1 起動モードの設定（BOOT0, BOOT1ピン）

3.2 サポートされているインターフェース

3.3 通信プロトコル

3.4 ROMブートローダーの使い方（ツール）

3.5 ROMブートローダーのメリットとデメリット

第4部：カスタムブートローダーの開発

4.1 なぜカスタムブートローダーが必要か

4.2 カスタムブートローダー開発のステップ

define APP_START_ADDRESS 0x08004000

4.3 リンカスクリプトの重要性

4.4 ベクタテーブルリマップの実装方法

define APP_START_ADDRESS 0x08004000

4.5 アプリケーションからのブートローダー起動方法

define BOOTLOADER_REQUEST_FLAG_ADDRESS (SRAM_BASE + 0x1000) // SRAMの安全なオフセット

define BOOTLOADER_REQUEST_VALUE 0x12345678 // 特定の値

第5部：応用例 – OTAアップデートの実装

5.1 OTAのメリットと課題

5.2 OTAアップデートの実装方式

5.3 セキュリティ対策

5.4 実装プロトコル例

第6部：セキュリティとブートローダー

6.1 セキュアブート (Secure Boot)

6.2 ファームウェア署名検証

6.3 暗号化

6.4 RDP (Read Protection) の活用

6.5 セキュアファームウェアアップデート (SFU)

第7部：デバッグとテスト

7.1 デバッグ手法

7.2 テストケース

7.3 よくある課題と解決策

第8部：STM32CubeFWとブートローダー開発

第9部：まとめと今後の展望

参考資料

コメントする 返信をキャンセル

第1部：ブートローダーとは？なぜSTM32開発で重要なのか

コメントする返信をキャンセル