STM32G0/G4のRoot of Trust(1)

2020年3月19日2020年3月27日 WithHappy

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は全ての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 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だけでも次回上手く説明できるか自信がありません。結果は、次回のブログ更新で判ります。

STM32CubeIDE更新、文字化け解決

2020年3月6日2020年7月18日 WithHappy

STマイクロエレクトロニクスの統合開発環境：STM32CubeIDEがv1.3.0に更新されました（2月28日、更新自動通知メールにて把握）。デフォルト設定のWindows版STM32CubeIDEは、エディタで追記した日本語コメントに文字化けが発生します。これは、昨年投稿したSTM32CubeIDE v1.1.0やv1.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か所変更します。

フォント設定を、デフォルトConsolasからメイリオなどの日本語文字セットへ変更（ワークスペース毎）
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起動時、またはCheck for Updatesにより、IDEを含めた各プラグイン更新を確認し、常に最新開発環境となります（悪名高いWindows Updateに似ているような…😅）。

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

最新ファームウェアを使う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サイトに加筆）

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

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

STM32CubeIDE-DEB

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

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

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として販売する予定です。進行状況などは、本ブログでお知らせします。

STM32G071RBとAlexaを繋ぐ

2020年1月17日2020年3月8日 WithHappy

1月9日STマイクロエレクトロニクス（以下STM）公式ブログに、STM32G0とAlexa（アレクサ）を接続する開発キット：Alexa Connect Kit（ACK）モジュールが紹介されました。アレクサに話しかけ、STM32G0評価ボードのNucleo-G071RB 経由でスマートホーム制御が簡単に実現できます。

システム構成

システム構成の公式ブログ掲載が無いので、自作したのが上図右側です（左側出典：STMサイト、Cortex-M7 MCUでアレクサ接続）。

USI MT7697HがACKモジュールで、Nucleo-G071RBとはArduinoコネクタで接続します。スマートスピーカに話しかけると、クラウド内で音声解析→制御コマンド生成を行い、このコマンドがACKへ無線送信され、STM32G0評価ボードNucleo-G071RBへ届き、STM32G071RBがスマートホーム機器などを制御します。

費用とSTM32G0用ACKドライバ、ファームウェア

費用：Nucleo-G071RBが約$10、ACKがUS Amazonで$197、（日本アマゾンで￥38,202）。

STM32G0用ACKドライバ、ファームウェア：公式ブログリンク先は、今日現在、提供されていません。

2018年6月頃は、STM32F7やSTM32H7などの高性能Cortex-M7 MCUでアレクサ接続がSTM公式ブログで投稿されましたが、今回Cortex-M0+のSTM32G0とACKでも簡単に接続可能になりました。

STM32G0特徴

2018年12月新発売のSTM32G0シリーズは、初の90nmプロセス製造MCUで低消費電力と高速動作、従来のSTM32F0 (Cortex-M0)～F1 (Cortex-M3)性能をカバーする新しい汎用MCUです。セキュリティハードウェア内蔵、低価格、64ピンパッケージでも１ペアVDD/VSS給電がSTM32G0の特徴です。
関連投稿：STM新汎用MCU STM32G0、守備範囲が広いSTM32G0

STM32マイコンマンスリー・アップデート2020年1月のP4に、「STM32G0 シリーズのラインナップ拡充 STM32G041/ G031/ G030 新登場」記事もあります。筆者も、STM32G0シリーズは、STMの汎用MCUとしてお勧めデバイスです。

LL APIかHAL API、混在？

残念ながら今は未提供ですが、筆者は、ACKドライバとファームウェアのAPIに興味があります。

理由は、STM32G0シリーズの高性能を引き出すには、HAL：Hardware Abstraction Layer APIよりもエキスパート向けLL：Low Layer API利用ソフトウェア開発が適すからです。

HALとLL比較（出典：STM32 Embedded Software Overvire） — HALとLL比較（※説明のため着色しています。出典：STM32 Embedded Software Overvire）

生産性や移植性の高いHAL APIとLL APIの混在利用は、注意が必要です（関連投稿：STM32CubeMXのLow-Layer API利用法 (2)の4章）。

ACKドライバ、ファームウェアが、LL APIかHAL APIのどちらを使っているか、または混在利用かを確認し、ノウハウを取得したかったのですが…😥。

LL API利用STM32G0xテンプレートとHAL API利用STM32Fxテンプレート

弊社は、LL API利用STM32G0x専用テンプレートと、HAL API利用STM32Fx汎用テンプレートの2種類を、それぞれ販売中です（テンプレートは同一、テンプレートを使うAPIのみが異なる）。

