Cortex-M4 アーカイブ - IoT MCUのHappyTech

Cortex-M4評価ボードRTOSまとめ

2021年8月27日2021年12月12日 WithHappy

低価格（4000円以下）、個人での入手性も良い32ビットARM Cortex-M4コア評価ボードのRTOS状況を示します。超低価格で最近話題の32ビット独自Xtensa LX6ディアルコアESP32も加えました。

Vendor	NXP	STマイクロ	Cypress	Espressif Systems
RTOS	FreeRTOS Azure RTOS	CMSIS-RTOS	FreeRTOS Mbed OS	FreeRTOS
Eva. Board	LPCXpresso54114	NUCLEO-G474RE	CY8CPROTO-063-BLE	ESP32-DevKitC
Series	LPC54110	STM32G4	PSoC 6	ESP32
Core	Cortex-M4/150MHz	Cortex-M4/170MHz	Cortex-M4/150MHz Cortex-M0+/100MHz	Xtensa LX6/240MHz Xtensa LX6/240MHz
Flash	256KB	512KB	1024KB	480KB
RAM	192KB	96KB	288KB	520KB
弊社対応	テンプレート販売中	テンプレート開発中	テンプレート検討中	未着手

※8月31日、Cypress PSoC 6のRTOSへ、MbedOSを追加しました。

主流FreeRTOS

どのベンダも、FreeRTOSが使えます。NXPは、Azure接続用のAzure RTOSも選択できますが、現状はCortex-M33コアが対応します。ディアルコア採用CypressのRTOS動作はM4側で、M0+は、ベアメタル動作のBLE通信を担います。STマイクロのCMSIS-RTOSは、現状FreeRTOSをラップ関数で変換したもので実質は、FreeRTOSです（コチラの関連投稿3章を参照してください）。

同じくディアルコアのEspressifは、どちらもRTOS動作可能ですが、片方がメインアプリケーション、もう片方が通信処理を担当するのが標準的な使い方です。

価格が上がりますがルネサス独自32ビットコアRX65N Cloud Kitは、FreeRTOSとAzure RTOSの選択が可能です。但し、無償版コンパイラは容量制限があり、高価な有償版を使わなければ開発できないため、個人向けとは言えません。

※無償版でも容量分割と書込みエリア指定など無理やり開発するトリッキーな方法があるそうです。

クラウドサービスシェア1位のAWS（Amazon Web Services）接続用FreeRTOSが主流であること、通信関連は、ディアルコア化し分離処理する傾向があることが解ります。

ディアルコア

ディアルコアで通信関連を分離する方式は、接続クラウドや接続規格に応じて通信ライブラリやプロトコルを変えれば、メイン処理側へ影響を及ぼさないメリットがあります。

例えば、STマイクロのCortex-M4/M0+ディアルコアMCU：STM32WBは、通信処理を担うM0+コアにBLEやZigBee、OpenThreadのバイナリコードをSTが無償提供し、これらを入れ替えることでマルチプロトコルの無線通信に対応するMCUです。

メイン処理を担うM4コアは、ユーザインタフェースやセンサ対応の処理に加え、セキュティ機能、上位通信アプリケーション処理を行います。

通信処理は、クラウド接続用とセンサや末端デバイス接続用に大別できます。

STM32WBやCY8CPROTO-063-BLEが採用した末端接続用のBLE通信処理を担うディアルコアのCortex-M0+には、敢えてRTOSを使う必要は無く、むしろベアメタル動作の方が応答性や低消費電力性も良さそうです。

一方、クラウド接続用の通信処理は、暗号化処理などの高度なセキュティ実装や、アプリケーションの移植性・生産性を上げるため、Cortex-M4クラスのコア能力とRTOSが必要です。

デュアルコアPSoC 6のFreeRTOS LED点滅

デュアルコアPSoC 6対応FreeRTOSテンプレートは、現在検討中です。手始めに表中のCY8CPROTO-063-BLEのメイン処理Cortex-M4コアへ、FreeRTOSを使ってLED点滅を行います。

と言っても、少し高価なCY8CKIT-062-BLEを使ったFreeRTOS LED点滅プログラムは、コチラの動画で紹介済みですので、詳細は動画をご覧ください。本稿は、CY8CPROTO-063-BLEと動画の差分を示します。

CY8CPROTO-063-BLE のCortex-M4とM0+のmain_cm4.c、main_cm0p.cとFreeRTOSConfig.hが下図です。

PSoC 6 CY8CPROTO-063-BLE FreeRTOS LED点滅のmain_cm4.cとmain_cm0.c

PSoC 6 CY8CPROTO-063-BLEのFreeRTOSConfig.h

日本語コメント追記部分が、オリジナル動画と異なる箇所です。

RED LEDは、P6[3]ポートへ割付けました。M0+が起動後、main_cm0p.cのL18でM4システムを起動していることが判ります。これらの変更を加えると、動画利用時のワーニングが消えCY8CPROTO-063-BLE でFreeRTOS LED点滅動作を確認できます。

PSoCの優れた点は、コンポーネント単位でプログラミングができることです（コチラの関連投稿：PSoCプログラミング要点章を参照してください）。

PSoC Creator起動時の上図が示すように、Cypressが想定したアプリケーション開発に必要なコンポーネントの集合体が、MCUデバイスと言い換えれば解り易いでしょう。つまり、評価ボードやMCUデバイスが異なっても、使用コンポーネントが同じなら、本稿のように殆ど同じ制御プログラムが使えます。

PSoC 6 FreeRTOSテンプレートも、単に設定はこうです…ではなく、様々な情報のCY8CPROTO-063-BLE利用時ポイントを中心に、開発・資料化したいと考えています。PSoCプログラミングの特徴やノウハウを説明することで、ご購入者様がテンプレートの応用範囲を広げることができるからです。

FreeRTOSアプリケーションテンプレート発売

2021年6月25日2021年12月12日 WithHappy

ARM Cortex-M4コア動作のFreeRTOSアプリケーションテンプレート第一弾、NXP）LPCXpresso54114対応版（税込2000円）を本日より発売します。概要、要点、FreeRTOSアプリケーションテンプレートとは、に関する説明資料は、コチラから無料ダウンロードできますのでご覧ください。

開発背景

IoT MCUのクラウド接続には、AWSならAmazon FreeRTOS、Microsoft AzureならAzure RTOSなどのRTOSが必要です。クラウド側からは、1つのRTOSライブラリを使って様々なMCUハードウェアを接続するための手段、これがRTOSです。

