STM32G0/G4のRoot of Trust(3)

STM32G0/G4シリーズRoot of Trust実現(3)は、第2回で示したSTM32G4評価ボード:NUCLEO-G474RE 利用STM32G4テンプレート開発環境と、デュアルファームウェアイメージのサンプルアプリケーションを使って、セキュア・ブート(SB)、セキュア・ファームウェア更新(SFU)のための準備、その具体的動作の説明をします。

初めに本稿(3)のまとめを示し、最後の章でRoot of Trust実現(1)~(3)全体のまとめを示します。

STM32G0/G4のRoot of Trust(3)まとめ

  • セキュア・ブート(SB)、セキュア・ファームウェア更新(SFU)に、評価ボード毎にSTM32CubeProgrammerを使ったオプションバイト設定必要。
  • Root of Trust(SBSFU)実装MCUは、VCP経由アクセスのみ可能。
  • SBSFUローカルVCPダウンロードのために、Tera TermとYMODEM送信機能利用。
  • STM32G4評価ボード:NUCLEO-G474REで、SBSFU実装デュアルファームウェアイメージアプリケーション動作説明。
  • STM32G0評価ボード:NUCLEO-G071RBでもSTM32G4評価ボードと同じRoot of Trust(SBSFU)実装動作を確認。

STM32G4評価ボード準備

SB、SFUサンプルアプリケーションの動作確認のために評価ボード:NUCLEO-G474REの事前準備が必要です。これには、STM32CubeProgrammerを使います。STM32G4の場合は、UM2262 図18ですが、オプションバイト等の設定は不要(デバイスデフォルトOK)です。

8.1.3のFlash全消去(Full chip erase)処理をします。また、評価ボードのST-LinkファームウェアをV2J29以上に更新します。更新は、評価ボードとUSB接続後、STM32CubeProgrammerのFirmware Updateクリックで最新版ST-Linkファームウェアへ更新されます。

ST-Linkファームウェアアップデート
ST-Linkファームウェアアップデート

Root of Trust(SBSFU)準備

図17. ステップバイステップ実行から判るように、最初のStep1:SBSFUダウンロード以外は、全て評価ボードのVirtual COMポート(VCP)経由でアプリケーションをダウンロードします。STM32CubeIDEがプログラミングやデバッグで使うST-Link接続(SWD接続)は、外部からのMCU攻撃とSBSFUが解釈するからです。

セキュア・ブート(SB)が攻撃と判断した時は、当然、アプリケーションを起動しないためMCUは動作停止します(SB処理は、第2回2章を参照してください)。

Step-byーstepのデュアルファームウェアイメージ実行(出典:UM2262)
Step-byーstepのデュアルファームウェアイメージ実行(出典:UM2262)

つまり、ファームウェアイメージのアプリケーションがディアル/シングルに関係なくRoot of Trust(SBSFU)実装MCUは、VCP経由アクセスのみ可能となります。また、VCP経由でのアプリケーションデバッグは非効率なため、十分なデバッグ済みアプリケーションをダウンロードする必要もあります。

このVCP経由ダウンロードのために、Tera TermとそのYMODEM送信機能の準備が必要です。

SBSFUサンプルアプリケーション

図17. Step-by-stepを使ってデュアルファームウェアイメージのSBSFUサンプルアプリケーション動作を説明します。

Step1:Flash全消去後のNUCLEO-G474REに、STM32CubeIDEを使って第2回3章で示した順番でコンパイル済みのSBSFUプロジェクト出力(SBSFU.elf)を、STM32CubeIDEを使わずにSTM32CubeProgrammerでダウンロードします。

STM32CubeIDEでは、ダウンロード後自動的にデバッガ接続に変わるため、この時点でSBSFUが攻撃を受けたと判断し使用できません。

STM32CubeProgrammerを使うとNUCLEO-G474REのFlashに、セキュアエンジンとSBSFUが書込まれます。これ以降は、Tera TermのVCP経由MCUアクセスのみが可能です。
※従って、STM32CubeIDEを使ったST-Link経由MCUデバッグ開発へ戻る時は、STM32CubeProgrammerでSBSFUが入ったFlashを全消去する必要がありますので注意してください。

次に、パソコンとNUCLEO-G474RE接続中のUSBケーブルを、2回挿抜します。これで、ST-Linkに代わりSBSFUとTera TermのVCP通信が開始します。

Step2:NUCLEO-G474RE とTera Termは、8-Non-1 115200bpsでシリアル接続します。接続後、NUCLEO-G474REリセットボタン(黒ボタン)を押すと、SBSFUが図24のWelcome画面をTera Termへ出力します。

SBSFUがTera Termへ出力するWelcome画面
SBSFUがTera Termへ出力するWelcome画面

Welcome画面を確認後、Tera Termのファイル(F)>転送(T)>YMODEM>送信(S)をクリックし、UserApp.sfb(暗号化ファームウェア)を選択します。
※UserApp.sfbは、NUCLEO-G474RE_2_Image _UserApp\Binaryフォルダ内(UserApp オブジェクト出力先フォルダ)にあります。

プログレスバーは、1秒ほど動きません。この間は、SBSFUがダウンロードファームウエアヘッダの有効性を検証し、格納するFlashスロット#0/#1領域を消去しているからです。

送信完了でNUCLEO-G474REのFlashが、Step2の状態になります。

Step3:NUCLEO-G474REが自動的に再起動し、SBSFUにより復号化されたUserAppが動作します。この時のTera Term出力が図27です。NUCLEO-G474REのLD2は、ゆっくり点滅します。

図27. 暗号化ファームウェア転送後のSBSFU再起動
図27. 暗号化ファームウェア転送後のSBSFU再起動

画面のUser App #Aは、2_Images_UserApp>main.cのL51:UserAppId = ‘A’の出力です。Main Menu:1/2/3は、インストールしたアプリケーションに記述されたSBSFUテスト機能です。

CN7真ん中よりやや下あたりを指で触るとTamper機能が動作し、ボードリセットが掛かります。

実際では、この段階で我々ユーザが開発したアプリケーションが動作中となります。

Step4:ユーザ開発アプリケーションに何らかのバグがあり、これをデバッグ済みの新しいアプリケーションへ更新(SFU)するのがこの段階です。

STM32CubeIDE でL51:UserAppId=‘B’へ変更し、コンパイルします。ここでは、これをデバッグ済みの新しいアプリケーションとします。

再び、Tera Termのファイル(F)>転送(T)>YMODEM>送信(S)をクリックし、UserApp.sfb(UserAppId=‘B’に変更し、コンパイルした暗号化ファームウェア)を選択し、ダウンロードします。ダウンロード完了でNUCLEO-G474REは再起動します。

Step5:再起動後の動作中アプリケーションは、図27の下線部が変更したUser App #Bに変わっていることで確認できます。

これで、新しいアプリケーションへの更新が完了しました。

*  *  *

図17を使ってRoot of Trust実現STM32G4シリーズMCUのセキュア・ブート(SB)、セキュア・ファームウェア更新(SFU)ローカル動作例を説明しました。

実際は、この動作が図2. ②通信チャネル経由で行われます。

図2.セキュアファームウェア更新プロセス(出典:UM2262)
図2.セキュアファームウェア更新プロセス(出典:UM2262)

通信チャネル利用時は、本稿のローカル動作で使ったTera TermのYMODEM送信を誰が行うのか、鍵の管理やサーバ提供など、筆者がUM2262から読み切れない不明な部分があります。これらはいずれ、明らかにする予定です。

また、UM2262図18. 評価ボード準備とSTM32CubeProgrammer設定方法が解りづらく、単なるサンプルアプリケーション動作にかなり「苦戦」しました。この部分は、通常アプリケーション開発とRoot of Trust実現開発の切換えとなる重要ポイントです。STM32G4テンプレート発売時には、添付資料にもっと解りやすい説明を加えます。

UM2262 Rev6/5の評価ボード:NUCLEO-G474RE設定記述ミス

「苦戦」理由は、UM2262 Rev6/5の8.1評価ボード:NUCLEO-G474RE設定記述に間違いがあるからです。

UM2262 8.1には、STM32G4のDBANKビット有効化と記述されていますが、これは「無効化が正しい」です。STM32CubeProgrammerで無効化に設定してください。

STM32G0評価ボード:NUCLEO-G071RBに関しては、記述にミスはありません。本稿の関連部分をNUCLEO-G071RBへ読替えると、全て正常動作します。

STM32G4シリーズは、STM32G0シリーズよりも約1年後に発売されました。新しいMCUのためUM2262に記述ミスがあるのだと思います。

STM32G0/G4のRoot of Trust全体まとめ

