MCUbootを用いてルネサスマイコンのファームウェアアップデートをしてみた その2

はじめに

前回、ルネサスのARMコアマイコンRAファミリのRA6M4と、ルネサスFlexible Software Package (FSP)を用いて、MCUbootのDirect XIPモードを実装してみました。

マイコンRA6M4は、最大1MBのROM（Code Flash）を持ち、Dual Bankに対応していたため、Direct XIPモードが使用できましたが、産業機器向けでは、あまり大きなROMを必要としません。そうすると、Dual Bankに対応していないROM容量を選択することになりますが、ROM容量は大きくなくても、ファームウェアアップデートが必要になる場面はあると思います。

 

そこで今回は、ROM容量が128KBのRA4E2でMCUbootを試みてみたいと思います。しかしながら、RA4E2向けのMCUbootのアプリケーションノートは提供されていませんでした。ここで比較的高価な評価ボード EK-RA4E2で、できなかったらどうしようと躊躇してしまいがちですが、RA4E2には、Fast Prototyping Boardと呼ばれる、評価ボード FPB-RA4E2 が提供されています。FPBは安価なので、これなら気軽にRA4E2の評価が試せます。

 

以下のアプリケーションノートを参考にしています。MCUbootって、なに？とおっしゃる方は、このアプリケーションノートも参照ください。

アプリケーションノート：RA4 Secure Bootloader Using MCUboot and Internal Code Flash

リンクは2025年７月のものです。

このアプリケーションノートと、そのサンプルプログラムでは、ルネサスARMコアマイコンRA4M3（ROM容量1024KB）を用い、様々なMCUbootのモードを紹介しています。

 

MCUbootのSwapモード

今回試してみるのは、MCUbootのSwapモードと呼ばれるモードです。Swapモードは、４つの領域が必要です。

・MCUboot領域：ブートローダの領域

・プライマリ領域：起動するアプリケーションの領域

・セカンダリ領域：更新アプリケーションが書き込まれ、かつ、古いアプリケーションを残す領域。この領域からは起動しません。

・スクラッチ領域：更新時に、初期アプリケーションと更新アプリケーションの入れ替えに使用されるテンポラリ領域

これらの領域を使用したSwapモードによるファームウェアアップデートの動作の概要を簡単に説明します。

初期アプリケーションはプライマリ領域に書き込まれており、起動しているとします。ファームウェアアップデートが開始されると、更新アプリケーションがダウンロードされ、セカンダリ領域に書き込まれていきます。
ダウンロードが完了すると、署名検証が行われ、認証されると、スクラッチ領域を利用して、初期アプリケーションと更新アプリケーションを分割しながら、Swapします。
Swapが完了すると、リセットがかかり、プライマリ領域に移動した更新アプリケーションが起動します。

Swapモードのメリットは、Dual Bankに対応していなくても、更新の前のアプリケーションを残すことができることです。デメリットは、スクラッチ領域が必要になることです。スクラッチ領域は入れ替え時に頻繁に書き込みが行われるため、この領域だけ、Flashメモリの書き換え回数の上限に早く到達することです。

（以降、初期アプリケーションを、初期アプリ。更新アプリケーションを更新アプリ、と略します）

 

開発手順

今回の開発環境のバージョンは、以下です。

e2 studio：2024-04

Flexible Software Package (FSP)：v5.3.1

 

ブートローダの作成

先ず、ブートローダを作成するため、ブートローダのプロジェクト mcuboot_ra4e2_bootloader を作成します。名称は任意です。プロジェクトの作成の手順で、ボードはFPB-RA4E2、Flat(Non-TrustZone) Project、No RTOS、Bare Metal – Minimal を選択しました。

プロジェクトの Stacks Configuration パースペクティブが開いたら、タブ [Pins] を選択し、[Generate data] のチェックボックスのチェックをはずします。

プルダウンメニューを使用して、”RA4E2 FPB” を、“R7FA4E2B93CFM.pincfg” に変更し、チェックボックスにチェックを入れ、“g_bsp_pin_cfg” と入力します。

タブ [Stacks] を選択します。[New Stack] より、スタック [MCUboot] を追加します。

スタック [MCUboot] を選択して、タブ [プロパティー] の プロパティ > Common > General > Upgrade Mode と進み、[Swap] を選択します。