一方、IoT MCU側からは、接続先サービスに応じたRTOSライブラリ利用に加え、従来のベアメタル開発からRTOS上でのアプリケーション開発へ発展する必要もあります。IoT化に伴うこのような変化に対し、開発者個人が手間なく対応するためのツール、これが弊社FreeRTOSアプリケーションテンプレートです。

目的

FreeRTOSアプリケーションテンプレートの目的は、「RTOS基礎固め」と「FreeRTOSプロトタイプ開発のスタートプロジェクトとなること」の2点です。

RTOS開発は、ベアメタル開発とは異なります。

RTOS Kernelが、開発した処理（タスクやThread）と他タスクの優先順位により、処理実行/待機を決めます。開発タスク単体の流用性は高まりますが、タスク間同期や通信に、セマフォやQueueなどのRTOS独特の手段が必要です。

IoTにより全てのモノ（MCU）がクラウドへ接続する時代の基盤は、RTOSです。

ベアメタル開発経験者が、このRTOSの早期基礎固め、Kernelと自身で開発したタスクの並列処理を理解するには、個々にRTOS手段を説明するサンプルソフトよりも、具体的なRTOSアプリケーションの方が実践的で役立ちます。

RTOSアプリケーションがあれば、優先順位を変えた時のタスク動作変化や、その他経験に基づいたRTOS実務開発で知りたい事柄を手間なく試し、新たな知見・見識を得られるからです。これらは、サンプルソフトや、説明文から得ることは困難で、実際のRTOSアプリケーションで開発者自身が試行するのがベストです。

そこで、各FreeRTOS手段を説明した弊社MCU RTOS習得ページを理解した次の段階として、最初の図に示したプロトタイプ開発着手に必須となるADC/LCD/SW/LED/VCOM処理を、NXP）LPCXpresso54114（Cortex-M4/150MHz、Flash/256KB、RAM/192KB）とBaseboard、Arduinoプロトタイプシールドに実装し、動作確認済みRTOSプロジェクトが、FreeRTOSアプリケーションテンプレートです。

FreeRTOS Application Template (NXP Version)

※上記プロジェクトは、クラウド接続は行っておりません。RTOS基礎固めとFreeRTOSプロトタイプ開発に適すことが目的ですので、クラウド接続RTOSライブラリは未実装です。

FreeRTOSを選んだのは、現在MCU RTOSシェア1位だからです（関連投稿はコチラ）。RTOS手段は、各RTOS共通技術であるSemaphoreとQueueの2つを用いております。LPCXpresso54114のFlashやRAM使用量にはまだ十分余裕がありますので、より高度なミューテックスやイベントグループなどの手段を適用するのも容易です。

特徴

本テンプレートには、上記FreeRTOSプロジェクトと同じ動作確認済みのベアメタル開発プロジェクトも添付しております。これは、ベアメタル開発に慣れた方が、FreeRTOSとベアメタルの差分をより明確に理解し、比較や評価をするためです（比較・評価は、ご購入者ご自身で行って頂きます）。

本テンプレート付属説明資料は、主にベアメタル開発者視点から見たFreeRTOSプロジェクトを解説しており、ベアメタルプロジェクトに関する説明は、ソースコードを読めばご理解頂けるとして省略しております。

従って、FreeRTOSアプリケーションテンプレートは、ベアメタル開発経験者を対象といたします。ベアメタル初心者の方は、先ずは各MCUベンダCortex-M0+/M3コア対応の従来マイコンテンプレートをご購入ください。従来テンプレート付属説明資料には、ベアメタル動作の詳しい説明が付いています。

※本テンプレートのベアメタルプロジェクトは、従来テンプレートCortex-M0+/M3コアをCortex-M4コア対応へ発展させたものです。ベアメタルプロトタイプ開発着手時に適すプロジェクトです。

FreeRTOSアプリケーションテンプレートは、ベアメタル開発経験者が、手間なく直にRTOSとベアメタルの差を理解・実感し、かつ、IoT基盤RTOSの効率的な基礎固めができるツールです。

なお、既に従来マイコンテンプレートご購入者様は、50％OFF特典があり、税込1000円にて本FreeRTOSアプリケーションテンプレートをご購入頂けます。弊社での確認ミスを防ぐため、ご購入時に従来テンプレート購入者様である旨、お知らせください。

勿論、従来テンプレートとFreeRTOSアプリケーションテンプレートの同時購入でも、この特典は適用されます。

まとめと今後

ベアメタル開発経験者が、IoT MCUクラウド接続に必要となるRTOSの効率的な基礎固め、FreeRTOSプロトタイプ開発着手プロジェクトとして使えることを目的に、NXP）LPCXpresso54114、Baseboard、Arduinoプロトタイプシールドを使ったFreeRTOSアプリケーションテンプレートを発売しました。

本テンプレートは、Amazon FreeRTOSのHardware Independent FreeRTOS Exampleを原本としています。第1弾はNXP）LPCXpresso54114へ適用しましたが、今後、STマイクロエレクトロニクス）STM32G4やCypress)PSoC 6など他社Cortex-M4コアの対応版も開発予定です。

STM32U5発表と最新IoT MCU動向

2021年3月19日2021年3月26日 WithHappy

STマイクロエレクトロニクス2021年2月25日発表の先端性能と超低消費電力動作両立のSTM32U5を紹介し、STのIoT MCU開発動向をセキュリティ、MCUコア、製造プロセスの観点から分析しました。

先端性能と超低消費電力動作のSTM32U5

公式ブログから抜粋したSTM32U5のベンチマークです。従来の超低消費電力MCU：STM32L0～L4+シリーズと、Cortex-M33コア搭載STM32L5、今回発表のSTM32U5をメモリサイズとパフォーマンスで比較しています。

STM32U5は、従来Cortex-M0+/M3/M4比、Cortex-M33搭載により後述のセキュリティ先端性能と、従来Cortex-M33搭載STM32L5比、230DMIPS/160MHzと大幅向上した超低消費電力動作の両立が判ります。STM32U5の詳細はリンク先を参照ください。

本稿はこの最新STM32U5情報を基に、STのIoT MCU開発動向を、セキュリティ、MCUコア、製造プロセスの3つの観点から分析します。

セキュリティ

昨年10月27日ウェビナー資料：ARM TrustZone対応マイコンによるIoTセキュリティのP17に示されたSTM32マイコンセキュリティ機能一覧です。セキュリティ先端性能のTrustZoneは、Cortex-M33コアに実装されています。

関連投稿：Cortex-M33とCortex-M0+/M4の差分