STM32G0/G4のRoot of Trust(1)~(3)、いかがでしたでしょうか? セキュリティ機能の実装は、IoT MCUでは必須です。従来のMCU開発へ追加する機能や手間、セキュリティ知識も当然必要になります。

これら追加分は、一般的な開発者が、オリジナリティを加えるべき部分では無いと思います。そこで、これら追加分を、できるだけ簡潔に解り易く説明したつもりです。Root of Trust (1)~(3)で、下記STM32マイコンマンスリー・アップデート2020年3月号P4のX-CUBE-SBSFU説明内容が、より解り易くなれば先ずはOKとします。

STM32マンスリー・アップデートP4:X-CUBE-SBSFU説明(出典:STM32マンスリー・アップデート2020年3月号)
STM32マンスリー・アップデートP4:X-CUBE-SBSFU説明(出典:STM32マンスリー・アップデート2020年3月号)

結局、STM32G0/G4シリーズMCUの場合は、通常のMCUアプリケーション開発が第1段、次に、これをIoT MCU化し、Root of Trust機能(SBSFU)を追加実装するのが第2段という、2段階開発になりそうです。この第2段SBSFU実装時に、本稿で用いたデュアル/シングルファームウェアイメージのアプリケーションサンプルが、枠組みとして使えそうです。

STM32G4テンプレートも、弊社通常テンプレート同様、RTOSを使わない疑似マルチタスク実装用(第1段テンプレート)と、開発済みアプリケーションのRoot of Trust SBSFU実装用(第2段テンプレート)の2つに分けてパックで提供しようと考えています。

セキュリティ(盾)は、常に脅威(鉾)との競争です。STM32G0/G4シリーズよりも更にセキュリティを強化したSTM32L5シリーズ(Cortex-M33)など最新MCUの方が、IoT MCU開発には向いているのかもしれません。

この終わりなき競争が続いてセキュリティ時代遅れにならないように、開発中MCUのより早く、かつ、万一より強いセキュリティMCUが必須となった場合でも、MCUコアに依存しない流用性の高いアプリケーション開発が求められます。


SW4STM32からSTM32CubeIDE移設

STマイクロエレクトロニクス(以下STM)MCUの統合開発環境(IDE)を、従来のSW4STM32から新しいSTM32CubeIDEへ移設するのは簡単です。STM32CubeIDE初期画面に、SW4STM32からSTM32CubeIDEへのプロジェクト変換機能があるからです。

しかし、本稿はSTM社自身による新しいSTM32CubeIDE発表を、STM32MCU純正開発ツールラインナップの完成ととらえ、SW4STM32で開発したSTM32FxテンプレートSTM32G0xテンプレートを、STM32CubeMX起点のSTM32CubeIDE移設方法とそのメリットを示します。

SW4STM32/TrueSTUDIOからSTM32CubeIDE移設背景

IDE開発元の買収&消滅、C/C++コンパイラ改版、Eclipse改版、WindowsなどのOS改版等々、IDE移設が生じる原因は、様々です。IDEは、MCU開発者と最も長い付合いをするツールで、しかも顧客先で稼働中ソフトウェアの変更手段ですので、IDE移設はできれば避けたい出来事です。

SW4STM32は、STM32MCU向けコードサイズ制限なしの無償IDEで、サードパーティAC6社が提供してきました。また、サードパーティAtollic社のTrueSTUDIOも同じくSTM32MCU向け無償IDEとして人気がありましたが、Atollic社をSTMが買収し、TrueSTUDIOはDiscontinue、代わりにSTM自社開発のSTM32CubeIDE無償提供を始めました(Atollic社買収の目的は、STM32CubeIDE開発だと思います)。

STM32 Software Development Tools(出典:STMサイト)
STM32 Software Development Tools(出典:STMサイト)

ポイントは、従来サードパーティが提供してきたコードサイズ制限なし無償IDEを、STM自らSTM32CubeIDEで提供し、「STM32CubeMX/IDE/Programmer/Monitorから構成されるSTM純正のSTM32MCU開発ツールラインナップが完成」したことです(上図)。

このうち、STM32CubeMoniterは、比較的新しいデバッガで、本ブログで紹介を予定しています。

STM32CubeIDEフォルダ構成

STM32CubeIDEは、SW4STM32やTrueSTUDIOよりも後発IDEですので、SW4STM32/TrueSTUDIO開発プロジェクトを、STM32CubeIDEプロジェクトへ変換し取込む機能があります。この機能の使用結果が下図左側です。

STM32CubeIDE変換機能移設プロジェクト(左)とSTM32CubeIDE新規プロジェクト(右)のフォルダ構成比較
STM32CubeIDE変換機能移設プロジェクト(左)とSTM32CubeIDE新規プロジェクト(右)のフォルダ構成比較

左側は、弊社がSW4STM32で開発したSTM32G0x SimpleTemplateプロジェクトを、STM32CubeIDEの変換機能を使ってSTM32CubeIDEプロジェクトへ移設後のProject Explorer、一方、右側は、STM32CubeIDEで新規にSTM32G0プロジェクトを作成した時のProject Explorerです。

左右でプロジェクトのフォルダ構成が異なっていることが判ります。

左:変換機能利用の移設プロジェクトは、従来のSW4STM32フォルダ構成がそのままSTM32CubeIDEで再現されます。

右:STM32CubeIDE新規プロジェクトのフォルダ構成は、Coreフォルダ内にIncフォルダとSrcフォルダがまとめられています。これがSTM32CubeIDE本来のフォルダ構成です。
※ここでのCoreは、下図Application code層を示します。

STM32CubeIDE本来のフォルダ構成は、MCUがCortex-M4のSTM32G4などへ代わっても、Core>Inc/Src構成は不変で、Driversフォルダの中身がSTM32G4対応へ変わるのみです。つまり、よりCMSIS対応のアプリケーション開発に向いた構成です。

CMSIS Structure(出典:Keil CMSIS Version 5.6.0 Generalサイト)
CMSIS Structure(出典:Keil CMSIS Version 5.6.0 Generalサイト)

※CMSIS対応は、関連投稿:mbed OS 5.4.0のLチカ動作、LPCXpresso824-MAXで確認の3章 CMSISを参照してください。

このようにSTM32CubeIDEは、開発者が「本来のアプリケーション開発に集中し易い、つまりIncとSrcのコード作成に集中できるMCU非依存のフォルダ構成」です。

さらに、他の「STM32MCU純正開発ツールとの相性良さや、新発売MCUデバイスへの素早い対応」も期待できます。

これらは、サードパーティIDEになかったSTM自社開発STM32CubeIDEの大きなメリットです。

STM32CubeMX起点のSTM32CubeIDE移設

STM32Fx/G0xテンプレートは、SW4STM32で開発しました。STM32CubeIDEプロジェクト変換機能を使って、従来SW4STM32フォルダ構成のままSTM32CubeIDEへの移設は簡単です。しかし、前章のSTM32CubeIDE本来のフォルダ構成の方が、より大きなメリットが期待できます。

そこで、本来のSTM32CubeIDEプロジェクトフォルダ構成へ、SW4STM32プロジェクトを移設します。

これには、STM32Fx/G0xテンプレート開発時に自作したSTM32CubeMXプロジェクトファイル(前章の左側:SimpleTemplate.ioc)を使います。

STM32CubeMXは、STM32MCUソフトウェア開発の起点となるコード生成ツールです。このSTM32CubeMXから移設を始めれば、次段のSTM32CubeIDEも本来の新規プロジェクト構成で自動生成されます。

さらに、開発アプリケーションで使うLL API/HAL APIの選択や変更も、STM32CubeMXで行います。従って、LL APIが「主」で開発したSTM32G0xテンプレートを、HAL APIへ変えるのも容易です。
※LL API「主」からHAL APIへも「主」へ変更する理由は、STM32G0シリーズがRoot of Trust対応メインストリーム(汎用)MCUだからです。STM32G0専用のLL APIアプリケーションよりも、汎用HAL APIアプリケーションの方が、Root of Trust実現には向いています。詳しくは、関連投稿:STM32G0/G4のRoot of Trust(2)を参照してください。

SW4STM32のSTM32CubeMXプロジェクトファイル(SimpleTemplate.ioc)を起点としてSTM32CubeIDEへ移設したProject Explorerが下図です。前章の右側:STM32CubeIDE新規プロジェクトと同じフォルダ構成で移設されていることが判ります。

STM32CubeMXプロジェクトファイル起点でSTM32CubeIDEへ移設
STM32CubeMXプロジェクトファイル起点でSTM32CubeIDEへ移設

但しこの方法では、SW4STM32でユーザ(筆者)が追加作成したファイル、前章左側:Launcher.c/Led.c/Lpuart.c/UserDefine.hは、手動で移設する必要があります。

まとめ