もちろん、STM32G0でもHAL APIを利用することは可能です（STM32G0x専用テンプレートにもHAL API使用例添付）。LL API利用ソフトウェアは、性能を引き出す代償に対象MCU専用になります。

HAL APIとLL APIの混在は避けた方が無難で、STM32G0はLL API専用でテンプレート化しました。添付資料も、LL APIを中心に解説しています。STM32Fxテンプレート添付資料は、HAL API中心の解説です。

両テンプレートをご購入頂ければ、LL/HAL双方のAPI差が具体的に理解できます。開発するアプリケーション要求性能や発展性に応じて、LL APIかHAL APIかの選択判断も可能になります。
※両テンプレート同時購入時は、2個目テンプレート50％OFF適用で、1500円（税込）です😀。

FYI：日本語コメント文字化け継続

STMマイコン開発環境にソースコード日本語コメントの文字化けが発生中であることを、昨年11月に投稿しました。この文字化け発生のSTM32CubeIDE v1.1.0/CubeMX v5.4.0開発環境が、STM32CubeIDE v1.2.0とSTM32CubeMX v5.5.0に更新されました。

更新後のSTM32CubeIDE v1.2.0/CubeMX v5.5.0でも、旧版同様に文字化けします。
一方、SW4STM32では、STM32CubeMX v5.5.0更新後も日本語コメント文字が正常表示されます。

他社の最新版EclipseベースIDE、NXPのMCUXpresso IDE v11.1.0や、CypressのPSoC Creator 4.2では、ソースコードText Font変更をしなくても文字化けはありませんので、STM特有問題だと思います。

ワールドワイドでの日本相対位置低下、今年から始まる小学校英語教育…、日本ものつくりは、英語必須になるかもしれません。

SW4STM32アプリケーションのSTM32CubeIDE移設

2019年11月15日2019年11月23日 WithHappy

SW4STM32で開発した2017年9月発売STM32Fxテンプレートと2019年6月発売STM32G0xテンプレートを、STM32MCU最新統合開発環境STM32CubeIDE v1.1.0へ移設しました。

移設は成功し、STマイクロエレクトロニクス最新統合開発環境：STM32CubeIDE v1.1.0（以下、CubeIDE）、STM32CubeMX v5.4.0（以下、CubeMX）、最新ファームウェアと弊社テンプレートを使って、効率的で最新のSTM32MCUプロトタイプ開発、アプリケーション開発ができます。

本稿は、STM32CubeIDE v1.1.0更新と文字化け対策投稿（その1）、（その2）のその3に相当します。説明が重複する箇所は、リンク先を参照してください。

移設成功結果

STM32Fxテンプレートは「ひと手間」、STM32G0xテンプレートは「そのまま」で最新統合開発環境へ移設でき、評価ボードにてテンプレート動作を確認しました。G0AdcTemplateのCubeIDE移設後と評価ボード動作例です。

既にSTM32Fx/G0xテンプレートご購入者様は、本稿の方法で最新STマイクロエレクトロニクス開発環境へ乗換えることができます。

※現状のCubeMX v5.4.0でコード生成後、CubeIDE v1.1.0の日本語コメントは文字化けしますので注意してください（詳細は、投稿その２参照）。

ファームウェア更新でコンパイルエラー発生：3章

先ず、ファームウェア起因のコンパイルエラーが発生するまでを示します。

１．SW4STM32で開発したF1BaseboardTemplateプロジェクトをCubeIDEへインポートします（インポート方法は、投稿その1-3章参照）。インポートソースコードの日本語コメントに文字化けが発生しますので、その1で示したShift-JISからUTF-8へのエンコード変換で解決します。

２．インポート済みのCubeMXプロジェクトファイルを、CubeIDEプラグイン版CubeMXで開き、Project Managerタブをクリックし、Toolchain/IDEがSTM32CubeIDEであることを確認します。インポートIDE変換が成功していれば、SW4STM32から自動的にSTM32CubeIDEへ変わっているハズです。

SW4STM32プロジェクトインポート後、プラグイン版STM32CubeMXで開いたプロジェクトファイル

ファームウェアは、最新版STM32Cube FW_F1 V1.8.0になっています。そのままProject>Generate Codeをクリックし、コード生成を実行します。

３．CubeIDEへ戻ると、（デフォルトの自動コンパイル設定だと）Lcd.cなど数か所に赤下線のコンパイルエラーが発生します。