今回の超低消費電力STM32U5発表前なのでSTM32L5のみ掲載されていますが、STM32U5もL5と同じセキュリティ機能です。STM32WLは、後述するワイヤレス（LoRaWAN対応）機能強化MCUです。

この表から、後述する最新メインストリーム（汎用）STM32G0/G4も、STM32U5/L5と同じセキュリティ機能を実装済みで、STM32U5との差分はTrustZone、PKA、RSSなど一部であることも判ります。

STM32U5のSTM32L5比大幅に動作周波数向上と低消費電力化が進んだ背景は、セキュリティ機能に対するより高い処理能力と40nm製造プロセスにあることが2月25日発表内容から判ります。

STM32ファミリMCUコア

STM32ファミリMCUコアは、ハイパフォーマンス/メインストリーム（汎用）/超低消費電力/ワイヤレスの4つにカテゴライズされます。前章のSTM32WLがワイヤレス、STM32U5/L5は超低消費電力です（STM32U5は加筆）。

STM32WLとSTM32WBの詳細は、コチラの関連投稿をご覧ください。

STM32U5と同様、従来の120nmから70nmへ製造プロセスを微細化して性能向上した最新メインストリームが、STM32G0/G4です。

新しいSTM32G0/G4は、従来汎用STM32F0/F1/F3とソフトウェア互換性があり、設計年が新しいにも係わらずデバイス価格は同程度です。従来メインストリームのより高い処理能力と低電力動作の顧客ニーズが反映された結果が、最新メインストリームSTM32G0/G4と言えるでしょう。

製造プロセス

製造プロセスの微細化は、そのままの設計でも動作周波数向上と低電力消費、デバイス価格低減に大きく寄与します。そこで、微細化時には、急変するIoT顧客ニーズを満たす機能や性能を従来デバイスへ盛込んで新デバイスを再設計します。STM32U5やSTM32G0/G4がその例です。

MCU開発者は、従来デバイスで開発するよりも製造プロセスを微細化した最新デバイスで対応する方が、より簡単に顧客ニーズを満たせる訳です。

関連投稿：開発者向けMCU生産技術の現状

まとめ

セキュリティ、MCUコア、製造プロセスのそれぞれを進化させた最新のIoT MCUデバイスが、次々に発表されます。開発者には、使い慣れた従来デバイスに拘らず、顧客ニーズを反映した最新デバイスでの開発をお勧めします。

また、短時間で最新デバイスを活用し製品化する方法として、最新メインストリーム（汎用）デバイスSTM32G0/G4を使ったプロトタイプ開発もお勧めします。

前章までで示したように最新メインストリームSTM32G0/G4は、他カテゴリデバイスの機能・性能を広くカバーしています。メインストリームプロトタイプ開発資産は、そのまま最新の他カテゴリデバイスへも流用できます。

従って、他カテゴリデバイスの特徴部分（セキュリティ、超低消費電力動作やワイヤレス）のみに注力した差分開発ができ、結果として短期製品化ができる訳です。

ちなみに、プロトタイプ開発に適したSTM32G0テンプレートは、コチラで販売中、FreeRTOS対応のSTM32G4アプリケーションテンプレートは、6E目標に開発中です。

あとがき：文字伝達

ソフトウェア開発者ならソースコード、ハードウェア開発者なら回路図が、最も直接的・正確に技術内容を使える手段です。文字は、記述者の理解を変換して伝える間接的手段です。両者に違い（文字化ノイズ）が生じるのは、やむを得ないと思います。

“報ステのTSMCのニュースに頭の抱えてしまった”、“TSMCは日本で何をしようとしているのか“からも分かるように、マスメディアは文字や画像で情報を伝えます。受けての我々開発者は、これらノイズを含むと思われるマスメディア情報を、自分の頭で分析・処理し、理解する必要があります。

と言うわけで本稿も、筆者が文字化ノイズを付けて分析した例です……、という言い訳でした😅。

無線STM32WBと汎用STM32G4比較

2021年1月15日2021年10月28日 WithHappy

STマイクロエレクトロニクスの近距離無線通信機能付きSTM32WB（Cortex-M4/64MHz）と、汎用メインストリームSTM32G4（Cortex-M4/170MHz）を比較します。

Bluetoothなどの超省電力無線通信は、IoTデバイスに好適です。無線機能付きSTM32WBのIoTアプリケーション開発方法を調査し、汎用STM32G4を使ったSTM32WBのIoTアプリケーション開発の可能性とメリットを検討しました。

ディアルコアSTM32WBとシングルコアSTM32G4

STM32WBとSTM32G4、どちらもARM Cortex-M4コアを持つMCUです。違いは、STM32WBが、無線処理専用Cortex-M0+コア/32MHz内蔵のディアルコアMCUという点です。

Cortex-M4とM0+コア間のアプリケーションは、プロセス間通信コントローラ（IPCC）によりノンブロックイングで割込み利用のメッセージ交換が可能です。IPCCは、コアをSleep/StopモードからRunモードへ復帰させることもできますので、両コアは別々に低消費電力動作ができます。

STM32WBシリーズの紹介スライドP2から抜粋したSTM32WBとSTM32G4の位置づけが下記です。ワイヤレスマイコンのSTM32WLとSTM32WBの違いは、WLはLoRaWANなど、WBはBluetoothなどのサポート無線規格が異なる点ですが、Cortex-M4とM0+のディアルコア構成は同じです。

無線コプロセッサ：Cortex-M0+コア

STM32WBのCortex-M0+コアは、Bluetooth 5、ZigBee、OpenThreadなど2.4GHz帯無線通信処理専用です。ユーザ（開発者）は、利用する無線規格（BLE⇋ZigBeeなどのブリッジも可能）を選択し、STマイクロエレクトロニクス開発の無線専用ファームウェアをCortex-M0+へダウンロードします。但し、このファームウェアに手を加えることはできません。

言い換えれば、Cortex-M0+側の無線処理はSTの動作保証付きで、ファームウェアバージョンアップなどのメインテナンスは必要ですが、ユーザ変更などは不必要、ブラックボックスとして扱える訳です。

つまり、見た目はディアルコアですが、STM32WBのCortex-M0+は無線コプロセサで、外付け無線モジュールと同等です。従って、ユーザが開発するSTM32WBのIoTアプリケーションは、シングルコアのSTM32G4と同じ手法で開発が可能です。

Bluetooth 5（BLE含む）とサンプルプログラム

STM32WBの無線規格は、Bluetooth5やZigBeeなど複数プロトコルをサポートしています。このうち、IoTセンサの少量データ収集アプリケーションに好適なBluetooth5とBLEの詳細は、Bluetooth Low Energyプロトコルの基礎知識に説明があります。BLEを利用するIoTセンサ・アプリケーションを開発する場合には、最低限必要となる知識です。

