PIC32MZ2048EFGマイコンのブートローダ機能を検討したため、今回はその際に戸惑った点等を備忘録として紹介します。ブートローダ機能を利用するとPICkit4やSNAP等の専用の書き込み治具がなくても、SDカードやUART等からファームウェアを容易に書き換えできるようになります。何かしらの製品に組み込んだ際にユーザ側でファームアップデートすることが想定される場合に便利です。今回は事前にブートローダを書き込んだPIC32MZマイコンにファームウェアの入ったSDカードを挿入すると自動的にファームウェアが書き込まれるブートローダを作成しました。
Microchipから様々なブートローダのドキュメントが提供されていますが、いまいち全容を把握するのに苦労したため、ポイントを絞って紹介したいと思います。詳細は
各ドキュメントを参照してください。
まずはブートローダ機能を開発する際のポイントを先に紹介します。
■ポイント
①ブートローダ用のプロジェクトとアプリケーションのプロジェクトは分けて作成する
→リンカファイルが異なるため、ミスを減らすためにプロジェクトを分ける。また、アプリケーション用のプロジェクトでは通常のバイナリ(hex)ファイルの他にbinファイルを生成するスクリプトを追加することでブートローダ読み込み用のbinファイルを追加で生成させる。
②リンカファイル作成方法
→Harmony3+bootloaderで生成したプロジェクトでブートローダ用のリンカファイルbtl.ldはそのまま使用可能。一方、アプリケーション側のリンカファイルはp32MZ2048EFG100.ldを編集必須。また、Harmony3+bootloaderで生成したプロジェクトのリンカ設定はbtl.ldファイルでなく、p32MZ2048EFG100.ldファイルとなっているため、p32MZ2048EFG100.ldをプロジェクトから除外してブートローダ用のリンカファイルbtl.ldに置き換えること。
③クロック設定やデバイスコンフィグは同じ設定にする
→ブートローダとアプリケーションの切り替え動作が不安定になる。
④ブートローダ用のプロジェクトは最低限の機能に絞る
→機能を盛り込むとブートローダファームがブートローダ領域に入らない。SDを読み込み専用に設定し、コンソールデバッグ機能は使用しない。
⑤ブートローダのファームは直接書き込み可能
→MPLAB IDEからデバッガを介して書き込み可能。既定ではフラッシュ全削除後に書き込みされるため、通常は書き込み直後にブートローダが起動し、アプリケーションの書き込みモードに入る。
⑥アプリケーションのファームは直接書き込まずにブートローダから書き込み
→直接書き込むとフラッシュ全削除してアプリケーションだけが書き込まれる。ブートローダが消されてしまうため、アプリケーション領域に処理をジャンプさせることができず、アプリケーションが起動しない。
■ブートローダ機能のシーケンス
ブートローダ起動→トリガチェック→(書き換えモードの時)ファーム書き換え処理→ソフトリセット
→(通常起動の時)アプリケーション起動処理→アプリケーション起動
■トリガ種類
ブートローダが起動後にファーム書き換えモードに入るか、通常のアプリケーション起動モードに入るかはIO状態やメモリ上の変数状態で切り替えることができます。
・a)IO状態トリガ
PIC32マイコンをリセットさせて、起動時のIO状態を見て切り替えます
・b)メモリ上の変数状態トリガ
アプリケーションが起動している状態でユーザ操作によってファーム書き換えモードにします。ファーム書き換えモードでは特定のメモリ領域に変数を書き込んで部分的なシステムリセット(特定のメモリ領域はリセットされない)をかけることでブートローダを再度起動させて、特定のメモリ領域の変数を見て書き換えモードに入るか、通常のアプリケーション起動モードに入るか切り替えます。
■ブートローダ側の開発流れ
1. MPLAB Ⅹ IDEのHarmony3にBootloaderパッケージを追加する。
Tools→Embedded→MPLAB Harmoney3 Content Managerをクリック。bootloaderとbootloader_apps_sd～にチェックを入れてパッケージを追加します。
2. Harmoney3プロジェクトを作成し、Filesytemタイプのbootloaderを追加する。
メディアタイプにSDカードを選択し、b)メモリ上の変数状態トリガを有効にするために16バイトの領域を確保する。また、ファイルシステムの設定は自動マウントを有効化して、読み込み専用に設定する。また、32GB以上のSDカードにも対応させる場合はexFatにチェックを入れる。また、クロック設定やデバイスコンフィグはアプリケーション側と共通の設定をします。
3. コード生成後にリンカファイルを設定する。
Harmoney3プロジェクトでbootloaderを追加すると自動的にbtl.ldとp32MZ2048EFG100.ldの2つのリンカファイルがプロジェクトに追加される。ただ、ビルド設定ではp32MZ2048EFG100.ldが有効となるため、p32MZ2048EFG100.ldをプロジェクトから除外して、btl.ldだけにする。
4. ファイルシステムコード追記する。
デフォルトではff.hのビルドに失敗するため、ff.hの38行目くらいに#define __STDC_VERSION__ 199902を定義する。
5. ブートローダコードを実装する。
詳細はコードをアップロードしてありますのでそちらを参照してください。起動直後にブートローダ機能を実行するか、アプリケーションを起動させるかの切り替えがinitialization.cにあります。
■アプリケーション側の開発流れ
1. 通常通りにMPLAB Ⅹ IDEのHarmony3のプロジェクトを作成します。また、クロック設定やデバイスコンフィグはブートローダ側と共通の設定をします。また、リンカファイルを変更して独自のリンカファイルを使用するため、Harmony3のプロジェクトグラフ内のsystem→Device&Project Confguration→Toolchain selectionのAdd linker file to projectのチェックを外します。
2. リンカファイルp32MZ2048EFG100.ldを書き換えます。
・PROVIDE(_ebase_address = 0x9D000000);の下にPROVIDE(_ebase_vector_offsets = 0x1000);を追加。
・_RESET_ADDR = 0xBFC00000;を_RESET_ADDR = 0xBD000000;に変更。
・_BEV_EXCPT_ADDR = 0xBFC00380;と_DBG_EXCPT_ADDR = 0xBFC00480;を削除。
・_SIMPLE_TLB_REFILL_EXCPT_ADDR、_CACHE_ERR_EXCPT_ADDR 、_GEN_EXCPT_ADDR に_ebase_address を追加して下記のように書き換える。
_SIMPLE_TLB_REFILL_EXCPT_ADDR = _ebase_address + _ebase_vector_offsets + 0;
_CACHE_ERR_EXCPT_ADDR = _ebase_address + _ebase_vector_offsets + 0x100;
_GEN_EXCPT_ADDR = _ebase_address + _ebase_vector_offsets + 0x180;
・メモリ領域(MEMORY)の書き換えとconfig領域の削除
(変更)
kseg0_program_mem (rx) : ORIGIN = 0x9D001000, LENGTH = 0x200000 - 0x1000
kseg1_boot_mem : ORIGIN = 0xBD000000, LENGTH = 0x480
kseg1_boot_mem_4B0 : ORIGIN = 0xBD0004B0, LENGTH = 0x1000 - 0x04B0
(追記)
/* Reserve 16 Bytes to Store Bootloader Trigger Pattern */
kseg0_data_mem (w!x) : ORIGIN = 0x80000000 + 16, LENGTH = 0x80000 - 16
(削除)
アプリケーション側ではコンフィグを行わないため、config領域を削除します。
config_BFC0FF40からboot2lastpageまでを削除します。
・SECTION領域(SECTIONS)のconfig削除
.config_BFC0FF40から始まるSECTIONSを削除する。
・SECTION領域(SECTIONS)の例外処理を削除
ブートローダ側に含まれるため、下記の例外処理を削除する。
.bev_excpt _BEV_EXCPT_ADDR :
{
KEEP(*(.bev_handler))
} > kseg1_boot_mem
・割込みオフセットに_ebase_vector_offsetsを追記
* Interrupt vector table with vector offsets */
.vectors _ebase_address + _ebase_vector_offsets + 0x200 :
・ブートローダ側に含まれるため、下記を削除する
/* The startup code is in the .reset.startup section.
* Keep this here for backwards compatibility with older
* C32 v1.xx releases.
*/
.startup ORIGIN(kseg0_boot_mem) :
{
KEEP(*(.startup))
} > kseg0_boot_mem
・ デバッグ例外処理とコンフィグはブートローダ側に含まれるため、除く処理を追加する。
/DISCARD/ : { *(.note.GNU-stack) *(.gnu_debuglink) *(.gnu.lto_*) *(.discard) }の下に下記を追加する。
/DISCARD/ : { *(._debug_exception) }
/DISCARD/ : { *(.config_*) }
3. アプリケーション側で必要に応じて、ソフトウェア的にファーム書き換えモードにするコードを追加します。BTL_TRIGGER_PATTERN で定義された特殊な値をBTL_TRIGGER_RAM_START に書き込んでソフトリセットさせることでリセット後にブートローダが起動し、ＳＤカードからファームを書き換える処理を走らせることができます。
#include "sys/kmem.h"
#define BTL_TRIGGER_RAM_START KVA0_TO_KVA1(0x80000000)
#define BTL_TRIGGER_PATTERN (0x5048434DUL)
#define DCACHE_CLEAN_BY_ADDR(start, sz)
static uint32_t *ramStart = (uint32_t *)BTL_TRIGGER_RAM_START;
SYS_DEBUG_PRINT(SYS_ERROR_DEBUG, "Bootloader Triggered!\r\n");
ramStart[0] = BTL_TRIGGER_PATTERN;
ramStart[1] = BTL_TRIGGER_PATTERN;
ramStart[2] = BTL_TRIGGER_PATTERN;
ramStart[3] = BTL_TRIGGER_PATTERN;
DCACHE_CLEAN_BY_ADDR(ramStart, 16);
APP_SystemReset();
4. プロジェクト設定でbinファイルを生成するコードを追加します。
アプリケーション側のビルド後にhexファイルからbinファイルを生成します。
${MP_CC_DIR}/xc32-objcopy -I ihex -O binary ${DISTDIR}/${PROJECTNAME}.${IMAGE_TYPE}.hex ${DISTDIR}/${PROJECTNAME}.${IMAGE_TYPE}.bin
これでブートローダ機能の設定および実装は完了です。先にブートローダ側のファームをPIC32マイコンに書き込んで、アプリケーション側のbinファイルをimage.binにファイル名を書き換えてSDカードに入れるとファームが書き換えられ、アプリケーションが実行されます。プロジェクトファイルおよび全体のコードはこちら(
code.zip)です。
なお、パッケージを追加するとC:\Users\(ユーザ名)\Harmony3\bootloader_apps_sdcard\apps\sdcard_bootloader内にブートローダ側のbootloaderとアプリケーション側のtest_appがサンプルコードが追加されます。ただ、サンプルプログラム(PIC32MZDA)とREADMEだけでは情報少なく苦労したため、試行錯誤しながら何とか動かすことができました。SDカード以外にもUARTやフラッシュメモリ等からも書き換えできますが、専用ソフトが不要でユーザ側のOS環境に依らず負担が少ないSDカードからの書き換えが汎用性が高く良いと思いました。また、アプリケーション側のリンカファイルを書き換えるとそのままでは簡単にデバッグやブートローダ無の単体動作できないため、元のリンカファイルも残しておいて、読み込むリンカファイルを切り替えるとよいと思います(Lodableに追加する別のデバッグ方法もありますが...)。