例えば、L236のLCD_EN_Pinは、CubeMXでGPIO_PIN_8をUser Label付けしたものです。LCD_EN_Pinへカーソルを持っていき、F3をクリックすると、定義ファイルmain.hのL103へ飛び、User Label付けは問題ないことが判ります。この段階では、コンパイルエラー原因は不明です。

４．コンパイルエラーがファームウェア起因かを確認するため、ファームウェアだけをFW_F1 V1.8.0からF1BaseboardTemplate 開発当時のFW_F1 V1.4.0へ戻します。但し、CubeIDE「プラグイン版CubeMX」は、ファームウェアを旧版へ戻す機能がありません。そこで、「スタンドアロン版CubeMX」を使ってファームウェアをFW_F1 V1.4.0へ戻し、再度コード生成を行うと、コンパイルエラーは発生しません。
※スタンドアロン版CubeMXでファームウェアを元の版数へ戻す方法は、4章で説明します。

以上の作業で、コンパイルエラー原因は、ファームウェア起因であることが判りました。

STM32CubeMXコード生成ファームウェア変更方法：4章

トラブルシューティングの前に、CubeMXでコード生成ファームウェア版数を変える方法を示します。CubeMXは、旧版ファームウェアをRepositoryフォルダへ自動保存し、いつでも旧版へ戻せる準備をしています。

１．スタンドアロン版CubeMXのProject Managerクリックで表示されるダイアログ一番下のUse Default Firmware Locationの☑を外し、BrowseクリックでRepositoryフォルダ内の旧版ファームウェア：STM32Cube_FW_V1.4.0を選択します。

２．そのままCubeMXでコード生成を実行すると、ファームウェア版数のみを変えたソースコードが生成されます。

※CubeIDEプラグイン版CubeMX（2つ前の図）は、Use Default Firmware Location自体有りません。つまり、最新ファームウェアでのみコード生成が可能です。
※CubeMXのGenerate Reportは、コード生成時の各種パラメタをPDF形式で出力する優れた機能です。しかし、肝心のコード生成ファームウェア版数が現状では出力されません。PDF出力へ手動で使用ファームウェア版数を追記することをお勧めします。

トラブルシューティング：5章

3章コンパイルエラー発生後、つまり最新ファームウェアFW_F1 V1.8.0でのコード生成後からトラブルシューティングします。

１．CubeIDEのエラーメッセージは、Symbol ‘LCD_EN_Pin’ could not be resolvedです。main.hで定義済みなので、なぜresolveできないのか不可解です。

２．そこで、Lcd.cの#include関連を見ると、#include “UserDefine.h”はあります。
※弊社テンプレートは、UserDefine.hでツール生成以外の全てのユーザ追加定義を記述し、全ソースファイルへincludeする方式を用いています。
※一方、CubeIDEは、CubeMXで生成するmain.cソースファイル1つへ、全ての制御を記述する方式を用いています。小規模なサンプルプロジェクトなどでは、解り易い方法です。
※但し、規模が大きくなると、ソースファイルを機能毎に分離し、ファイル単位の流用性やメンテナンス性を上げたくなり、弊社は、このファイル分離方法をテンプレートに採用中です。

３．UserDefine.hに、#include “main.h”の1行を追加します。

UserDefine.hへ#include "main.h" 追加 — UserDefine.hへ#include “main.h” 追加

４．Clear Project後、Build Projectでコンパイルエラーは解消し、コンパイル成功します。評価ボード：STM32F103RBでF1BaseboardTemplate の最新開発環境での正常動作確認ができます。

最新ファームウェアは、全てのユーザ追加ソースファイルに、#include “main.h”が必須なことがトラブル原因でした。

最新開発環境への移設まとめ：6章

2017年9月にSW4STM32で開発完了したSTM32Fxテンプレートは、UserDefine.hに、#include “main.h”追記で、2019年11月STM32MCU最新開発環境：STM32CubeIDE v1.1.0、STM32CubeMX v5.4.0、STM32Cube FW_F1 V1.8.0/FW_F0 V1.11.0へ移設できます。

2019年6月にSW4STM32で開発完了したSTM32G0xテンプレートは、なにもせずに、2019年11月最新開発環境：STM32CubeIDE v1.1.0、STM32CubeMX v5.4.0、STM32Cube FW_G0 V1.3.0へ移設できます。
※STM32G0xテンプレートは、初めからUserDefine.hに、#include main.hが追記済みです。

Build Analyzer

SW4STM32からCubeIDEへ移設後、最初に目に付くIDE画面の差分は、ビルド成功時、右下表示のBuild Analyzerだと思います。