STM32WBには、開発環境STM32CubeWBとP-NUCLEO-WB55評価ボードで動作する様々なBLEサンプルプログラムがあります。サンプルプログラムの解析やこれらを応用したIoTアプリケーション開発時、BLE基礎知識が役立ちます。

また、P-NUCLEO-WB55評価ボードとスマートフォンをBLE接続し動作するサンプルプログラムもあります。

FSU： Firmware Upgrade Services

ディアルコアSTM32WBのCortex-M4アプリケーション開発時は、Cortex-M0+ファームウェアも同時にFlashへ書込みます。この点が、シングルコアSTM32G4開発と異なる部分です。

このFlash書込みには、STM32CubeProgrammmerのコマンドライトツール（CLI）で提供されるFSU：Firmware Upgrade Servicesを使います（動画説明はコチラを参照してください）。

簡単に言うと、Cortex-M4とCortex-M0+でメモリ共有中のFlashへ、ユーザ開発Cortex-M4アプリケーションを書込む時に、同時に通信Cortex-M0+ファームウェアも更新する仕組みで、手順さえ守れば通常のSTM32CubeIDEを使ったシングルコアSTM32G4のFlash書込み同様簡単です。

Flash書込み後は、STM32G4と同じ方法でアプリケーションデバッグを行います。

無線通信機能付きディアルコアSTM32WBと汎用シングルコアSTM32G4比較結果

P-NUCLEO-WB55とNUCLEO-G474RE — STM32WB評価ボードP-NUCLEO-WB55（左）とSTM32G4評価ボードNUCLEO-G474RE（右）

本稿で示したSTM32WB関連情報は、昨年末に行われたSTマイクロエレクトロニクス日本語ウェビナー資料から抜粋したもので、STM32マイコン体験実習（Bluetooth^®編）でオリジナル動画とスライドが公開中です。また、STM32WBトレーニング資料とCortex-M4トレーニング資料も参考にしました。

前章までで、無線通信機能付きディアルコアSTM32WBと汎用シングルコアSTM32G4を比較し、下記を得ました。

ディアルコアSTM32WBのCortex-M0+側は、通信コプロセサでブラックボックとして扱える。
例えば、IoTセンサデータ収集などのCortex-M4側IoTアプリケーションを、HAL（Hardware Abstraction Layer）APIで開発すれば、通信部分は異なるがデータ収集部分はSTM32WBとSTM32G4で共通開発できる。
STM32WBとSTM32G4で異なる点は、評価ボードへのFlashプログラミングだが、手順は簡単。
STM32WBのFlashプログラミングで用いたSTM32CubeProgrammerは、STM32G4のRoot of Trustで用いたもので、STM32WBでもSTM32G4と同様のRoot if Trustを実現できる。

HAL APIはコチラの関連投稿などを、STM32G4のRoot of Trustはコチラの関連投稿を参照してください。

STM32WBのIoTアプリケーションを汎用STM32G4で開発

最初の図に示したCortex-M4動作最高周波数の64MHzと170MHz、デバイスFlash/RAM容量差に注意すれば、STM32WBのIoTアプリケーションを汎用STM32G4で開発することは、可能でメリットもあると思います。

前提条件として、HAL API開発であること、STM32WBのIoTアプリケーション用Flash/RAM容量が、無線通信コプロセサCortex-M0+が使っても十分残ること、無線通信の代用としてUSARTなどの有線通信を使うこと、などです。FreeRTOS利用が良い場合があるかもしれません。

無線コプロセサCortex-M0+使用容量は、かなり少なく（ウェビナーでは使用量が公表されましたが数値未取得）Cortex-M4 IoTアプリケーション用空き容量は十分あります。また、汎用STM32G4の方が高速動作のため開発制約条件も緩いです。無線では、通信断時のエラー処理検討が必要ですが、有線ですのでエラー処理なしで本来の通信処理は開発可能です。

つまり、STM32WBの無線通信エラー処理以外は、ほぼ全て汎用STM32G4で代用開発が可能です。

Cortex-M4クラスMCUは、どれも高速で大容量Flash/RAMを実装し高いポテンシャルを持っています。つまり、IoTプロトタイプ開発とその評価には、最適なデバイスです。

汎用STM32G4で代用開発済みアプリケーションをSTM32WB/STM32WLへ移植し、IoTプロトタイプ開発をスピードアップするメリットは、差分開発、つまりIoT特有機能の差分を開発ができることです。

ある程度MCU開発経験を持つ開発者が、従来MCU開発では少なかった無線通信や高度なIoTセキュリティなどのIoTアプリケーション特有の重点ポイントに注力でき、即座にIoTプロトタイプ開発（代用開発含む）とそれを評価するツールとなること、これが弊社Cortex-M4テンプレートの目標です。

評価の結果、仮にMCUやIoTセンサ、無線機能の再選択が必要となっても、開発部分の多くが次に即座に流用できるソフトウェア資産となるには、汎用STM32G4によるIoTプロトタイプ開発が有効だと思います。

具体的には、従来テンプレートとは「対象者レベルと目的を変える」ことを検討中です。

従来Cortex-M0/M0+/M3テンプレートは、対象者が初心者/中級レベル開発者で、MCU基本動作（Simpleテンプレート）とADC/LCD動作（IoT汎用Baseboardテンプレート）を提供し、基本的なMCU理解と開発が目的のテンプレート
Cortex-M4テンプレートは、対象者が中級レベル以上の開発者で、MCU基本動作などは省き、IoTプロトタイプ開発高速化が目的のテンプレート

本稿説明がすんなりとご理解頂ければ、中級レベル以上の開発者、Cortex-M4テンプレート対象者だと思います。

News

2021年1月12日、STM32CubeとMicrosoftのAzure RTOSが統合、STM32マイコン開発環境で協力というニュースが発表されました。STのCortex-M4テンプレートは、FreeRTOSとAzure RTOSの両方が必要かもしれません。

STブログに、上記の詳細情報があります。

2020マイコンテンプレート案件総括

2020年12月18日2021年1月15日 WithHappy

COVID-19パンデミックの2020年も残すところ2週間になりました。2020年の金曜ブログ投稿は本日が最後、次回は2021年1月8日（金）とし休暇に入ります。

※既存マイコンテンプレートは、年中無休、24時間販売中です、いつでもご購入お持ちしております。

2020マイコンテンプレート案件総括