STM32CubeIDEの提供で、STM32MCU純正開発ツールラインナップが完成しました。
※STM32CubeIDE v1.3.0に残っていた日本語文字化けは、コチラの投稿方法で解決しました。

SW4STM32/TrueSTUDIOなどの従来IDEからSTM32CubeIDE 移設のメリットは、他のSTM純正開発ツール(STM32CubeMX/Programmer/Monitor)との好相性や新発売MCUデバイスへの早い対応です。

従来IDEプロジェクトの移設は、STM32CubeIDEプロジェクト変換機能を使うと簡単です。しかし、移設メリットを活かすには、旧IDEフォルダ構成から、STM32CubeIDE本来の構成となるSTM32CubeMXプロジェクト起点の移設を、弊社STM32Fx/G0xテンプレートへ適用します。

STM32CubeIDE対応の各テンプレート改版完成は、本ブログで発表します。

STM32G0/G4のRoot of Trust(2)

STM32G0/G4シリーズRoot of Trust実現の第2回目は、初めにRoot of Trustを実現するセキュア・ブートの説明にトライし、直にセキュア・ブートとセキュア・ファームウェア更新を実装するSTM32G4テンプレート開発環境の構築方法を示します。

セキュア・ブート説明をこまごま続けるよりも、具体的なRoot of Trust実現開発環境を示す方が、実務的(短絡的?)だからです。

セキュア・ブート

第1回紹介の日本語版UM2262、P1概要:セキュア・ブート説明を抜粋したのが以下です。

‘セキュア・ブート(信頼の起点となるサービス)は、システムリセット後に必ず実行される改変不可のコードで、無効なコードや悪意のあるコードを実行しないために、実行前に毎回STM32の静的保護を確認し、STM32実行時保護を有効化してから、ユーザアプリケーションコードの認証および整合性を検証します。’

英語直訳で難解です(各単語の事前理解が必要なセキュリティ関連説明は、殆どがこんな感じですが…)。

ただ、下線部:「必ず実行される改変不可のコード」なので、理解不足や多少間違って解釈しても、セキュア・ブートコードを実装すれば、それで十分かもしれません😅。

セキュア・ブート解釈

図1.セキュアブートの信頼の起点(出典:UM2262)
図1.セキュアブートの信頼の起点(出典:UM2262)

要は、ユーザが開発したアプリケーション実行前に、MCUが勝手に行うブート処理のセキュリティを高度にしたものがセキュア・ブート(SB)だと解釈します。

従来のブート処理は、リセット後、MCU内蔵クロック発振器の安定化待ちやRAM領域初期化などの処理を何の疑いもなく実行し、その後、ユーザ開発アプリケーションを起動していました。

セキュア・ブート処理は、前章のセキュア・ブート処理を行い(図1.①)、その結果をUM2262:9章の表6. 起動時エラーメッセージ(下表)で示すように認証し②、「エラーなし。成功。」時のみ、③ユーザ開発アプリケーションを起動します。

表6. セキュア・ブート起動時のエラーメッセージ(出典:UM2262)
表6. セキュア・ブート起動時のエラーメッセージ(出典:UM2262)

パソコンで例えると、従来ブートがBIOS起動、セキュア・ブートがUEFI起動に相当すると考えれば良いのかもしれません。

X-CUBE-SBSFUはHAL API補完

Root of Trust実現で使うSTM32Cube拡張パッケージ:X-CUBE-SBSFUは、STM32MCU間の移植性を重視しているためHAL(Hardware Abstraction Layer)ベースです。

弊社発売中のSTM32G0xテンプレート(Version1)は、高速性を活かすエキスパート向けLL(Low layer)APIが「主」、HAL APIは「従」としてSW4STM32で開発しました。しかし、STM32G0でのRoot of Trust実現には、HALベースのソフトウェア開発が適しています。

LL/HAL混在利用は、関連投稿:STM32CubeMXのLow-Layer API利用法 (2)の4章で示した注意が必要です。X-CUBE-SBSFUは、アプリケーション起動前のHAL利用で、起動後のユーザアプリケーションのLL利用の場合は、問題ないかもしれません。この点は、今後明らかにしていきます。

いずれにせよSTM32G0xテンプレートは、IDEをSW4STM32から新しいSTM32CubeIDEへ移設すると同時に、Root of Trust実現に向けHAL APIも「主」とし、STM32CubeIDEで「再開発」してVersion 2に改版する予定です。

セキュリティ関連の説明はここまでにして、STM32G4シリーズでRoot of Trust実現の具体的方法に移ります。

Root of Trust実現STM32G4テンプレート開発環境

Root of Trust実現にセキュア・ブート(SB)機能とセキュア・ファームウェア更新(SFU)機能を実装する汎用STM32G4シリーズのテンプレート開発環境は、以下とします。

  • 統合開発環境:STM32CubeIDE v1.3.0、2020/02/26
  • STM32Cube拡張パッケージ:X-CUBE-SBSFU v2.3.0、2020/01/17
  • STM32G4評価ボード:NUCLEO-G474RE(Cortex-M4/170MHz、Flash/512KB、RAM/128KB)

この環境で実現するセキュリティ機能が、UM2262の6.1概要に記載されたものです。これら機能理解に不明確な部分もありますが、内容把握済み、これら機能実現ためX-CUBE-SBSFUを使うと割切ります。開発環境を使っているうちに、(多分)理解度が上がるでしょう😅。

なおUM2262日本語版は、英語版Rev5からの翻訳なのでサポートIDEにSW4STM32はありますが、新しいSTM32CubeIDEがありません。しかし、最新英語版UM2262 Rev6に、STM32CubeIDEが追加されましたので本ブログでもSTM32CubeIDEを使います。

また、セキュリティ機能をテストするNUCLEO-G474RE用サンプルアプリケーションもX-CUBE-SBSFUに添付されていますので、これを以降の説明に使います。

UM2262では、STM32CubeIDEを使ったRoot of Trust開発環境の構築手順が判りにくいので、以下に説明を加えます。

構築手順1:STM32CubeIDEへのRoot of Trust SW4STM32プロジェクトインポート

X-CUBE-SBSFU v2.3.0には、SW4STM32プロジェクトが添付されていますが、未だSTM32CubeIDEプロジェクトの添付はありません。

そこで、STM32CubeIDEのInformation CenterからImport SWSTM32 projectをクリックし、X-CUBE-SBSFU添付SW4STM32プロジェクトを変換(Import)し、STM32CubeIDEプロジェクトを新規作成します。

STM32CubeIDEのSW4STM32プロジェクトインポート
STM32CubeIDEのSW4STM32プロジェクトインポート

STM32G4評価ボード:NUCLEO-G474REのSW4STM32プロジェクト6個を、STM32CubeIDEへインポートする時のダイアログです。

Finishクリックで、プロジェクト毎に下図2回の同意を求められますので、OKをクリックします。

STM32CubeIDE Projects Converter
STM32CubeIDE Projects Converter

構築手順2:Root of Trustサンプルアプリケーションのコンパイル

インポートした6個のプロジェクトは、シングルファームウェアイメージ:NUCLEO-G474RE_1_Imageとデュアルファームウェアイメージ:NUCLEO-G474RE_2_Imageの2種類のサンプルアプリケーションです。

2種類のRoot of Trustサンプルアプリケーション
2種類のRoot of Trustサンプルアプリケーション

シングル/デュアルファームウェアイメージの違いは、次章で説明します。

このサンプルアプリケーションは、それぞれ図15のように、_SECoreBin、_SBSFU、_UserAppの順番でプロジェクトをコンパイルする必要があります。図示のように前段コンパイル生成出力を、次段コンパイル入力に使うからです。

図15. アプリケーションのコンパイルステップ(出典:UM2262)
図15. アプリケーションのコンパイルステップ(出典:UM2262)

この順番を守ってコンパイルした時のみ_UserAppの出力オブジェクトが生成されます。

Windowsセキュリティソフト(Avastなど)によっては、コンパイル途中でワーニングを出力することがありますが、暫く待つとコンパイルを継続します。

シングルファームウェアイメージとデュアルファームウェアイメージ

図15は、SBSFU処理後のFlashメモリ配置を示しています。

図15の右側黄色部分:アクティブなイメージ領域だけをSFU処理で使うサンプルアプリケーションが、シングルファームウェアイメージです。右側黄色部分の上側、イメージのダウンロード/バックアップ領域に、図2のネットワーク(②通信チャネル)経由の新しいファームウェアを一旦入れるのが、デュアルファームウェアイメージです。

図2.セキュアファームウェア更新プロセス(出典:UM2262)
図2.セキュアファームウェア更新プロセス(出典:UM2262)

デュアルファームウェアイメージは、SFU処理中に電源断で中断しても、電源復帰後にSFU継続が可能です。また、アクティブなイメージ領域で動作中アプリケーションと並行してダウンロードが可能です。