最初の図で示したG0AdcTemplate移設後のCubeIDE Build Analyzerを示します。RAM、FLASH使用率が一目で解ります。その他のIDE画面や操作は、旧SW4STM32と殆ど同じです。

Serial Console

CubeIDEは、Serial Console画面を持っています。従来環境では別途必要であったVirtual COM Port （VCP）用のTera Termなどのツールが不要となり、IDEだけでVCP入出力が確認できます。高まるVCP重要性が最新IDEへ反映されたと思います（関連投稿：STLINK-V3の4章）。

但し、バックグラウンドが、Tera Termの黒からSerial Console画面では白になったため、テンプレートで用いたVCP出力文字色を、デフォルトの白から黒へ変更した方が見易いです。この色変更後のSerial Consoleが下図右側です。

TeraTerm画面とSTM32CubeIDEのSerial Console画面

汎用MCU第2位のSTM32MCU最新ソフトウェア開発環境

STM32MCUは、汎用MCUで第2位、シェア20％を超えています（関連投稿は、コチラ）。2019年4月新発表のSTM32CubeIDEは、半年を経て今回Major releaseし、v1.1.0になりました。無償IDEで、シェア続伸に向けて続々と新発売されるSTM32MCUデバイスへ対応中なのは、STM32CubeIDEだけです。

STM32CubeIDEを使い、本ブログ関連STM32MCUの最新ソフトウェア開発環境が、下表です。

名称	機能	2019/11/01版数	MCU評価ボード
STM32CubeIDE	Eclipseベースの統合開発環境	1.1.0
STM32CubeMX	初期化Cソースコード生成ツール	5.4.0
STM32CubeG0	STM32G0シリーズ用ファームウェア：G0_FW	1.3.0	STM32G071RB
STM32CubeG4	STM32G4シリーズ用ファームウェア：G4_FW	1.1.0	STM32G474RE
STM32CubeF0	STM32F0シリーズ用ファームウェア：F0_FW	1.11.0	STM32F072RB
STM32CubeF3	STM32F3シリーズ用ファームウェア：F3_FW	1.8.0	STM32F103RB

次回は、弊社販売中のSTM32FxテンプレートやSTM32G0xテンプレートを、上記最新ソフトウェア開発環境へ移設する予定です。

汎用MCUシェア20％超、第2位はSTM32MCU

2019年10月11日2019年10月18日 WithHappy

“シェア2位に躍り出たSTの汎用マイコン事業戦略”が、EE Times Japanに掲載されました。本稿は、この記事を要約し、記事記載のMCU 4ニーズの1つ、セキュリティ強化マイコン：STM32H7の暗号鍵利用によるソフトウェア更新方法（ST公式ブログ10月8日投稿）を示します。

STM32MCUは、汎用MCU世界市場シェア20％超の第2位へ

2019年9月、東京都内でSTマイクロエレクトロニクス（以下STM）による記者会見が開かれ、そのレポートがEE Times Japan記事内容です。ARM Cortex-Mコア採用のSTM32MCUが、2018年には汎用MCU世界市場シェア20％を超え第2位になった要因分析、今後のSTM汎用MCU事業方針が会見内容です。

車載用を除くMCUが汎用MCUです。本ブログも、この汎用MCUを対象としており、上図推移は重要なデータです。

以下、マイクロコントローラ＆デジタルICグループマイクロコントローラ製品事業部グローバル・マーケティング・ディレクタ）Daniel Colonna氏の記者会見談話を中心に記事要約を示します。

STM32MCUシェア続伸要因

STM競合他社は買収や統合で成長しているが、STMは独自でシェア2位を実現。要因は、民生機器だけに集中せず、産業機器などのインダストリアル分野（＝マスマーケット）に主眼を置き製品開発を行ってきたこと。マスマーケットターゲット事業方針は今後も変えず、シェア30%を目指す。

インダストリアル分野の4MCUニーズとSTM対応

演算性能の強化（STM32MP1/STM32H7）、より高度なAI実現（STM32CubeMXのAI機能拡張パッケージ）、多様な接続技術への対応（STM32WB）、セキュリティ強化（STM32Trust）の４点がインダストリアル分野MCUのニーズとそのSTMの対応（カッコ内）。

より広範囲なマスマーケット獲得策

モノクロからカラーLEDへ置換え（TouchGFX）、8ビットなどから32ビットMCUへ置換え（STM32G0シリーズ）で、より広範囲マスマーケットでのSTM32MCU浸透を図る。

以上が記者会見記事の要約です。