🔴：Cortex-M4コア利用のマイコンテンプレート開発（2020年内）
🟡：FRDM-KL25ZとIoT汎用Baseboard利用のKinetis Lテンプレート発売（12月）
🟢：IoT MCU向け汎用Baseboard開発（10月）
🟢：STM32FxテンプレートV2発売（5月）
🟢：STM32G0xテンプレートV2発売（5月）

1のCortex-M4テンプレート開発は、STM32G4のRoot of Trustと、NXP LPCXpresso54114のRTOSサンプル解説で、Cortex-M4テンプレート化には程遠い状況です（赤ステータス）。

2のKinetis Lテンプレート（FRDM-KL25Z、Cortex-M0+/48MHz、Flash:128KB、RAM:16KB）は、添付説明資料作成が未着手です（黄ステータス）。

3のArduinoプロトタイプシールド追加、IoT MCU汎用Baseboardは完成しました（緑ステータス）。

4と5のSTM32FxテンプレートとSTM32G0xテンプレート発売までは、ほぼ順調に進みました（緑ステータス）。

対策としてブログ休暇中に、2のKinetis Lテンプレート完成と、これに伴うHappyTechサイト変更を目標にします。
１のCortex-M4テンプレート開発は、2021年内へ持越します。

ブログ記事高度検索機能（1月8日までの期間限定）

休暇中、ブログ更新はありません。そこで、読者の気になった過去の記事検索が、より高度にできる下記Googleカスタム検索機能を、1月8日までの期間限定で追加します。

上記検索は、WordPressのオリジナル検索（右上のSearch…窓）よりも、記事キーワード検索が高度にできます。少しでもキーワードが閃きましたら、入力してご活用ください。

あとがき

激変の2020年、テンプレート関連以外にも予定どおりに進まなかった案件や、新に発生した問題・課題も多数あります。例年より少し長めの休暇中、これらにも対処したいと考えております。今年のような環境変化に対し、柔軟に対応できる心身へ変えたいです（ヨガが良いかも？ 3日坊主確実ですが…😅）。

本年も、弊社ブログ、HappyTechサイトをご覧いただき、ありがとうございました。
今後も、引き続きよろしくお願いいたします。よいお年をお迎えください。

Cortex-M33とCortex-M0+/M4の差分

2020年12月10日2021年1月29日 WithHappy

STマイクロエレクトロニクスが、STM32マイコン体験実習（セキュリティ編①～⑤）という動画でCortex-M33 TrustZone解説とSTM32L5（Cortex-M33/110MHz、Flash/256/512KB、RAM/256KB）のセキュリティ実習を行っています。

このセキュリティ編①：31min17secから、IoT MCU向けセキュリティ強化Cortex-M33コアのARM TrustZoneマイコンと、通常Cortex-M0+/M4コアマイコンとの差分を抽出しました。TrustZoneマイコン基礎知識の習得が目的です。

Cortex-M33とCortex-M0+/M4差分

セキュリティ編動画①～⑤概要

①P3（動画①、スライドP3を示します）に、動画①～⑤の概要が示されています。動画①でCortex-M33コアの解説、②でSTM32L5開発環境の準備、後半③～⑤でSTM32L5評価ボード：NUCLEO-L552ZE-Q（¥2,303 Mouser）を使ったセキュリティ演習という構成です。

本稿は、動画①から、ARM TrustZone Cortex-M33コアと通常Cortex-M0+/M4コアとの差分を一覧表にしました。

※ARM公式差分情報を知りたい方は、①P48の参考文献が参考になります。

Cortex-M33とCortex-M0+/M4の差分

オンデマンド動画ですので、好きな個所で止める、再生読度を変えるなどが可能です。動画①は、筆者が経験したTrustZone解説の中で最も分かり易い動画です。

特にP36/P37/P39は、4段階に増えたステート処理内容が具体的に判りTrustZoneマイコン特徴理解に役立ちます。
また、P19は、様々なセキュリティレベルと対応STM32MCUのセキュリティ機能差が一目で判る重要な資料です。

頁	要旨（ARM TrustZone Cortex-M33と通常Cortex-M0+/M4差分）
7	ソフトウェア攻撃防御策がTrustZone。物理攻撃対策はセキュアマイコン（≠汎用MCU）が有効。
12	Secure呼出し＝予め決めた手順で内蔵周辺回路（I2C/SPI/RAMなど）へアクセスする技術 Security Isolation＝Secure呼出しを使い通常アクセスと隔離・分離する技術 ARM TrustZone＝Security Isolationを対象MCUで柔軟に構成する技術
16	タンパ＝物理攻撃を検出→検出後バックアップレジスタやSRAM自動消去 JTAGピン無効化→設定後はGPIOなどで運用 WRP（WRite Protection）：数KB単位設定可能 RDP（ReaD Protection）：JTAG読出し禁止→読出検出でプログラム実行停止→PORで解除 Secure Memory＝起動時のみ読出し可能な領域
17	MPU（Memory Protection Unit）：最大16個メモリ領域の読書き、命令実行許可/禁止設定
18	セキュリティは単独では効果が薄く、複数重ね攻撃への敷居を上げ強化（暗号鍵保存例掲載）
19	STM32マイコン内蔵セキュリティ機能差一覧。TrustZone対応はSTM32L5のみ（2020/12時点） STM32G0/G4(Cortex-M0+/M4)でもSRAM RDP機能などあり
22	TrustZoneは、アドレス空間とバス通信の両方をハードウェア監視しアクセス制御
23	アドレス空間監視＝コア内蔵SAU IDAU、バス通信監視＝TZ(TrustZone) ControllerとAHBバス
24	STM32L5は、内部FlashアクセスにST独自Flashレジスタとオプションバイトで保護
26	TrustZone-aware周辺回路＝DMA1&2/GPIO…などAHB接続回路は個別セキュリティ設定要上記以外がSecurable周辺回路＝UART/SPI…などでAHB/APBブリッジがアクセス監視
29	従来MCUベアメタル開発は、mainループも割込みハンドラも常に特権モード動作の1段階
30	従来MCUのRTOS開発は、割込みハンドラ/RTOSが特権モード、ユーザタスクは非特権の2段階
32	Secureステート追加TrustZoneは、4段階化→各層の処理配置がTrustZoneソフト設計第一歩
35	Secureソフトと従来ソフトのプロジェクト差一覧（セキュリティ関連設定はSecureソフトのみ可能でmain関数はあるがmainループなしなど）
36	TrustZoneマイコンベアメタル開発の4段階ステート処理配置例（TrustZoneソフト設計例1）
37	TrustZoneマイコンRTOS開発の4段階ステート処理配置例（TrustZoneソフト設計例2）
38	TrustZoneソフト開発時、Secureソフトと通常ソフトの2プロジェクト作成必要
39	TrustZoneソフトの基本実行フロー（Secureソフトから通常ソフトへの処理内容一覧）
40 41 42	Secureステートと通常ステートのアドレス空間の見え方差まとめ
44	動画①全体まとめ
45	STM32L5開発時のキーポイント一覧（全18項目）
46	STM32L5開発時のキーポイント演習項目一覧（18項目中9項目を動画③～⑤で演習）
48	おすすめARMv8-M（Cortex-M33コア）TrustZone参考文献一覧