スタック [Add Requires a crypt stack] を左クリックして、スタック [MCUboot TinyCrypt(S/W only)] を追加します。

スタック [Add Requires Flash] を左クリックして、スタック [Flash] を追加します。

スタック [Flash] を選択し、タブ [プロパティー] より、値を図のように設定します。

スタック [Add ASN.1 parser if using TinyCrypt or Custom Crypt (Protected Mode)] を左クリックして、スタック [MCUboot ASN.1 Parser] を追加します。

タブ [BSP] を選択し、タブ [プロパティー]より、プロパティ > RA CommonのMain stack sizeに “0x1000” 、Heep size に “0x400” を設定します。

 

フラッシュメモリの領域を決めます。

RA4E2 はフラッシュメモリ のイレース単位により、32KB (0x8000)で区切る必要があります。

MCUbootのSwapモードでは、MCUboot領域、プライマリ領域、セカンダリ領域、スクラッチ領域の４つの領域が必要です。RA4E2のコードフラッシュメモリは128KBなので、32KBの倍数で４つの領域を設定すると、必然的にそれぞれの領域は32KB（0x8000）の一択となります。

この領域のサイズにもとづき、スタック [MCUboot] を選択し、タブ [プロパティー]より、プロパティ > Flash Layout を以下の様に設定します。

MCUbootに含まれている公開鍵と秘密鍵の既定のペアをテストの目的で使用することを選択できます。スタック [Add [Optional] Add Example Keys] を左クリックして、スタック [MCUboot Example Keys (NOT FOR PRODUCTION)] を追加します。

プロジェクト・エクスプローラーのプロジェクトから、コード hal_entry.c をダブルクリックで開きます。プロジェクトのDeveloper Assistance > HAL/Common > MCUboot > Quick Setup と進んで、Call Quick Setup を コードの 関数 hal_entry() の前に、ドラッグします。

Generate Project Content をクリックして、コードを生成し、ハンマーボタンでビルドします。これで、MCUbootのブートローダの作成は終了です。

 

アプリケーションの作成

次に初期アプリと更新アプリを作成します。アプリは何でもよいので、任意に作成してください。私は、初期アプリと更新アプリの区別がつくように、基本的なLED点滅アプリを作成しました。評価ボード FPB-RA4E2 には、LED1とLED2の二つのLEDが実装されているので、初期アプリと更新アプリで点滅方法を変えました。仮に初期アプリをプロジェクト mcuboot_ra4e2_primary、更新アプリをプロジェクト mcuboot_ra4e2_secondary としました。

このように、ブートローダとアプリを分けて作成できるので、既存のアプリにMCUbootを加えるのも容易にできそうです。

アプリケーションには、バージョン番号を含めることが出来ます。今回のSwapモードでは、ダウングレード防止はできませんが、Over Writeモードでは、ダウングレード防止ができるとの事です。バージョン番号は、環境変数 MCUBOOT_IMAGE_VERSIONを定義することで実現できます。また、署名の検証がある場合は、環境変数MCUBOOT_IMAGE_SIGNING_KEYを設定する必要があります。これらの変数を設定する手順を説明します。

 

e2 studioのプロジェクト・エクスプローラーの、初期アプリのプロジェクト を左クリックして、[プロパティ] を選択します。

[プロパティ] の左のメニューより、[環境] を選択し、[追加] をクリックします。

環境変数の[名前] に、“MCUBOOT_IMAGE_VERSION”、[値]に “1.0.0”（任意） を入力し、OKをクリックします。

再度、[追加] をクリックし、[名前] に、“MCUBOOT_IMAGE_SIGNING_KEY”、[値] に“

${workspace_loc:mcuboot_ra4e2_bootloader}/ra/mcu-tools/MCUboot/root-ec-p256.pem“を入力し、[OK]をクリックします。

[適用して閉じる] をクリックして、変数の設定は完了です。

次の手順は、どのような効果があったのかは検証していませんが、アプリケーションノートに「お勧め」とされていたので、記載します。左のメニューより、[設定] を選択し、タブ [ビルド・ステップ] の コマンドに、“rm -f ${ProjName}.elf” と入力し、[適用して閉じる]をクリックします。

バージョン番号の追加から、ここまでの手順を、初期アプリと更新アプリの２つのプロジェクトに行い、それぞれに、Generate Project Content をクリックして、コードを生成し、ハンマーボタンでビルドします。

続いて、デバッグ構成を設定していきます。