汎用MCU第2位となったSTM32MCU評価ボードは、入手性が良く安価です。コードサイズ制限なしの無償開発環境（STM32CubeIDE /SW4STM32/STM32CubeMX）も使い勝手に優れています。また、厳選された日本語技術資料も活用でき、初級/中級レベルのMCU開発者に最適だと筆者も思います。

この特徴を持つSTM32MCUに対して、弊社はSTM32G0x専用テンプレートやSTM32Fx汎用テンプレートを販売中です。今後は、STM32G4テンプレートも開発を予定しています。

これまでNon ARM汎用MCU1位であったRunesasも、ARMコア他社対応か（？）ついに2019年10月8日、Cortex-MコアMCU販売を開始しました。これについては、別途投稿します。

セキュリティ強化STM32H7のソフトウェア更新

インダストリアル分野４MCUニーズのうち、演算性能とセキュリティ強化を満たすのが、STM32H7（Cortex-M7/480MHz、Cortex-M4/240MHzのデュアルコア）です。筆者個人は、MCUというよりむしろMPUに属す気がします。STMも、STM32MCU（下記右）に対して、STM32マイクロプロセッサ（下記左）と区別しています。但し、名称は違っても、そこに用いる技術は同一のはずです。

丁度最初に示した10月8日のSTM公式ブログに、セキュリティ強化STM32H7のファームウェア書換え手順図を見つけました。関連投稿：総務省：2020年4月以降IoT機器アップデート機能義務化予定の2章で示した3種サイバー攻撃へのウイルス感染対策です。

ハードウェア暗号化エンジンを持つSTM32H7は、図右上のSFI：Secure Firmware Installで暗号化、STM32G0やSTM32G4等は、図右下のSMI：Secure Module Installで暗号化し、更新ソフトウェアを準備します。どちらも、セキュリティ認証情報を含むHSM：ST Hardware Secure Module smart cardで鍵を受渡し復号化、ソフトウェア書換えを行います。

我々が開発するMCUソフトウェアの更新頻度は、PCに比べれば低いはずです。しかし、その頻度は、ウイルスの数に比例しますので、サイバー攻撃が増えればその度にこの書換えで対応することを考えると憂鬱になります。
※書換え失敗やワクチン投入による通常処理への配慮も必要で、Windows 10のようにユーザ任せの無責任な対応はMCUソフトウェアでは論外なため、開発者負担は増すばかりです😫。

STM32CubeIDE v1.0.1更新

2019年7月16日2019年7月19日 WithHappy

STマイクロエレクトロニクス（以下STM）のSTM32マイコンマンスリー・アップデート2019年7月号P9に、STM32CubeIDEのv1.0.1更新が記載されています。

STM32CubeIDE v1.0.1更新内容

内蔵のコード生成ツールSTM32CubeMXがv5.2.0からv5.2.1に変更されたこと、バグ修正が主な更新内容です（RN0114（2019/07/11））。

最新のSTM32CubeMX v5.2.1により、STM32G0x LL APIを活かしたソフトウェア開発がSTM32CubeIDE v1.0.1でも可能となりました。つまり、弊社推薦のSTM32MCU開発環境：SW4STM32＋STM32CubeMX v5.2.1＋STM32G0 FW 1.2.0と同じ土俵に今回の更新でなった訳です。

ベースEclipse IDE状況

STM32CubeIDE v1.0.1のベースEclipse IDE は、ECLIPSE™ 2019-03 です。Eclipse最新版は、ECLIPSE™ 2019-06（2019/06/19）ですので、ベースに合わせてSTM32CubeIDEも更新されるでしょう。

Eclipse IDEは、昨年の2018年6月までは、Photon、Oxygen、Neonなどのリリース名が付いていましたが、6月以降は、ECLIPSE™リリース年-月に変更されました。3か月毎に更新され、次回は2019-09予定です。
※メジャー/マイナー更新かは、判りにくくなりました。

STM32CubeIDE v1.0.1使用所感

今回の更新で期待していた日本語対応に関しては、旧STM32CubeIDE v1.0.0からの改善は見られません。

例えば、SW4STM32プロジェクトをSTM32CubeIDEへインポートすると、日本語ソースコードコメントが文字化けします。Preferences>Text Editors>Colors and Fontsを変えても同様です。

付属エディタを使っての直接日本語入力は問題ありませんが、SW4STM32からのマイグレーションツールでの文字化け発生は、回避手段があるとは思いますが面倒です。Atollic社）TureSTUDIO最終版で見せた日本語メニュー実装などは、先の話になりそうです。

また、旧v1.0.0では正しく表示されていたInformation Centerページも、‘表示できません’となります。