TrustZoneマイコン開発は工数2倍、スキルも必要

動画①は、他ベンダのARM Cortex-M33 TrustZoneマイコン開発でも基礎知識が得られます（※P24のST独自Flashレジスタとオプションバイト保護は除く）。IoT MCU向けセキュリティ強化Cortex-M33コアで導入されたTrustZoneを活用するには、①の理解は最低限必要です。

従来Cortex-M0+/M4に比べ、Cortex-M33シングルコア開発でもSecureと通常（Normal）ソフトウェアの2プロジェクト必要、メモリ空間と周辺回路のセキュリティ設定必要（メモリ分割損も生じると予想）、JTAGピン無効化など、従来のアプリケーション開発とそのデバッグに加え、ソフトウェア攻撃対策TrustZone導入による工数やその動作確認/解除などの手間が余分に必要になります。

このTrustZone導入オーバーヘッドは、少なくないです（セキュリティ編②～⑤でオーバーヘッド工数が判ります。補足章に動画②～⑤リンク添付）。Cortex-M33コア最高速度が110MHzと他コア比高速で、Flash/RAMも大容量なのは、このオーバーヘッドのハードウェア対策だと思います。

TrustZoneマイコンのソフトウェア開発工数は、同じアプリケーションの通常マイコン開発の2倍程度は必要になると思います。また、TrustZone起因のトラブルに対する分析スキルも必須です。

ソフトウェア攻撃に対する防御壁の高さは、言い換えると、ソフトウェア開発のし難さと等価です。セキュリティレベルが上がるにつれ、開発コストも上がります。

全てのIoT MCUがTrustZone対応MCUである必要は無いと思います。コスト重視の場合は、従来Cortex-M0+/M4コアでセキュリティ強化対応（例えば、関連投稿：STM32G0/G4のRoot of Trust(1)～(3)など）でも使える可能性があります（関連投稿：IoT MCUコア次世代像のIoT MCUコアの3層構造最下層のFront End IoT MCUに相当）。

セキュリティは、強固な方が良いのは当然ですが、それ相応の追加コストも生じます。セキュリティ対コストの観点からIoT MCUの選択が必要となるでしょう。

＊　＊　＊

セキュリティ対策は、いわば自動車保険のようなものです。保険代金の負担は、開発者かエンドユーザか、エンドユーザがTrustZone導入オーバーヘッドを理解することは難しいと思いますので悩ましい問題です😅。

Cortex-M33 TrustZoneマイコンは、ソフトウェア開発者が記述した処理を攻撃とマイコンが誤認識（正常認識）した場合は、無視、あるいは最悪、マイコンを使用不能にします。見つけにくい無視された処理が、開発者起因か、あるいはTrustZone起因かを分析できるスキル、これが、通常マイコン開発との最大の差分です。

STM32マイコン体験実習は、TrustZone起因スキルを習得できるよく考えられた教材です。

補足

STM32マイコン体験実習（セキュリティ編②）
STM32マイコン体験実習（セキュリティ編③）
STM32マイコン体験実習（セキュリティ編④）
STM32マイコン体験実習（セキュリティ編⑤）

関連投稿：STM HTML版マンスリー・アップデートの見かた4章の全体像リンク集なども役立ちます。

Cortex-M33コア以外でTrustZone技術を用いたマイコンは、Cortex-M35P、Cortex-M23があります。

IoT MCUコア次世代像

2020年11月27日2021年12月12日 WithHappy

PCのCPUは、IntelとAMDの2社が独占状態でした。しかし、AppleがARMベースの新CPU：M1を発表し、そのコストパフォーマンスは、Intel/AMDの3倍（！）とも言われます（記事：「ソフト技術者もうなるApple「M1」の実力、新アプリに道」や、「Apple M1の実力を新世代のIntel/AMD CPUと比較」など）。

本稿は、これらPC CPUコアの現状から、次世代IoT MCUコアの3層構造と筆者希望的観測を示します。

CPUコア：Apple/Intel/AMD

筆者が学生だった頃は、マシン語のPCソフトウェアもありました。CPUコア性能が低いため、ユーザ要求を満たすアプリケーション開発には、ソフトウェア流用性や開発性を無視したマシン語開発もやむを得ない状況でした。

現在のCPUコア性能は、重たいGUIやネットワーク処理を複数こなしても、ユーザ要求を満たし、かつ流用性も高いC/C++などの高級言語でのアプリケーション開発が普通です。Appleは、この状況でIntel/AMDコストパフォーマンス比3倍のM1 CPUを開発しました。

このM1 CPUを使えば、従来CPUのボトルネックが解消できるために、より優れたGUIや新しいアプリケーションの開発が期待できます。

このM1実現の鍵は、5nmルールの製造技術と新しいCPU設計にあるようです。

MCUコア：ARM/Non ARM

MCUはARMコアとNon ARMコアがありますが、Non ARMコアのコストパフォーマンス比は、M1程ではありません。従って、主流はARM Cortex-M系シングルコア採用MCUで、事実上ARMコア独占状態です。開発言語はC言語でベアメタル開発、製造プロセスも数10nmと、いわば、数10年前のIntel独占CPUコアに近い状況です。

RISC-Vという新しいMCUコアも出てきましたが、まだ少数派でその性能も未知数です。Intel/AMD CPUと比較記事の最後に記載された「競争こそユーザの利益」には、MCU世界はなっていません。

ARMはコア設計図のみ提供し、デバイス実装はMCUベンダが担当します。従って、現状のMCU世界が続く場合には、MCU高速化は製造技術進化とマルチコア化が鍵です。

ARMは、エッジAIに向けたNPUを発表しました。独自MCUコアと付随する開発環境を提供でき、かつコストパフォーマンスがARMコアの数倍を実現できるMCUベンダが無い現状では、ARMの頑張りがIoT MCUを牽引すると思います。