シングルファームウェアイメージは、新しいファームウェアを、アクティブなイメージ領域上へ直接更新します。

デュアルファームウェアイメージは、フェールセーフな分、Flash容量はシングル比、倍必要になります。一方、シングルファームウェアイメージは、ユーザが使えるFlash容量が大きいので、デュアルよりも大きなアプリケーション開発ができます。

※ここで使ったセキュリティ用語:ファームウェアイメージとは、STM32CubeIDEのコード生成ツールSTM32CubeMXがデバイス毎に用いるファームウェア(弊社ならFW_F0/F1/G0/G4)とは別物です。図15の黄色部分を示します。

*  *  *

以上で、STM32CubeIDEを使ったRoot of Trust実現のセキュア・ブート(SB)、セキュア・ファームウェア更新(SFU)機能を持つSTM32G4テンプレート開発環境の構築と、SBSFUに使うシングル/デュアルファームウェアイメージの2種サンプルアプリケーションを説明しました。

次回、このSTM32G4テンプレート開発環境とデュアルファームウェアイメージのサンプルアプリケーションを使って、Root of Trust実現の動作説明を予定しています。

STM32G0/G4のRoot of Trust(2)まとめ

  • 信頼の起点:セキュア・ブート(SB)は、リセット後に必ず実行される改変不可能コード。
  • SB処理後、エラーなし認証時のみ、ユーザアプリケーション起動。
  • STM32Cube拡張パッケージ:X-CUBE-SBSFUは、HAL API補完。
  • STM32CubeIDEでRoot of Trust実現のセキュア・ブート(SB)、セキュア・ファームウェア更新(SFU)機能実装STM32G4テンプレート開発環境と構築手順説明。
  • SBSFUアプリケーションのデュアルファームウェアイメージとシングルファームウェアイメージの特徴説明。

SB、SFU実現には、暗号化や図1/2/15掲載の鍵、セキュアエンジンなど、本稿で説明を省いた(すっ飛ばした)様々なセキュリティ処理が必要です。UM2262付録の章に、これら詳細が記載されています。

本質的なセキュリティ理解には、これら各処理の理解積重ねが必要だと思います。付録の章を一読しておくと、今後いろいろな場面で役立ちます。

STM32G0/G4のRoot of Trust(1)

2020年3月号STM32マンスリー・アップデートのP4に、STM32マイコンでRoot of Trustを実現するセキュリティ・ソフトウェア・パッケージ:X-CUBE-SBSFUが紹介されています。

セキュア・ブート、セキュア・ファームウェア更新、Root of Trust…などIoT MCUセキュリティ用語満載で、投稿:総務省によるIoT機器アップデート機能義務化に関連しそうな内容です。

解りにくいこれらセキュリティ関連の用語解説と、本ブログ対象STマイクロエレクトロニクスのSTM32G0/G4シリーズのRoot of Trust実現方法を、今回から数回に分けて投稿します。

Root of Trust とX-CUBE-SBSFU、STM32G0/G4

マンスリー・アップデートの説明は、エッセンスのみを抽出した代物なので、リーフレットを使って説明します。

一言で言うと、「Root of Trust実現には、X-CUBE-SBSFUが必要で、対応中STM32MCUが下表」です。

Root of Trust対応中のSTM32マイコン一覧(出典:FLXCUBESBSFU0819J)
Root of Trust対応中のSTM32マイコン一覧(出典:FLXCUBESBSFU0819J)

つまり、Root of Trustは全てのSTM32MCUで実現できる訳ではなく、表中のMCU、メインストリーム(汎用)・マイコンの場合は、STM32G0とSTM32G4がセキュア・ブート(SB)とセキュア・ファームウェア更新(SFB)に対応しておりRoot of Trustを実現しています。

X-CUBE-SBSFUの下線部SBはセキュア・ブート、SFUはセキュアFW更新を示します。X-CUBEは、STM純正ソフトウェアツールの総称です。

信頼性を実現するハードウェア/ソフトウェアの根幹部分を、Root of Trustと呼びます。

汎用MCUでRoot of Trustの実現には、ハードウェア/ソフトウェア両方に相応の能力が必要で、従来からある汎用STM32Fxシリーズではなく、新しい汎用STM32G0/G4にSBとSFUが実装されたのだと思います。

ということは、総務省のIoT機器アップデート機能義務化が実施されると、IoTエッジで使う汎用MCUは、必然的にSTM32G0/G4シリーズになるかもしれません。
※X-CUBE-SBSFUは、移植性の高いHAL API利用のため、従来汎用STM32Fxへも流用可能かもしれません。しかし、現時点では、表記STM32G0/G4のみ対応と解釈しています。

STM32汎用MCUラインナップ
STM32汎用MCUラインナップ(出典:STM32 Mainsterm MCUsに加筆)

用語を説明したのみですが、Root of Trust とX-CUBE-SBSFU、汎用マイコンSTM32G0/G4の関係が、マンスリー・アップデートエッセンスより見えてきたと思いますがいかがでしょう。

さらに、一歩踏み込んで、STM32G0/G4のセキュア・ブート、セキュア・ファームウェア更新方法やセキュリティの背景などの詳細は、次回以降説明します。

X-CUBE-SBSFUユーザマニュアル:UM2262

次回以降の説明は、X-CUBE-SBSFUユーザマニュアル日本語版(2019 年 11 月14日):UM2262を基に行います。

UM2262は、X-CUBE-SBSFU対応中の全てのSTM32マイコン(ハイパフォーマンス/超低消費電力/メインストリーム(汎用)/ワイヤレス)が併記されています。

そこで、STM32G0とSTM32G4関連のみを抜粋し、特にセキュア・ブート(SB)とセキュア・ファームウェア更新(SFU)の設定方法と背景を中心に説明します。販売中のSTM32G0xテンプレートと、開発予定のSTM32G4テンプレートに関連するからです。

本稿で示したRoot of Trustを、STM32G4テンプレートに実装するかは未定です。しかし、IoTエッジマイコンのSTM32G4らしさを出すには、Root of Trust実現は必須だと思います。

また、STM32G0xテンプレートは、まずVersion 2改版で新統合環境:STM32CubeIDE v1.3.0への対応を予定しております(現行版は、SW4STM32開発のVersion 1)。
※STM32G0関連の投稿は、本ブログ右上のSearch窓へ、“STM32G0”と入力すると、効率よく投稿が集まります。新汎用STM32G0の特徴、STM32G0xテンプレートのことが解ります。

STM32G0へのRoot of Trust実装も未定ですが、対応する場合でもVersion 2より後にするつもりです。

従って、具体的なRoot of Trust実現方法は、STM32G4シリーズで先行、その後にSTM32G0シリーズが続くという順番になります。

TrustZone対応STM32マイコン体験セミナー(セキュリティ編)

5月22日(品川)と7月31日(大阪)に、2020年2月発売STM32L5マイコン(Cortex-M33/110MHz)を使ったSTM主催、定員30名、4時間半のTrustZone対応STMマイコン体験セミナー(セキュリティ編)が開催されます。

STM32L5は、PSA Certifiedレベル2認証を取得済みのTrustZoneマイコンです。PSA認証は、関連投稿:ARM MCU変化の背景の2章の3:セキュリティ対応をご覧ください。STM32L5のTrustZone実現は、専用のSTM32Cube拡張パッケージ:STM32CubeL5を使っています。

セミナー概要の冒頭に、「IoTセキュリティに関する法令やガイドラインの整備が進んでいます」とあり、具体的にIoTセキュリティ機能のSTM32L5への実装と必要性が解ると思います。セミナーに参加し、エキスパートから色々な情報を仕入れたいのですが、COVIC-19の影響で出張ができるか?…、Webinarなら嬉しいのですがね😅。

評価ボード付き無料セミナーです。ご興味がある方は、参加してはいかがでしょう。

STM32G0/G4のRoot of Trust(1)まとめ

  • Root of Trust実現に、STM32Cube拡張パッケージ:X-CUBE-SBSFUが必要。Root of Trust対応中の汎用マイコンは、STM32G0/G4シリーズ。
  • 信頼性実現のハードウェア/ソフトウェア根幹部分をRoot of Trustと呼ぶ。
  • IoT機器アップデート機能義務化なら、IoTエッジ汎用MCUは、STM32G0/G4シリーズになる可能性あり。
  • STM32G0/G4シリーズのRoot of Trust実現方法、SB(セキュア・ブート)とSFU(セキュア・ファームウェア更新)は、UM2262を使い次回以降説明。

ここまでは、比較的簡単にRoot of Trust、X-CUBE-SBSFU、STM32G0/G4が説明できたと思います。ここからが、セキュリティの難解なところで、SBだけでも次回上手く説明できるか自信がありません。結果は、次回のブログ更新で判ります。