RN0114の2.3 Known problems and limitations項目も多いので、あえて今すぐにSW4STM32に変えてSTM32CubeIDE v1.0.1を使う必要性は感じません。土俵（付属開発ツール版数）が同じになっただけです。

現行SW4STM32 → 新STM32CubeIDE切替えタイミング

コードサイズ制限無しのSTM32MCU無償IDEは、旧Atollic社）TrueSTUDIOは既にDiscontinue、AC6社）SW4STM32も新デバイスへの更新をしない可能性が高いと思います。新しいIDE：STM32CubeIDEへ切替えるタイミングが、そろそろ近づいてきました。

筆者としては、SW4STM32の更新状況を注視しつつ現行IDE使用を維持し、次回のSTM32CubeIDE更新タイミングで新IDEへ切替えるつもりです。

STM32G0動画と専用テンプレート

2019年6月27日2019年6月29日 WithHappy

STマイクロエレクトロニクス（以下STM）の公式ブログで、STM32G0を理解できるPart.0～10の動画（英語版）を紹介しています。
各動画は、休憩時間に視聴するのに丁度良い6分から15分程度の長さです。

動画リスト

13:13 Pt. 0, Install Procedure

6:05 Pt. 1, Saving Content of the Flash of the STM32

13:47 Pt. 2, Blinky

13:09 Pt. 3, PWM

9:10 Pt. 4, External Interrupt

14:20 Pt. 5, Low Power (Pt. 1)

6:23 Pt. 6, Low Power (Pt. 2)

13:19 Pt. 7, Printf

13:27 Pt. 8, Low Layer Drivers

17:37 Pt. 9, DMA

15:14 Pt. 10, Flashing STM32

少し聞きにくい英語ですが、スライドを見るだけでも内容は解ると思います。

開発環境

動画のIDEは、KeilのSTM32G0/F0/L0専用無償版を使っています。既にSTM32CubeIDEやSW4STM32を利用中の方は、これらIDEとKeil専用版を同時インストールすると、STM32G0/F0/L0のみコンパイル可能となるトラブルが発生するらしいので注意してください。

IDE以外は、コード生成ツール：STM32CubeMX、評価ボード：Nucleo-G071RB、通信アプリ：Tera Termなどおなじみの環境での解説です。

STM32G0のSTM32F0/F1をカバーする広い守備範囲、Low Layer API開発メリットや重要性などが理解できると思います。残念なのは、STM32G0x全シリーズ搭載の最新ADC解説が無いことです。ADCに関しては弊社関連投稿を参照ください。

STM32G0x専用テンプレート

動画Part8紹介のLL APIを活用したSTM32G0x専用テンプレートを発売中です。

STM32G0xシリーズのプロトタイプ開発着手時に必要となるLPUARTやLED制御などの複数サンプルソフトがあらかじめ実装済みで、評価ボードADC入力変換値のTera Term出力も実装済みです。

STM32G0xシリーズ性能をフルに発揮したアプリケーション早期開発や、STM32G0習得に最適です。

ご購入、お待ちしております。

続報：STM32CubeIDE

2019年5月16日2019年5月26日 WithHappy

2019年5月8日STマイクロエレクトロニクス（以下ST）公式ブログで無償STM32CubeIDEの続報が掲載されました。STM32マンスリー・アップデート2019年5月号のトップページにも掲載中です。

STM32CubeMXがビルドインされたST初のIDE：STM32CubeIDE内蔵ツール版数と、ライバルIDEに相当するSW4STM32とTrueSTUDIOの今後を予想します。

STM32CubeIDE内蔵ツール版数

STM32CubeIDEにビルドインされたツール版数が下記です。FWは、本ブログ対象STM32F0/F1/G0のみ掲載します。ビルドインSTM32CubeMXの使い勝手は、単独STM32CubeMXツールと同じです。

内蔵ツール	2019年5月16日版数
STM32CubeIDE	1.0.0
STM32CubeMX	5.2.0
STM32F1 FW	1.7.0
STM32F0 FW	1.10.0
STM32G0 FW	1.2.0

STM32CubeIDE起動時に各ツール更新がチェックされるので、起動に多少もたつきを感じます。MicrosoftのC2R：Click to Runに近い機能です。

STM32G0 FW 1.2.0インストールには、STM32CubeMX 5.2.0以上が必要な点は注意が必要です。単独でSTM32CubeMX 5.1.0使用中の方が、FW更新してもSTM32G0 FW 1.2.0の検出すらできません。先ず、STM32CubeMXを 5.2.0へ更新後、再更新チェックでSTM32G0 FW 1.2.0が使えます。