※NVIDIAによるARM買収が、今後のARM動向に及ぼす影響は気になる状況ではあります。

IoT MCUコア

MCUコアとCPUコアの一番の差は、ユーザ要求コストです。これは、同じコアのMCU製品に、内蔵周辺回路やFlash/RAM容量の異なる多くのデバイスをベンダが提供中であることからも解ります。ユーザは、MCUに対して無駄なコストは払いたくないのです。

つまり、MCUデバイスはアプリケーション専用製品、CPUデバイスは超汎用製品、ここが分岐点です。

IoT MCUには、エッジAI、セキュリティ、無線通信（5GやWi-Fi）などのIoT機能追加が必要です。これら機能を並列動作させる手段として、RTOSも期待されています。この状況対応に、MCUコアも高性能化やマルチコア化に進化しつつあります。

セキュリティや無線通信は、予め決まった仕様があり、これら対応の専用ライブラリがベンダより提供されます。但し、セキュリティは、コストに見合った様々なセキュリティレベルがあるのも特徴です。ソフトウェア技術者は、専用ライブラリのMCU実装には神経を使いますが、ライブラリ本体の変更などは求められません。この仕様が決まった部分を「IoT基本機能」と本稿では呼びます。

MCUソフトウェア開発者が注力すべきは、ユーザ要求に応じて開発するIoTアプリケーション部分です。この部分を、「IoT付加機能」と呼び、「IoT基本機能」と分けて考えます。

ユーザのアプリケーション専用MCU製品意識は、IoT MCUでも変わりません。例えば、IoT基本機能の無線機能は不要や、ユーザがコストに応じて取捨選択できるセキュリティレベルなどのIoT MCU製品構成になると思います。一方、IoT付加機能だけを実装するなら、現状のMCUでも実現可能です。

以上のことから、IoT MCUは3層構造になると思います。

層	機能	追記
Back End IoT MCU	IoT基本機能＋付加機能＋分析結果表示	収集データ分析結果ビジュアル表示
IoT MCU	IoT基本機能＋付加機能	高性能、マルチコア、RTOS利用
Front End IoT MCU	センサデータ収集などのIoT付加機能最小限セキュリティ対策	収集データは上層へ有線送信コスト最重視

最下層は、ユーザ要求アプリケーションを実装し、主にセンサからのデータを収集するFront End IoT MCUです。ここは、現状のARM/Non ARMコアMCUでも実現できIoT付加機能を実装する層です。デバイスコスト最重視なので、最小限のセキュリティ対策と収集データを有線、または無線モジュールなど経由で上位IoT MCUへ送信します。IoT MCUサブセット版になる可能性もあります。

中間層は、高度なセキュリティと市場に応じた無線通信、エッジAI機能などのIoT基本機能がフル実装できる高性能MCUコアやマルチコア、RTOS利用へ進化した層です。IoT付加機能も同時実装可能で、下層の複数Front End IoT MCUが収集したセンサデータを、まとめて上位Back End IoT MCUまたは、インターネット空間へ直接送信できます。製造技術進化とマルチコア化、ARM新コア（Cortex-M23/33/55など）が寄与し、IoT MCUの中心デバイスです。

最上層は、第2層のIoT MCU機能に加え、インターネット空間で収集データを分析・活用した結果をユーザへビジュアル表示する機能を追加した超高性能MCUコア活用層です。自動車のADAS（Advanced Driver-Assistance Systems：先進運転支援システム）のおかげでユーザへのビジュアル表示要求はより高度になります。このユーザ要求を満たす次世代の超高性能IoT MCU（またはMPU）が実現します。

最下層のFront End IoT MCUは、現状のCortex-M0+/M4コアで弊社テンプレート適用のMCUが生き残ってほしい、というのが筆者の希望的観測です。
それにしてもAppleのコスパ3倍M1、凄いです。iPhoneもそうですが、抜きん出た技術と経営能力、Jobs精神、健在ですね。

Cortex-M0からCortex-M0+変化

2020年7月3日2020年7月10日 WithHappy

前稿で示したNXP MCUラインナップ図には、ARM Cortex-M0/M0+両方のコアが掲載中でした。しかし、最新版MCUXpresso IDEのコア選択ダイアログには、Cortex-M0選択肢がありません。

そこで、Cortex-M0+とCortex-M0の違いを調べた結果、新規MCU開発にNXPのCortex-M0コアを使う必然性は低いという結論に達しました。本稿は、その根拠を示します。

ARM Cortex-M0+とCortex-M0の差

弊社関連投稿：Cortex-M0/M0+/M3比較とコア選択や、ARMコア利用メリットの評価、ARM MCU変化の背景をまとめ、ARMコアの発表年順に示したのが下表です。※M4の発表年は間違っているかもしれませんが、市場に出回ったCortex-Mxコアの順番は下表で正しいハズです😌。

ARM Cortex-Mx性能、発表年
Cortex-Mコア	性能 (MIPS @ MHz)	ARM発表年	MCUモデル
Cortex-M3	1.25	2004	旧メインストリーム
Cortex-M0	0.9	2009	ローコスト
Cortex-M0+	0.95	2011	ローパワー
Cortex-M4	1.25	2012頃	デジタル信号処理新メインストリーム

要するに、Cortex-M0+やCortex-M4は、Cortex-M0やCortex-M3をベースに市場ニーズに即した変更を加えた新しいARMコアだと言うことです。本稿では、特にCortex-M0+とM0の違いに注目します。

Cortex-M0+には、表の差以外にも高速IOアクセス、高速パイプライン、低消費動作モードなどCortex-M0には無い数々の特徴がありますが、Cortex-M0よりも高性能（0.9→0.95MIPS@MHz）で、シリコンチップ高速化にも好都合です。

つまり、新規開発にCortex-M0+の代わりに敢えてCortex-M0コアを用いる理由は、見当たらない訳です。

NXPの新しい統合開発環境MCUXpresso IDEのSDKのコア選択肢に、Cortex-M0が無いのは、上記が理由だと思います。※ローコストに関しては、コア単体の相対評価はできても、使用数量でかなり変動するためMCUコスト絶対評価を難しくしています。

NXP MCUXpresso SDK対応評価ボード数

最新MCUXpresso IDE v11.1.1のSDKで対応中の評価ボード数を一覧にしました。例えば、Cortex-M33コアなら下図のように7個です。

評価ボードは、プロトタイプ開発には必須で、その評価ボードで動作するSDK（Software Development Kit）があればソフトウェア開発効率は向上します。Cortex-Mxコア間のソフトウェア移植性は高く、同じコアのソフトウェアであれば、異なる評価ボードへの移植もさらに容易です。