TI.comの新しい購入機能

米)半導体大手テキサスインスツルメンツのサイト:TI.comに追加された新しい製品購入機能を紹介します。

TIは、アナログICやDSP(Digital Signal Processor) 、本ブログ掲載の低電力動作Cortex-M4マイコンMSP432など多くの半導体デバイスや製品を開発・販売しています。ただ、競合他社と比べると、従来は個人調達に便利な通販のDigiKeyやMouserの取扱いTI製品品揃えが少ない傾向がありました。新しいTi.com購入機能は、これを改善できます。

TI.comの新しい購入機能

DigiKeyやMouserと同じように、TI.comで直接TI製品やデバイスを購入できます。違いは、TI製品のみを扱う点。もちろん価格は多少違いますが、品揃えは豊富です。下図のように、試作から生産に至るまで調達できます。

TI.comの新しい購入機能(出典:myTI newsletter)
TI.comの新しい購入機能(出典:myTI newsletter)

他社MCUベンダサイトのカートは、DigiKeyやMouserなどの外部通販へのリンクが一般的です。TIは、一律配送などのサービスも含めてTI自らが通販を行うという点が他社と異なる新しい機能です。

最大30個までという制限は設けていますが、個人購入や試作レベルの調達なら十分利用できます。通販会社にとっては脅威でしょう。TIは、手数料を通販会社に払うよりも、全製品の通販を自社で行う方法を選択したのだと思います。

MSP432デバイス品揃え豊富、低価格

本ブログ掲載の低電力動作MSP432評価ボード:MSP-EXP432P401R(ARM Cortex-M4F/48MHz、256KB/Flash、64KB/RAM、浮動小数点ユニット、DSPアクセラレーション)も、もちろんTI.comから購入できます。

さらに、評価ボードでの開発後、実機で利用するFlash/RAM容量が異なる様々なMSP432デバイスも購入できます。

評価ボード:MSP-EXP432P401Rは、CCS Cloud IDEやArduino IDEに似たEnergia IDEが使えるなど、他社MCU開発にないユニークなソフトウェア開発環境が特徴です。

CCS DesktopとCCS Cloud、Energia IDE比較(出典:TIサイト)
CCS DesktopとCCS Cloud、Energia IDE比較(出典:TIサイト)

※Energia IDEの詳細は、関連投稿:MSP432オープンプラットフォーム開発環境を参照してください。
※CCS Cloud IDEの使い方は、関連投稿:CCS Cloud IDEを参照してください。

Energia IDEは初めてソフトウェアを開発する方に、CCS Cloud IDEはいつでも何処でも場所を選ばずにブサウザだけでソフトウェアを開発したい方に向いています。

また、パンデミック表明となったCOVID-19終息宣言がWHOからでるまでは当分の間、在宅勤務やMCU開発の自己研鑽時間、または数人でのテレワークMCU開発などの機会も増えるでしょう。これらにもCCS Cloud IDEは、活用できると思います。

評価ボードを使ったプロトタイプ開発は、最終的に実機で使うMCUデバイスの選択が的確にできます。つまり、実機でよりFlash/RAM容量が必要になるか、それともより低価格デバイスで製品や製品改良などにも十分賄えるかなど、製品実装MCUの選択が、プロトタイプ結果に基づいて具体的にできる訳です。

新しいTI.com購入機能は、MSP432デバイスの品揃えが豊富です。プロトタイプ開発の選択結果を反映した実機MCUデバイス調達が、直接Ti.comから低価格で可能です。通販DigiKeyやMouserの代替になりえます。

STM32CubeIDE更新、文字化け解決

STマイクロエレクトロニクスの統合開発環境:STM32CubeIDEがv1.3.0に更新されました(2月28日、更新自動通知メールにて把握)。デフォルト設定のWindows版STM32CubeIDEは、エディタで追記した日本語コメントに文字化けが発生します。これは、昨年投稿したSTM32CubeIDE v1.1.0v1.2.0と同じで、最新版でも解決されません。

そこで、対策にデフォルト設定を2か所変え、日本語文字化け解決を確認しました。また、Linux Debian版STM32CubeIDEとSW4STM32は、最新環境でもデフォルトで文字化けが無いことも確認しました。

Windows版STM32CubeIDE日本語文字化け発生箇所

2019年4月新登場STマイクロエレクトロニクス統合開発環境:STM32CubeIDE-Winの日本語コメント文字化けは、

  • SW4STM32プロジェクトのSTM32CubeIDEインポート後
  • プラグイン版STM32CubeMXでのコード再生成時

に、エディタでソースコードに追記した日本語コメントに文字化けが発生します。
※Windows版は、Windows 10 Pro 1909の話です。

STM32CubeIDE-Win v1.3.0日本語文字化け対策

数回のメジャー更新を経て登場後約1年のv1.3.0でも、この文字化けはデフォルトのままでは未解決です。そこで、ネット検索したところ、コチラの対策を得ました。

STM32CubeIDEのデフォルト設定を、2か所変更します。

STM32CubeIDEの日本語文字化け2箇所の対策
STM32CubeIDEの日本語文字化け2箇所の対策
  1. フォント設定を、デフォルトConsolasからメイリオなどの日本語文字セットへ変更(ワークスペース毎)
  2. Text file encoding設定を、デフォルトUTF-8からShift-JISへ変更(プロジェクト毎)

※1は、STM32CubeIDEのWindowタブ>Preferenceダイアログ検索窓へ”font”入力>Colors and Font選択>C/C++選択>Editor選択>C/C++ Editor Text Fontを選択し、Edit…クリックで左図表示
※2は、プロジェクト選択>Propertiesクリックで右図表示

右図のようにプルダウンメニューにShift-JIS選択肢が無い時は、Shift-JISと直接入力し、Apply and Closeをクリックします。

1はワークスペース毎、2はプロジェクト毎に設定が必要です。

これら2か所の変更で、SW4STM32プロジェクトインポート後とSTM32CubeMXコード再生成時、どちらもエディタ追記日本語コメント文字化けは解決できました。

以上で、従来のSW4STM32から新しいSTM32CubeIDEへ、日本語コメント文字化け無しにSTM32MCU開発環境を移行できます。

STM32CubeIDE特徴

STM32CubeIDEは、コード生成ツール:STM32CubeMX、開発デバイスファームウェア(弊社ならFW_F0/F1/G0/G4)全てを1パッケージ化し、全て最新版のみを提供する特徴があります。投稿時のSTM32CubeIDE v1.3.0が下図です。

簡単に言うと、開発ソフトウェアが全てSTM32CubeIDEへプラグインされた形式です。

STM32CubeIDE全体構成
STM32CubeIDE全体構成

STM32CubeIDE起動時、またはCheck for Updatesにより、IDEを含めた各プラグイン更新を確認し、常に最新開発環境となります(悪名高いWindows Updateに似ているような…😅)。

これは、プラグイン版STM32CubeMX v5.6.0に、旧ファームウェア選択機能が無いことからも解ります。

最新ファームウェアを使うSTM32CubeMXプラグイン版(左)とファームウェア選択可能なスタンドアロン版(右)
最新ファームウェアを使うSTM32CubeMXプラグイン版(左)とファームウェア選択可能なスタンドアロン版(右)

例えば、顧客先で稼働中ソフトウェアへ変更を加えるなど旧ファームウェアのまま開発希望の場合は、スタンドアロン版STM32CubeMX v5.6.0を使えば、右図のように旧ファームウェア選択も可能です(関連投稿:v1.2.0の開発環境更新リスク、ファームウェア更新リスク回避策の章に背景説明があります)。

純正STM32Cubeツール

STM32MCUソフトウェア開発に使えるIDEは、下図中央のようにIAR:Embedded Workbench、ARM:Keil、AC6:SW4STM32、etc.などサードパーティ製も数多くあります。しかし、純正STM32CubeツールのSTM32CubeIDEが、STマイクロエレクトロニクス一押しの統合開発環境だと思います。

STM32 Software Development Tools(出典:STMサイトに加筆)
STM32 Software Development Tools(出典:STMサイトに加筆)

もちろん、従来からあるSW4STM32もまだ現役(Active)です。ST Communityには、今も多くのSW4STM32事例があります。

そこで、Windows版STM32CubeIDE以外の、SW4STM32とLinux Debian版STM32CubeIDEの現状を調べました。

STM32CubeIDE-DEB

64ビット版のみですが、STM32CubeIDE v1.3.0のLinux Debian版インストーラが、Windows版STM32CubeIDEと同じ純正ソフトウェア入手サイトにあります。

STM32CubeIDE Debian Linux Installer
STM32CubeIDE Debian Linux Installer