全てがビルドインされたSTM32CubeIDEなら、このような版数による最新版インストールトラブルが回避できるでしょう。

STM32CubeIDEのAdvanced Debug機能

STMCubeIDE you are able to（出典：How to use STM32CubeIDE動画）

How to use STM32CubeIDEから抜粋したSTM32CubeIDE新機能が上図です。Advanced DebugのLive Expressions viewやSWV real-time tracing viewは、デバッグがより楽しく容易になる機能だと思います。

STM32CubeIDEライバル、無償AC6）SW4STM32と旧Atollic）TrueSTUDIOの今後

気になるのは、STM32CubeIDEと同様のコードサイズ制限なし無償IDE、AC6社）SW4STM32と旧Atollic社）TrueSTUDIOの2つのIDEが、今後更新され続けるかです。

ブログ内に、SW4STM32とTrueSTUDIO各ユーザに向けた注意書きがあります（Before STM32CubeIDE, What SW4STM32 and TrueSTUDIO Users Must Know章）。ブログでは、どちらのIDEユーザに対しても新しいSTM32CubeIDEへの移行を促しているようです。有償のIARとKeilのIDEに対しては、これまで通りです。

TrueSTUDIOは、既にSTM32G0 FW 1.2.0未対応です（関連投稿：TrueSTUDIOとSTM32CubeMXインストール方法の手順4参照）。SW4STM32は、最新デバイスをフォロー中ですが、近い将来、TrueSTUDIOと同じ運命、つまり、ツール改版への遅れや最新MCUへ対応しない可能性があります。

2017年末にSTに買収されたAtollicのIDE開発力が、新しいST純正STM32CubeIDE開発へ使われたとすると、現行のTrueSTUDIOが最新STM32G0xデバイスに未対応なのも納得がいきます。いわゆるデスコン（Discontinue）の前兆です。

なお、既成SW4STM32プロジェクトやTrueSTUDIOプロジェクトに対しては、STM32CubeIDEマイグレーションツール（UM2579など）がSTM32CubeIDE初期画面に用意されています。既成プロジェクトは、そのままSTM32CubeIDEで開くことはできず、また、一旦マイグレーションすると、元のSW4STM32プロジェクトへは戻せません。

このため、UM2579では、既成プロジェクトをバックアップ後、マイグレーションすることを明記しています。

STM32CubeIDEの使い勝手は、SW4STM32に近く、しかもAdvanced Debug機能でデバッグも面白くなりそうです。現版STM32CubeIDE 1.0.0は日本語対応がイマイチです。この点が改良されればSW4STM32からのマイグレーションを検討する予定です。

汎用STM32FxテンプレートのSTM32G0x使用法

2019年5月10日2019年5月16日 WithHappy

LL APIを利用するSTM32G0x「専用テンプレート」開発は、3月からの投稿で一応目安が付きました。
※投稿下欄タグ：専用テンプレートをクリックすると本稿を含め関連投稿が読めます。

これらの投稿で販売中の汎用STM32Fxテンプレートは、HAL APIを使っているので別STM32MCU、例えばG0シリーズMCUのSTM32G071RBなどへの使用・移植も簡単であることを何度か書いてきました。

そこで、この「汎用テンプレート」のSTM32G071RBへの使用法を説明します。

STM32Fxテンプレートは、図1に示すようにF0シリーズMCUのSTM32F072RBと、F1シリーズMCUのSTM32F103RB両方で動作確認済みです。本稿は、このSTM32FxテンプレートをSTM32G0へポーティングします。

汎用STM32FxテンプレートのSTM32G0x使用法まとめ

HAL APIはSTM32MCUで共通なので、HAL API利用アプリケーション（この場合はテンプレート、STM32Fx Template）は、STM32デバイスが変わってもそのまま使える
HAL APIより下層のソフトウェアは、STM32CubeMXを使って自動生成
STM開発環境にMCU移植機能が無い現状では、移植デバイス先のSTM32CubeMX設定さえ間違わなければ、HAL APIより上層アプリケーションの使用・移植は、簡単

汎用STM32Fxテンプレートを購入検討中の方、または既にSTM32Fxテンプレートをお持ちの方は、HAL API利用STM32Fxテンプレートの別デバイス移植性が優れていることが本稿でご理解頂けると思います。

汎用STM32F0シンプルテンプレートのSTM32G071RB移植手順

手順1．SW4STM32で、F0SimpleTemplateプロジェクト名をG0SimpleTemplateへリネームコピー