つまり、評価ボード数が多いCortex-M0+やCortex-M4が、現在最もCortex-Mxコアソフトウェア開発効率が高いことを示しています。また、Cortex-M3コア選択肢がない理由も、Cortex-M0コアがない理由と同じと推測します。

本当の並列処理が要求されるマルチコア開発なら、Cortex-M0+とM4のペア、または、IoTセキュリティを強化したCortex-M33コアx2であることも判ります。※Cortex-M33は、2016年ARM発表のセキュリティ強化コアです。

新規ARM Cortex-Mxソフトウェア開発は、Cortex-M0+コアまたはCortex-M4コア利用に収束してきたと思います。
※Cortex-M33コアは、従来コアに無いIoT向けセキュアゾーンなどが新規機能追加されていますので除外しています。

弊社テンプレート開発方針

前稿のNXP MCUラインナップからCortex-M0とCortex-M3を除き、現状SDK提供中のARM Cortex-Mxコアラインナップをまとめると下図になります。※Cortex-M33は未掲載です。

Software Development Kit開発から見たNXP MCUラインナップ

弊社もCortex-M0+、Cortex-M4、Cortex-M33コア向けのテンプレート開発を進める方針です。

STM32G0/G4のRoot of Trust(2)

2020年3月27日2020年5月31日 WithHappy

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

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

セキュア・ブート

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

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

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

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

セキュア・ブート解釈

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

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

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

パソコンで例えると、従来ブートが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プロジェクトを新規作成します。

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

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

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

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

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

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

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

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

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

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

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

デュアルファームウェアイメージは、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付録の章に、これら詳細が記載されています。

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

FreeRTOSサンプルコード(1)

2020年1月24日2020年1月31日 WithHappy

NXPのCortex-M4/M0+ディアルコアLPCXpresso54114のFreeRTOSサンプルコードを数回に分けて調査します。Cortex-M4クラスのMCUは、処理は高速で大容量Flash、RAMを持つので、ベアメタル利用だけでなくRTOS利用ソフトウェア開発にも適します。

ベアメタルCortex-M0/M0+/M3に適用済み弊社テンプレートを、そのままCortex-M4 MCUに使うのは、テンプレートがMCU非依存なので簡単です。ですが、先ずFreeRTOSソフトウェアをよく知り、新開発ベアメタルCortex-M4テンプレートへ応用できる機能があるか判断するのが調査の目的です。

RTOS習得2017

2017年3月にLPCXpresso824-MAX（Cortex-M0+ 30MHz、32KB Flash、8KB RAM）を使ってFreeRTOSのポイントを調査し、結果をマイコンRTOS習得ページにまとめました。

第1部から第3部で、最低限のFreeRTOSと使用APIを解説し、第4部で、最も優れた解説書と筆者が考えるソースコードと評価ボードを使ってFreeRTOS動作解析と習得を行うという内容です。

ただ、自作FreeRTOSサンプルコードの出来が悪く、第4部の動作解析は不十分でした。

そこで、RTOS利用がより現実的なLPCXpresso54114（Cortex-M4/M0+ 100MHz、256KB Flash、192KB RAM）評価ボードとSDK付属FreeRTOSサンプルコードを用いて、不十分だった第4部FreeRTOS動作解析に再挑戦します。平たく言えば、NXP公式FreeRTOSサンプルコードを、不出来な自作コードの代わりに利用します😅。

第1回目は、FreeRTOSサンプルコードの出所、FreeRTOS動作を調べる4ツールを説明します。

LPCXpresso54114 SDK付属FreeRTOSサンプルコード

NXPマイコンの公式サンプルコード取得方法は、3つあります。最も新しいのがSDK：Software Development Kitから、2つ目がLPCOpenライブラリから、3つ目がPE：Processor Expertからの取得です。

NXP社が古くから用いてきたサンプルコード提供方法が、LPCOpenライブラリです。
NXPに買収された旧Freescale社のKinetis MCUなどは、PEと呼ばれるGUIベースAPI生成ツールでサンプルコードを提供していました。同じMCUでも提供方法によりAPIは異なり、サンプルコード互換性はありません。
※ベンダ毎に異なるAPI提供方法やその違い、サンプルコードとの関係は、別投稿で説明する予定です。

Freescale買収後のNXPは、SDKで全MCU（＝新旧NXP＋買収FreescaleのMCU）のAPIとサンプルコードを提供する方法に統一したようです。その根拠は、最新MCUXpresso IDEユーザインタフェースが、SDKの利用前提でできているからです。

現在も提供中のLPCOpenライブラリ内にあるLPCXpresso54114 FreeRTOSサンプルコードは2個、一方、SDK内のFreeRTOSサンプルコードは11個あります。PE提供はありません。

調査対象としては、FreeRTOSサンプルコード数が最多のSDKが適しています。

LPCXpresso54114 FreeRTOS examples in SDK

FreeRTOS実動作解析ツール

MCUXpresso IDE v11.1.0のHelp>Help Contentsに、MCUXpresso IDE FreeRTOS Debug Guideがあります（PDF文書がMCUXpresso IDEインストールフォルダ内にも有り）。この中に、FreeRTOSサンプルコードデバッグのみに使えるタスク対応デバッガ4ツール（Task List/Queue List/Timer List/Heap Usage）があります。

MCUXpresso IDE Help ContentsのFreeRTOS Debug GuideのShowing FreeRTOS TAD Views

Task List：タスク毎のプライオリティ、スタック使用量、動作時間表示
Queue List：アクティブキュー、セマフォ、ミューテックス利用時のリソース表示
Timer List：RTOSタイマー表示
Heap Usage：ヒープ使用量、メモリブロック割当て表示

これらFreeRTOS専用ツールは、FreeRTOSサンプルコードの評価ボード動作後、デバッガ停止中に表示されます。シミュレーションではなく、評価ボードでの「実動作結果」が判ります。開発ソフトウェアだけでなくRTOS使用量が判るので、デバイスにどれ程リソース余裕があるかが判断できます。

RTOSソフトウェアは、ユーザが開発するタスクの単体、結合デバッグに加え、RTOS動作の確認事項が増えます。FreeRTOS実動作解析4ツールは、これらの確認ができます。評価ボードを使ったプロトタイプ開発の重要度は、ベアメタル開発比より大きくなると言えるでしょう。

次回以降、LPCXpresso54114のSDK付属FreeRTOSサンプルコードを、MCUXpresso IDEのFreeRTOS Debug Guideに沿って調査します。