筆者は、DebianよりもMintが好きなので、STM32CubeIDE-DEBをLinux Mint 19.3 MATE (64-bit)へインストールし、デフォルト設定でも日本語文字化け無し、評価ボードで正常動作することを確認しました。

STM32CubeIDE-DEBは、デフォルトで日本語文字化けなしで動作
STM32CubeIDE-DEBは、デフォルトで日本語文字化けなしで動作

Mintへのインストール方法が下記です。途中で長いライセンス同意を求められます。

chmod +x st-stm32cubeide_1.3.0….sh
sudo ./st-stm32cubeide_1.3.0….sh、または、sudo bash st-stm32cubeide_1.3.0….sh
※NXP:MCUXpresso IDE v11.1.0のInstallation Guide, Appendix A – Linux Installationを参考にしました。

STM32CubeMXやデバイスファームウェアは、Windows版と同様全てプラグインです。Linux版SW4STM32既成プロジェクトが手元に無いのでインポートは試せませんが、問題無いと思います。

リリースノート:RN0114のLinux動作テスト環境にMintは有りません。自己責任でNXP:MCUXpresso IDE v11.1.0 Linux版ともども、Mint上でSTM32CubeIDE-DEBが正常動作したことをお知らせします。

SW4STM32とスタンドアロン版STM32CubeMX v5.6.0

SW4STM32とスタンドアロン版STM32CubeMX v5.6.0で開発環境を構築する場合は、デフォルトでも日本語文字化けは発生しません。従来環境に慣れた方は、SW4STM32もそのまま使えると思います。

お知らせ:STM32FxテンプレートとSTM32G0xテンプレート改版予定

STM32CubeIDE-Win v1.3.0に加えた本稿2か所変更が、次版以降のSTM32CubeIDEにも必要かは判りません。ただ、いまさらShift-JIS設定?という気はします。WindowsでShift-JIS継続利用の弊害は、コチラの記事がよく解ります。

しかし、懸案であった日本語コメント文字化けが解決、新登場後1年経過しv1.3.0となったこのタイミングで、従来SW4STM32から新しいSTM32CubeIDEへ開発環境を乗換えるのもチャンスだと思います。SW4STM32更新頻度が減ったことや、他の純正STM32Cubeツールとの相性良さも期待できるからです。

そこで、SW4STM32で開発・販売したSTM32FxテンプレートSTM32G0xテンプレートを、STM32CubeIDE-Winを使って再開発に着手し、新にVersion 2として販売する予定です。進行状況などは、本ブログでお知らせします。

MCUベンダAPI生成ツール比較

お知らせ

弊社サイト:マイコンRTOS習得を2020年版へ改版しました。前稿までのFreeRTOSサンプルコード(1)~(5)結果を、2017年版へ反映させた結果です。是非、ご覧ください。

MCUベンダAPI生成ツール一覧

FreeRTOSサンプルコード(1)で予告したベンダ毎に異なるAPI生成ツールやその違い、サンプルコードとの関係を説明します。本ブロブ掲載MCUベンダ5社のAPI生成ツール一覧が下表です。

MCUベンダトップシェア5社のMCU API生成ツール一覧
ベンダ API生成ツール ブログ掲載MCU API生成方法
Runesas CS+ RL78/G1x 個別ハードウェア設定
NXP SDK LPC111x/LPC8xx/Kinetis E/LPC5411x MCU設定
STM STM32CubeMX STM32Fx/STM32Gx 個別ハードウェア設定
Cypress PSoC Creator PSoC4/PSoC4 BLE/PSoC4000/PSoC6 個別ハードウェア設定
TI CCS STM432 MCU設定

IDEとは別のAPI生成ツール専用名があり、ツール単独で更新するのが、NXP)SDK、STM)STM32CubeMXです。Runesas)CS+、Cypress)PSoC Creator、TI)CCSは、IDEにAPI生成ツールが組込まれていますので、IDE名称をAPI生成ツール欄に記載しています。
※CS+のAPI生成ツールは、単独でコード生成と呼ぶこともあります。

さて、これらAPI生成ツールには、2種類のAPI生成方法があります。

  • MCU設定:利用MCUを設定し、内蔵ハードウェアAPIを一括生成…NXP)SDK、TI)CCS
  • 個別ハードウェア設定:利用内蔵ハードウェアを個別設定し、APIを生成…Runesas)CS+、STM)STM32CubeMX、Cypress)PSoC Creator

MCU設定タイプのAPI生成ツールは、全内蔵ハードウェアAPIを、ユーザ利用の有無に係わらず一括生成するため、規模が大きく、SDK(Software Development Kit)などパッケージ化してIDEへ提供されます。但し、コンパイル時に利用ハードウェアのみをリンクしてMCUへダウンロードするので、少Flashサイズでも問題はありません。

MCU設定タイプの特徴は、例えば、UART速度設定などのハードウェア動作パラメタは、APIパラメタとしてMCUソースコードにユーザが記述します。

MCU設定タイプのNXP)SDKのUART API例
MCU設定タイプのNXP)SDKのUART API例

一方、個別ハードウェア設定タイプは、UARTなどのハードウェア動作パラメタは、API生成前にGUI(Graphical User Interface)で設定し、設定後にAPIを生成します。このためユーザが、MCUソースコードのAPIに動作パラメタを追記することはありません。

個別ハードウェア設定タイプのSTM32CubeMXのUART API例
個別ハードウェア設定タイプのSTM32CubeMXのUART API例

API生成ツール比較

MCU設定タイプのAPI生成ツールは、使い方がMCU設定のみで簡単です。また、ハードウェア動作パラメタがMCUソースコード内にあるため、動作変更や修正もIDE上で行えますが、人手によるバグ混入の可能性も高まります。

個別ハードウェアタイプAPI生成ツールは、MCUソースコード内のAPI記述が簡素です。生成されたAPI内部に動作パラメタが含まれているからです。但し、ハードウェア動作変更には、IDEから一旦API生成ツールに戻り、APIの再生成が必要です。この場合でも、MCUソースコードは不変ですので、GUI設定にミスが無ければバグ混入は少ないでしょう。

どちらにも、一長一短があります。敢えて分類すると、ソフトウェア開発者向きが、MCU設定タイプ、ハードウェア開発者向きでTP:Test Program応用も容易なのが、個別ハードウェア設定タイプです。

個別ハードウェア設定タイプであっても、Cypress)PSoC Creatorなどは、通常パラメタはBasicタブ、詳細パラメタはAdvanceタブで分け、誰でも設定を容易にしたツールもあります。

MCUソフトウェアは、C言語によるMCU API制御です。MCU API生成ツールの使い勝手が、ソフトウェア生産性の半分程度を占めていると個人的には思います。

サンプルコード/サンプルソフトウェア

各社のサンプルコード/サンプルソフトウェアは、上記API生成ツールのMCUソースコード出力例です。

従って、サンプルコードには、出力例と明示的に判るよう多くのコメントが付加されています。初めてサンプルコードを見る開発者は、注意深くコメントを読んで、そのMCU開発の全体像を理解することが重要です。

全体像が理解済みであれば、より効率的な開発手法、例えば、(推薦はしませんが)個別ハードウェア設定タイプであっても、IDEからAPI生成ツールに戻らずに、直接MCUソースコードでハードウェア動作パラメタを変更するなどのトリッキーな使い方も可能です。

MCU開発とCOVID-19

新型コロナウイルス:COVID-19が世界的に流行しつつあり、工場閉鎖や物流への影響も出始めています。現状は治療薬が無いので、「個人の免疫力と体力」が生死の決め手です。

同時にMCU供給不足/停止など、開発への波及も懸念されます。これに対し「個人で第2のMCU開発力」を持つことが解決策を与えます。

本稿は、MCUベンダトップシェア5社のMCU API生成ツールを比較しました。MCUシェア評価ボード価格や入手性、個人の好みなど、是非ご自分にあった比較項目で、現在利用中のMCUに代わる第2のMCU開発力を持つことをお勧めします。

第2のMCU開発力は、現行と視点が変わり利用中MCUスキルも同時に磨くことができ、様々な開発リスクに耐力(体力)が付きます。短期で効果的な第2のMCU開発力の取得に、弊社マイコンテンプレートがお役に立てると思います。

FreeRTOSサンプルコード(5)

MCUXpresso54114評価ボードSDK付属FreeRTOSサンプルコード調査最終回の本稿は、タスク数=3のプロジェクト、freertos_eventとfreertos_queue、freertos_genericを説明します。

FreeRTOSサンプルコード:タスク数=3

FreeRTOSプロジェクト:タスク数=3
Project Tasks heap_ Additional FreeRTOS APIs Additional Comments
freertos_event 3 4 xEventGroupCreate xEventGroupSetBits
xEventGroupWaitBits