手順2．STM32CubeMXで、評価ボードNucleo-G071RBプロジェクトを新規作成し、F0SimpleTemplate.icoと同じ変更を加え、手順1でリネームしたG0SimpleTemplate.icoへ上書き保存後、コード生成

手順3．SW4STM32で、G0SimpleTemplateのmain.cとUserDefine.hなど数か所を変更＆コンパイル

手順4．STM32G071RB評価ボードNucleo-G071RBで、移植シンプルテンプレート動作確認

文章で書くと手順１～4のように量が多くなります。しかし、HAL APIはSTM32MCUで共通、デバイスが変わってもHAL API利用アプリケーションをそのまま使うために、下層の構築にSTM32CubeMXを使うだけです。HAL APIアプリケーション移植は簡単です。

手順詳細を説明します。

手順1：SW4STM32で、F0SimpleTemplateプロジェクトをG0SimpleTemplateへリネームコピー

F0SimpleTemplateをコピー、同じワークスペースへペーストする時にG0SimpleTemplateへリネームします。

F0SimpleTemplateをG0SimpleTempleteへリネームコピー

G0SimpleTemplateフォルダ内のF0SimpleTemplate.iocをG0SimpleTemplate.iocへF2：リネームします。
※手順1の目的は、F0SimpleTemplateソースコードのユーザ追記部分を、丸ごとG0SimpleTemplateで流用するためです。

手順2：STM32CubeMXで、Nucleo-G071RB新規作成とコード生成

現状のSTM32CubeMXには、MCUデバイス間の移植機能がありません。そこで、F0SimpleTemplate.iocファイルを見ながら、新規作成Nucleo-G071RBの周辺回路を手動で同じ設定にします。

先ずG0SimpleTemplete.iocファイルを新規作成し、手順1でリネームしたG0SimpleTemplete.iocへ上書き保存します。その後、STM32CubeMXの2重起動を活かしF0SimpleTemplate.iocを見ながらG0SimpleTemplete.ioc周辺回路を同じ設定にします。最後に、全ての周辺回路をHAL APIでコード生成します。

※Connectivityは、F0SimpleTemplateに合わせてUSART2、Clock Configurationは、HCLK Max.の64MHz、Timerは、F0SimpleTemplateのTIM3機能に近いTIM7を使いました。

手順3：SW4STM32で、main.cとuserdefine.hの数か所を修正＆コンパイル

どのようなアプリケーションソフトでも、デバイス依存の箇所があります。F0SimpleTemplateも同様です。これらは手動で変更・修正するとビルドが成功します。変更・修正箇所が下記です。

HALライブラリとBSP（Board Support Package）変更
stm32f0xx_hal.h→stm32g0xx_hal_conf.h、stm32f0xx_nucleo.h→stm32g0xx_nucleo.h（UserDefine.h）
BSPはRepository\STM32Cube_FW_G0_V1.2.0\Drivers\BSP\STM32G0xx_Nucleoのstm32g0xx_nucleo.c/hをSrc/Incへコピー
TIM3の代わりにTIM7を使ったので、htim3→htim7（main.c）
G0SimpleTemplateに無関係ファイル削除（stm32f0xx_nucleo.c/h, system_stm32f0xx.c）

手順4：評価ボードNucleo-G071RBで動作確認

F0SimpleTemplateをG0SimpleTempletaへ流用したVitrual COMポート画面

※表示メッセージは、STM32G0xデバイス対応に変更しています。

あとがき

繰返しますが、文章で書くと移植手順は長く複雑に感じます（特に手順3）。しかし、ソフトウェアアーキテクチャ図1が理解済みならHAL API利用アプリケーションの別デバイスへの移植は簡単です。手順3内容は、デバイスが変われば当然必要となる事柄です。

HAL API利用アプリケーションの最大メリットは、MCU移植が容易なことです。つまり、HAL APIアプリケーションは、「STM32MCUデバイス非依存」とも言えます。

現状では、このメリットを活かす開発環境が不備なだけです。不備分は手動で補い、STM32F0/F1アプリケーションをSTM32G0アプリケーションへ移植する方法を示しました。

近い将来、STM開発環境にMCUデバイス移植機能が提供されると筆者は思います。

お知らせ：LL APIを利用するLL APIのSTM32G0x「専用」テンプレートの販売時には、本稿のHAL API利用「汎用」G0SimpleTemplateも添付し、専用と汎用の両方を1パッケージで販売する予定です。

※LL APIとHAL APIの差を把握したい方は、STM32CubeMXのLow-Layer API利用法（２）を参照ください。