初期アプリのプロジェクトを選択（実際はどのプロジェクトでもよいです）し、右クリックでメニューを開き、デバッグ > デバッグの構成 へと進みます。

初期アプリのプロジェクト（例：mcuboot_ra4e2_primary Debug_Flat）が選択されていることを確認し、タブ [Startup]を選択し、[追加…]をクリックします。

[ワークスペース] をクリックし、ブートローダのプロジェクト（例：mcuboot_ra4e2_bootloader）に移動し、debugフォルダからプロジェクトバイナリファイル（例：ra_mcuboot_ra4e2.elf）を選択し、[OK] をクリックします。

もう一度 [追加] をクリックし、初期アプリのプロジェクト（例：app_ra4e2_primary）のプロジェクトバイナリファイル（例：app_ra4e2_primary.elf）を追加し、[OK] をクリックします。

もう一度 [追加] をクリックし、初期アプリの署名されたバイナリファイル（例：mcuboot_ra4e2_primary.bin.signed）を追加し、[OK] をクリックします。

初期アプリの署名されたバイナリファイルのロードタイプを [バイナリーデータ]に、オフセットをプライマリエリアの先頭アドレス0x8000 に変更し、［適用］をクリックします。

 

初期アプリの実行

引き続いて、［デバッグ］をクリックします。

デバッガーは、ブートローダのリセットハンドラーにヒットします。

[再開] ボタン をクリックします。引き続き、もう一度、[再開]ボタンをクリックし、初期アプリを起動します。ここで、LEDの点滅により、初期アプリが動作している事を確認できました。（下図の状態１から状態２）

 

セカンダリーアプリケーションのダウンロードと実行

[一時停止] ボタンを押してプログラムを一時停止します。

e2 studio のツールバーの［ファイルのロード］ ボタンをクリックします。

[ワークスペース]をクリックし、更新アプリのdebugフォルダから署名されたバイナリファイル（例：mcuboot_ra4e2_secondary.bin.signed）を追加し、[アドレス］にセカンダリ領域の 先頭アドレス “0x10000”を入力し、[OK] をクリックします。

[再開] ボタンをクリックします。プライマリ領域 と セカンダリ領域 の中身のSwapが行われ、更新アプリが実行されます。（下図の状態３～状態５）

 

ROMの確認

私はLEDの点滅により、更新アプリの実行を確認できました。しかし、本当にROMの中でSwapがおこなわれ動作が行われているのかが、わかりません。やはりここは確認をしておきたいものです。

そこで、e2 studio のメモリーモニター機能を用いてメモリの読み出しを行ってみました。しかし、更新アプリの書き込み後の状態（上図の状態３）を読み出すだけで、初期アプリと更新アプリがSwapされた状態（状態５）を観測することが出来ませんでした。これは e2 studioの仕様によるもののようです。

PCにJ-Link Commanderがインストールされているならば、こちらを使用してみてください。

J-Link Commanderを起動したら、“connect” と入力します。次に “？” を入力すると、デバイス一覧が表示されますので、RA4E2の型名 [R7FA4E2B8] を選択して［OK］をクリックします。

次に、インタフェースにSWD＝“S” を入力し、スピードは、空打ち（デフォルのままなので、Enterキーのみ）します。

次に、メモリの読み出し例を示します。下図で上の２つが、更新アプリの書き込み後です。バージョン番号から、まだ、プライマリ領域に 初期アプリがあり、セカンダリ領域に 更新アプリがある事が分かります。

下の２つが、Swapが行われた後です。バージョン番号から、プライマリ領域に更新アプリがあり、セカンダリ領域に初期アプリがある事が分かり、Swapが行われたことが確認できました。

 

まとめ

RA4M3（ROM 1024KB）のアプリケーションノートを参考にしながら、RA4E2（ROM 128KB）を搭載した安価な評価ボードFPB-RA4E2で、MCUbootを実行することが出来ました。

このように、ルネサスではFlexible Software Package (FSP)の提供により、ルネサスArmコアマイコンのRAファミリで、MCUbootを用いたファームウェアアップデートをサポートしております。

一度、経験すれば、様々なRAファミリ にMCUbootを展開させていくことが容易であることが理解できます。

ルネサス Armコアマイコン RAファミリ でMCUbootを用いたファームウェアアップデートを実現してください。

 

お問い合わせはこちら