タスクや割込みなどのイベントをグループ化し、他タスク制御。

セマフォと似ているがイベントの論理演算可能。

freertos_queue 3 4 xQueueCreate
xQueueSend
xQueueReceive
vQueueAddToRegistry
タスク間メッセージ通信デモ。キューは、順序維持FIFO構造。
freertos_generic 3 4

キュー、ソフトウェアタイマ、セマフォの組合せデモ。

FreeRTOS.orgサンプルコードに基づき作成。

※freertos_genericのAdditional FreeRTOS APIは、これまでのサンプルAPI組合せのため追加分なし。

FreeRTOS Project:freertos_event

イベントによるタスク制御は、セマフォに似ています。複数のセマフォを1つにまとめたイベントグループを作成(xEventGroupCreate)し、このグループ化した個々のイベント間で論理演算ができることが特徴です。

xEventGroupWaitBitsの例(出典:freertos_event.c)
xEventGroupWaitBitsの例(出典:freertos_event.c)

イベント間の論理演算ができるので、シングルイベントのセマフォよりも柔軟なタスク制御ができます。

FreeRTOS Project:freertos_queue

これまで説明してきたプロジェクトのタスク間制御には、ミューテックスやセマフォ、上記イベントなど全てビット単位のシグナルを使ってきました。最後に説明するプロジェクトfreertos_queueは、タスク間でメッセージを送受信します。

メッセージは、キュー=有限長FIFO(First In First Out)経由で送受信されますので、メッセージの順番は維持されますが、キューが溢れないような使い方が必要です。深すぎるキューはメモリ効率が悪く、浅いキューではメッセージが溢れます。深さ見積もりなどのためにプロトタイプ開発が必要でしょう。

例えば、複数センサ出力をMCUでまとめ、定期的にクラウドへ送信するようなFreeRTOSアプリケーションソフトの素になりそうなプロジェクトです。クラウドサービスにAmazon Web Service(AWS)を使う時には、専用のネットワーク接続ライブラリもFreeRTOSで提供されますので、このアプリケーションとの親和性も良いと思います。

FreeRTOS Project:freertos_generic

MCUXpresso54114評価ボードSDK付属FreeRTOSサンプルコード11個の説明の最後が、このfreertos_genericプロジェクトです。これまで説明してきた10個のサンプルコードを総合的にまとめたプロジェクトで、出典はhttp://www.freertos.org/Hardware-independent-RTOS-example.htmlです。

筆者の下手な説明よりも、実際にソースコードを見て頂くと丁寧なコメント付きです。このソースコードを読んでFreeRTOSの仕組みがすんなりと理解できれば、ベアメタルからFreeRTOSソフトウェア開発へのステップアップ初期段階は完了と言えるでしょう。つまり、10個サンプルコード習得度の自己評価に使えます。

FreeRTOSサンプルコード:タスク数=3の調査結果

  • 複数セマフォを1つにまとめたイベントグループタスク制御は、イベント間の論理演算が可能
  • キュー利用のタスク間メッセージ通信は、深さ設定にプロトタイプ開発が有効
  • freertos_genericは、SDK付属サンプルコード10個の習得度評価に使える
  • メモリ使用法は、heap_4を利用

まとめ:MCUXpresso54114評価ボードSDK付属FreeRTOSサンプルコード調査

5回に渡ってMCUXpresso54114評価ボードSDK付属FreeRTOSサンプルコードをタスク数が少ない順に調査しました。基本的なFreeRTOS機能は、解説済み11個のサンプルプロジェクトでカバーされています。

各プロジェクトの追加分FreeRTOS APIのみを表で示し、しかも弊社サイトマイコンRTOS習得2017の内容は既にご存じという前提で説明したので、解りにくい部分もあったかもしれません。
要するに、ベアメタル開発にFreeRTOS APIを追加すればRTOSソフトウェア開発ができることを強調したかったからです。

FreeRTOSのマルチタスク並列動作、タスク間同期/競合回避手段、これらのFreeRTOS APIのみを理解すれば、ベアメタル開発経験がそのまま活かせます。

今回の1~5回の解説は、マイコンRTOS習得2020年版として2017年版サイトへ改版する予定です。改版後にご覧になれば解りにくさが改善されるかもしれません。

調査目的は、開発予定のベアメタルCortex-M4テンプレートへのRTOS機能応用でした。現時点で、応用内容は不明確です。しばらく時間を頂いて明確化します。

ただ、マルチタスクFreeRTOSと異なり、ベアメタルテンプレートは、全て自分の制御下タスクです。タスク間同期やメッセージ送受信も、特別な工夫なく簡単に実現できます。

FreeRTOS利用MCUのAWS接続(出典:Amazon FreeRTOSの開始方法に加筆)
FreeRTOS利用MCUのAWS接続(出典:Amazon FreeRTOSの開始方法に加筆)

上図のように、AWSへの接続やIoTセキュリティ機能追加など今後必須になるIoT MCUの機能実装は、専用ライブラリベース、特にFreeRTOSライブラリで提供される可能性が高いと予想できます。

これらライブラリは、ベアメタル開発でも利用可能ですが、FreeRTOSソフトウェアの方が親和性も高く開発が容易なことも事実です。

しかも、これら専用ライブラリで実行される処理内容は、本来我々開発者が変更を加えるべきでない定型処理です(もちろんプロパティなどのパラメタは、開発者依存です)。

いずれにしても、MCUXpresso54114を使ったFreeRTOSソフトウェア開発環境と基本機能は習得できたので、ベアメタルCortex-M4テンプレート開発へ活かしていきます。

FreeRTOSサンプルコード(4)

タスク数=2のMCUXpresso54114評価ボードSDK付属FreeRTOSサンプルコードの後半2プロジェクト、MutexとSemaphoreを説明します(前半は、前稿参照)。

FreeRTOSサンプルコード:タスク数=2

FreeRTOSプロジェクト:タスク数=2(後半)
Project Tasks heap_ Additional FreeRTOS APIs Additional Comments
freertos_mutex 2 4

xSemaphoreCreateMutex
xSemaphoreGive

並列動作の共有リソース同期/競合制御。taskYIELDは要注意!

Mutexのセマフォ作成は、   xSemaphoreCreateMutex。

Semaphoreのセマフォ作成は、xSemaphoreCreateBinary。

freertos_sem 1+3 4

xSemaphoreGive

※Freertos_semはタスク数4個。実質はproducer_taskとconsumer_taskの2個。

FreeRTOS Project:freertos_mutex

RTOSソフトウェアのメリットは、複数タスクが「完全に並列動作」することです。ただし、副作用として、共有リソースのアクセス競合が生じます。サンプルコードの場合はIDE Console出力で、その他にUARTやIOポートなど多くの共有リソースがMCUにはあります。

この共有リソースへのセクセス競合を防ぐ手段がミューテックスです。共有リソース使用前に他タスクの使用/未使用を検出し、未使用時のみ利用、利用後は、使用権を戻す操作(xSemaphoreGive)をします。

仮にミューテックス機能が無ければ、英字と数字が混ざった出力になり、使い物になりません。
並列動作のRTOSに、Mutexは必須機能です。

注意点は、Consoleへ部分出力後のtaskYIELDです。

F3クリックで調べましたがtaskYIELDの理由は、筆者には不明です。だだし、コメントを読むとFreeRTOSインプリメント依存部分なので、そのまま弄らない方が良さそうです。共有リソース利用中には、taskYIELDが必要と覚えておけば(とりあえず)良いとします。
※本調査の目的は、ベアメタルCortex-M4テンプレート開発へのRTOS機能応用であって、FreeRTOS自身ではないので、この程度で留めていきます👍。

共有リソース使用検出APIは、xSemaphoreTakeです。前稿freertos_ticklessプロジェクトの割込みISRと処理タスク同期に用いたAPIと同一です。差分は、セマフォ自体の作り方が異なります。ミューテックスの場合は、xSemaphoreCreateMutex、セマフォの場合は、xSemaphoreCreateBinaryです。

違いは、初期値です。ミューテックスは、初期値が使用可能(pdTRUE)になりますが、セマフォは、初期値が使用不可です。どちらも、並列動作タスク間の同期/競合制御として、同じAPI:xSemaphoreTakeを使っているということです。

FreeRTOS Project:freertos_sem

前稿freertos_ticklessで示したISRと処理タスクのセマフォ同期とは別の使用例が、freertos_ semプロジェクトです。同期というより、むしろ排他制御にセマフォを使った例です。

このプロジェクトは、これまでのサンプルコードで最も多い4タスク:1(producer_task)+3(consumer_task)を生成し、2個のセマフォ(xSemaphore_producerとxSemaphore_consumer)を使い、1個のアイテムを4タスク間で利用する例です(Doc>freertos_sem_example.txtによるとランデブーモデル同期と言うようです)。

2セマフォで1共有アイテム利用のランデブーモデル同期
2セマフォで1共有アイテム利用のランデブーモデル同期

1個の(共有)アイテムは、元々produser_taskが持っており、cunsumer_taskへその使用権を与えます(L119:xSemaphoreGive→xSemaphore_consumer)。

並列動作中の3個cumsumer_taskのどれかがこの使用権を取得します(L143:xSemaphoreTaka←xSemaphore_consumer)。使用後は、produser_taskへ使用権を返却します(L141:xSemaphoreGige→xSemaphore_producer)。

produser_taskは、cunsumer_taskの使用権返却を待っており(L121: xSemaphoreTaka←xSemaphore_producer)、返却後、再び最初に戻ってcunsumer_taskへ使用権を与えます。

cunsumer専用セマフォがxSemaphore_consumer、producer専用セマフォがxSemaphore_producerで、それぞれを図示したようにやり取りしながら4タスクが動作します。

ベアメタル風に、ランデブーモデル同期:synchronized in bilateral rendezvous modelを解説すると上記のようになります。

ソースコード上では、どのcumsumer_taskが共有アイテムを獲得するかは不明ですが、評価ボード実行結果は、常にConsumer 0→1→2→0・・・の順番でした。3個のcumsumer_taskプライオリティが同一の時は、生成順に1個のアイテム共有ができるようです。

FreeRTOSサンプルコード:タスク数=2(後半)の調査結果

  • FreeRTOSタスク並列動作副作用の共有リソースアクセス競合回避手段に、ミューテックスがある
  • MCUXpresso54114 のFreeRTOS共有リソース利用途中には、taskYIELDが必要
  • 初期値(pdTRUE)の有無が、ミューテックス作成とセマフォ作成で異なる
  • バイナリセマフォの排他制御利用例に、ランデブーモデル同期がある
  • メモリ使用法は、heap_4を利用

FreeRTOSデバイス依存開発ノウハウ

筆者のOS:Operating System利用アプリケーションソフト開発経験は、Windows PCのみです。Windows OSは、リアルタイム性はありません。そのおかげで、PCアプリケーションソフト開発時に、他タスクへの影響、プライオリティなどは考慮せずに比較的簡単に開発ができました。

ミューテックスやセマフォを利用した覚えもありません。もちろんファイルなどの共有リソースには、それなりのアクセス手順があり、それに従って開発すれば特に問題はありません。

一方MCUでOS利用の場合は、リアルタイム性は無視できません。限られたMCU能力を上手く利用するためのデバイス依存開発ノウハウが、メモリ使用法:heap_4やtaskYIELDだと思います。

これらノウハウは、ソースコード上では解りにくい代物です。また、文章記述できる量も限られます。

これには、評価ボード上でソースコードのパラメタを変えた時の挙動変化を開発者自身がつかんで習得する方法が効率的です。LPCXpresso54114(Cortex-M4/M0+ 100MHz、256KB Flash、192KB RAM)評価ボードは、入手性もよく低価格(約3400円)です。無償LPCXpresso IDEとともにご利用いただければ、本稿やFreeRTOSがより解り易くなります。

PS:FreeRTOSの最新版V10.3.0が2020年2月7日に公開されました。詳細は、リリースノートをご覧ください。

FreeRTOSサンプルコード(3)

タスク数=1の前稿FreeRTOSサンプルコード(2)に続き、本稿は、タスク数=2のMCUXpresso54114評価ボードSDK付属FreeRTOSサンプルコードの前半3プロジェクトを説明します。

FreeRTOSサンプルコード:タスク数=2

FreeRTOSプロジェクト:タスク数=2(前半)
Project Tasks heap_ Additional FreeRTOS APIs Additional Comments
freertos_tickless 2 4

vTaskDelay
xTaskGetTickCount
xSemaphoreCreateBinary
xSemaphoreGiveFromISR
xSemaphoreTake

FreeRTOS低電力動作とSW_taskの2タスク並列動作説明。

Tickless_taskは、vTaskDelay、前稿hello_taskは、vTaskSuspend。

SW_taskは、Tickless_taskに何ら影響を与えない。

freertos_i2c 2 4

xSemaphoreCreateBinary
xSemaphoreGiveFromISR
xSemaphoreTake

master_taskとslave_taskの2タスク構成。正常動作結果は、Console窓出力。DoC>readme.txtでも結果が判る。

freertos_spi 2 4

xSemaphoreCreateBinary
xSemaphoreGiveFromISR
xSemaphoreTake

同上

タスク数=2のサンプルコードは、上記以外にもFreeRTOS特徴のミューテックスとセマフォ利用例がありますが、これらは次回説明します。

FreeRTOS Project:freertos_ tickles

前稿説明のhello_taskは、Console窓に文字を1回出力し、「待ち状態」になりました。
hello_task とよく似たTickless_taskは、文字の代わりにxTaskGetTickCountで得た数字を1回出力し、vTaskDelayで5秒間の「停止状態(=低電力動作:Sleep)」になります。

低電力動作からの復帰Eventで、Tickless_taskは停止状態から実行可能状態へ移行し、スケジューラによって再実行されます。停止時間5秒間のtick回数がConsole窓に出力されます。
※FreeRTOSタスクの状態遷移図は、マイコンRTOS習得2017の第2部を参照。

このプロジェクトは、Tickless_task が、SW_task動作に全く影響を受けないFreeRTOSの特徴を説明しています。

つまり、Tickless_taskと、SW_taskは、それぞれ別々にあたかも自分のタスクがMCUを占有するように記述されており、かつその通り並列動作します。これがFreeRTOS利用ソフトウェア開発の最大メリットです。タスク開発は、ベアメタルソフトウェア開発に比べ簡単に、かつ流用性も大きくなるでしょう。

※SW3プッシュは、ソフトウェア、ハードウェアで何もチャタリッグ防止策をしていない処理の検証にも使えます。試しにSW3を長く押してチャタリッグが発生することを確かめてください。チャタリッグ防止策の必要性が解ります。

FreeRTOS Project:freertos_ i2cとfreertos_ spi

freertos_ i2cとfreertos_spiプロジェクトは、どちらもMCU内蔵I2C、またはSPIを使った外部デバイスとの通信サンプルコードです。どちらもmaster_taskとslave_taskの2タスクから構成されています。

main.cでslave_taskのみをタスク登録し、slave_task内でmaster_taskを登録しています。このように、FreeRTOSスケジューラ起動後でも、任意の場所で新たなタスク登録が可能です。

動作は、最初master_taskでデータ送信し、それをslave_taskで受信、次にslave_taskがデータ送信し、それをmaster_taskで受信し、両タスクとも正常終了します。

この動作シナリオは、slave_taskに記述されており、master_taskのデータ送信開始は、slave_taskのmaster_task登録の結果、並列実行されます。slave_taskのデータ受信と送信完了は、i2c_slave_callbackからのセマフォを使って判断しています。

評価ボード実装Arduinoコネクタ上の配線で、送受信データをループバック接続しますので、評価ボード1台のみで両タクス動作結果が、IDEのConsole窓に出力されます。

MCUXpresso54114評価ボードをお持ちでない方は、両プロジェクトのDoc>readme.txtのRunning the demoにConsole窓出力と同じ結果があるので解ります。

I2C/SPI通信対象のデバイスは、従来からの外付けEEPROMに加え、最近ではIoTセキュティデバイスなどがあります。

IoTセキュティデバイスは例えば、NXPのEdgeLookやMicrochipのCryptoAuthenticationファミリなどがあり、IoT MCUのクラウド接続には、これらデバイス利用が必須になりそうです。

I2C通信のIoTセキュリティデバイス接続例(出典:NXP SE050データシート)
I2C通信のIoTセキュリティデバイス接続例(出典:NXP SE050データシート)

FreeRTOSサンプルコード:タスク数=2(前半)の調査結果

  • FreeRTOS低電力動作(Sleep)は、vTaskDelay(msec)で低電力動作開始と復帰
  • タスク数が2と少ないので、タスク並列動作が解り易く、プライオリティ設定とその意味も理解容易
  • I2C/SPI割込みISRとのタスク同期に、バイナリセマフォ利用
  • 割込みcallback関数でセマフォをgive → 割込み処理タスクでセマフォをtake → セマフォ消滅
  • IoT MCUは、セキュティデバイスとのI2C接続可能性大
  • メモリ使用法は、heap_4を利用

セマフォ(Semaphore)同期は、マイコンRTOS習得2017の第3部:Semaphoreによるタスク同期の章に、図入り解説していますのでご参照ください。

FreeRTOSサンプルソースコードは、MCUXpresso IDEのみでも御覧頂けます。是非、PCへインストールし本稿をご参照ください。