FRDM-KE02Z40M アーカイブ - IoT MCUのHappyTech

OpenSDA接続トラブル解決方法

2020年7月31日2020年8月19日 WithHappy

ブログ読者様のおかげで、不明だったFRDM評価ボードOpenSDAとMCUXpresso IDE間の接続トラブル解決方法が判明しました。本稿は、このOpenSDA接続トラブル解決方法と、昨今の激しいMCU開発環境変化への開発者対応私案を示します。

OpenSDA v1/v2差

前投稿当日、弊社ブログ読者様からFRDM評価ボードOpenSDA処理トラブル時のJ-Linkハードウェアデバッガによる解決方法と、その根拠となったNXP Communityリンク、さらに、同様のトラブルを抱えた方々向けに、ご提供情報を弊社ブログで共有してくださいとのメールを頂きました。

この場を借りて御礼申し上げます。ありがとうございます。

ご提供情報を基に、FRDM評価ボードOpenSDA v1/v2の差をまとめたのが、下表です。

OpenSDA v1/v2とFRDM評価ボードのまとめ
OpenSDA版数	評価ボード例	開発者	トラブル状況	トラブル解決方法
OpenSDA v1.0	FRDM-KE02Z40M	P&E Micro社 (Proprietary)	弊社あり	OpenSDA処理MCUをハードウェアデバッガで書換えれば解決の可能性あり
	FRDM-KL25Z		弊社なし
OpenSDA v2.0	FRDM-K64F	ARM/mbed.org (Open source)	Community内あり	OpenSDA処理MCUをハードウェアデバッガ:SEGGER J-Linkなどで書換えて解決（情報提供者様の解決実績あり）
OpenSDA v2.1以上	FRDM-K22F

OpenSDAにはv1系とv2系があり、v1.0は開発会社：P&E MicroのProprietary製品、v2系はARM/mbed.org開発のオープンソースです。また、新しいFRDM評価ボードの多くはv2.1以上を搭載済みで、v1.0やv2.0は古くからあるFRDM-K64Fなどです（Getting Start with MCUXpresso SDK, Rev.3, 03/2017のTable 1掲載ボードでの比較。この表になぜかFRDM-KE02Z40Mの記載はありません）。

Getting Start with MCUXpresso SDK Rev. 3 03-2017のTable 1

OpenSDA接続トラブル解決方法

OpenSDA v2系のブートローダ更新失敗などにより生じたMCUXpresso IDE接続トラブルは、SEGGER J-Linkなどのハードウェアデバッガを使って、OpenSDA処理MCU：Kinetis K20（Cortex-M4）を、評価ボードのJ-TAGコネクタ経由でユーザが直接再プログラミングすれば解決します。再プログラミング用コードも、オープンソースです（情報提供者様の解決実績もあります）。

しかし残念ながら、弊社トラブル中のFRDM-KE02Z40Mは、OpenSDA v1.0です。OpenSDA 1.0は、処理ソフトウェアがProprietary（非オープンソース）ですので、この処理部分のユーザによる再プログラミングが可能かはCase-by-caseです。

通常Proprietaryソフトウェアは、下記理由で再プログラミングができない場合が多いと思います。

理由：前稿で示したユーザ（筆者）が、Windows 10ストレージサービスを一時停止しなかったブートローダ更新は、MCU側にとってはProprietary処理ソフトウェアの悪意侵害と判断される可能性があります。
侵害と判断された場合には、セキュリティ防御手段としてMCU書込みプロテクトをかけ、再プログラミングはできなくなります。また、Proprietaryなので初めからMCU書換えプロテクト済みの可能性もあります。

※USB経由で行うブートローダ更新と、J-TAG経由のOpenSDA処理MCUソフトウェア書換えは、別物であることに注意してください。

FRDM-KE02Z40M Proprietary OpenSDA v1.0再プログラミングは、トラブル実機で試す必要があります。Proprietaryソフトウェアのため、書換え障壁はオープンソースOpenSDA v2系よりも当然高いと思われます。

J-TAGハードウェアデバッガメリット

評価ボードOpenSDA v1.0再プログラミングに必要となるJ-TAGハードウェアデバッガ価格は、例えばSEGGER J-Linkなら最低€300から、円換算で約￥37,000（2020年7月）からです。

同じ金額で10枚程度の最新MCU評価ボードが購入できるので、個人レベルのJ-TAGハードウェアデバッガ購入は勇気がいります。

J-TAGハードウェアデバッガのメリットは、旧Freescale）Bertrand Deleris氏の組込み向けデバッグ技術の基本（2007年3月：EDN）が良く解ります。マルチコアMCUデバッグや、ハードウェア/ソフトウェアブレークポイント差、セキュリティとDebug/Releaseの関係など参考になりますので、一読をお勧めします。

半導体ライフサイクルとMCU開発者対応私案

半導体製品のライフサイクルと製造中止（EOL）対策（2020年7月、EE Times）によると、多くの半導体製品の平均寿命は、3～5年だそうです。

MCUベンダ各社は、10～15年の安定供給を保証しますが、製品搭載済みMCUの賞味期限は、我々開発者が製品化に1年要したとして、発売後5年程度だと個人的には思います。

※MCU賞味期限≒MCUの差別化特徴を活かした製品が競合他社より優位な期間。IoTセキュリティ、AI機能実装や製造プロセス細分化など今後MCUは激変するハズなので、より短くなると思います。

丁度、新車購入後、2回目の車検（3年＋2年＝5年）で名目上の減価償却する自動車と同程度です。

COVID-19の影響で少し鈍る可能性もありますが、ADAS（先進運転支援システム）が引っ張る自動車と同様、“MCU製品も5年目安で世代交代を考えるべきだ”と思います。

また、「日本製品」が海外で売れなくなった根本原因（2020年7月、東洋経済オンライン）を読むと、「加点型の完璧主義」の世界基準に対して、日本人の「盆栽のような減点型のミニマムな完璧ものづくり」が日本敗因の1つです。プラス側メリットやそれに費やした見えない労力などは無視する一方、マイナス側の過度な批判は、日本特有かもしれません。

“基準を減点型→加点型へ180度変える努力が日本は必要”になりそうです。

MCU開発環境は、PC OSも含めて常に変化・進化します。そして、それらの環境変化は全て世界基準です。

MCUXpresso IDEは、7月9日にv11.2.0へ、MCUXpresso SDKの多くは、7月19日にv2.8.0へ更新されました。次々に生まれる新MCUや環境変化に対応するためですが、逆にこれら変化・進化に馴染まない従来MCUや減点型対応者も生じます。これらは、徐々に進化と逆らい「ガラパゴス化」している訳です。

MCU開発者は、変化・進化する環境に対して、開発中、または顧客稼働中のMCUが進化に馴染まなくなる兆候・前兆を素早く捉え、最終利用者と協議の上、従来から180度変えた“加点型対応策を取ることが、ワールドワイドなMCU開発者との競争に生き残り、その結果、日本製品も生き残れる方法”だと思います。

ガラパゴス化が全て悪い訳ではありません。しかし、日本MCU開発者がガラパゴス化すれば、その生存確率は確実に下がります。

まとめ、新開発汎用Kinetis Lテンプレート

これまでの章内容をまとめます。

壊れたFRDM-KE02Z40のOpenSDA v1.0 Proprietary再プログラミングには、J-TAGハードウェアデバッガ：37,000円が必要で、OpenSDA v2系とは異なるProprietaryソフトウェアのため、書換え可能かはトラブル実機検証が必須。
J-TAGハードウェアデバッガは、MCUコア/ベンダに依存しない強力デバッグツール。
激変MCU環境に対して、加点型へ進化しないと日本MCU開発者はガラパゴス化する。

これらから、FRDM-KE02Z40（Cortex-M0+/40MHz、5V Robust）のOpenSDA v1.0 Proprietary再プログラミングはあきらめ、5V耐圧が特徴であるKinetis Eテンプレートv2改版開発は中止、新たにFRDM-KL25Z（Cortex-M0+/48MHz、General Purpose = Main Stream）を用いた汎用Kinetis Lテンプレート開発に着手しようと考えております。

5V耐圧の代案は、一般的になってきたレベルシフタを用いる方法でKinetis Eテンプレートの最終利用者様への対応をお願いいたします（関連投稿：MCUの5V耐圧ピンを参考にしてください）。

5V耐圧を失う代わりに、FRDM-KE02Z40Mでは実装していましたが動作しないTouch pad (Slider)が、FRDM-KL25Zでは動作します。Touch pad (Slider)動作には、MCU内蔵Touch Sense Input：TSIハードウェアが必須です。FRDM-KE02Z40Mは内蔵されていません。TSIライブラリソフトウェアのみでは動作しないことは、2015年開発のKinetis Eテンプレート v1で確認済みです。

新開発の汎用Kinetis Lテンプレートは、このFRDM-KL25Z内蔵TSIハードウェアとライブラリ使いTouch pad (Slider)を、外付けSW入力の代わりに用います。

※FRDM-KL25Z搭載のMCU：MKL25Z128VLK4 （Cortex-M0+/48MHz、Flash:128KB、RAM:16KB、66:IOs）は最新MCUとは言えませんが、「低価格、入手性良し、汎用性（Main Stream）、応用範囲の広さ、OpenSDAトラブル無し」が、新規汎用テンプレート開発採用にプラスに働きました。

さいごに

多彩な情報満載のCommunityですが、逆に欲しい答え発見までにかなりの時間・労力がかかるのもCommunityです。

ブログ読者様ご提供Communityリンクのおかげで、短期間で効率的に問題解決法を見つけることができ、さらにJ-TAGハードウェアデバッガなどの関連情報収集、現状テンプレート開発見直しもできました。

ここにあらためて心より感謝いたします。ありがとうございました。

FRDM評価ボードOpenSDA接続問題整理

2020年7月22日2020年8月7日 WithHappy

Kinetis E（Cortex-M0+/40MHz、5V Robust）テンプレートv2開発障害となっている評価ボード：FRDM-KE02Z40MのOpenSDAとMCUXpresso IDEデバッガ間の接続問題は、残念ながら未解決です。今回は、このOpenSDA問題を簡単に整理します。また、Linuxによる第2のMCU開発環境構築の新設カテゴリも示します。

Kinetis OpenSDA

OpenSDA Block Diagram（出典：OpenSDA Users Guideに加筆）

Figure 1は、MCUXpresso IDEとKineties MCU間のブロック図です。旧Freescaleは、Kinetis Design Studio：KDSというFreescale製IDEとKinetis MCU評価マイコンボード間の接続は、OpenSDAというインタフェースで接続していました。

このOpenSDAは、KDS直接接続だけでなく、PC（Windows 7）との接続時、File System（USBメモリ）として動作し、クラウド開発環境：mbed開発にも利用できる2種類のプログラミング機能を持ちます。

現在問題発生中のFRDM-KE02Z40MのOpenSDAも、Windows 7当時は問題なく動作していました。その結果、Kinetis Eテンプレートv1発売ができました。

MCUXpresso IDE接続問題（Windows 10）

Freescaleを買収したNXPは、自社LPCと新旧Freescale Kinetis両マイコンに新しい統合開発環境：MCUXpresso IDEを用意しました。このMCUXpresso IDEの評価ボード接続インタフェース一覧（一部抜粋）が下図です。

MCUXpresso SDK support platform（出典：Getting Started with MCUXpresso）

簡単に説明すると、MCUXpresso IDEは、NXP純正評価ボードEVKやLPCXpresso54xxx接続インタフェース：CMSIS-DAPと、新旧FRDM評価ボード接続インタフェース：OpenSDA v1系/v2系とmbedの3種類全てをサポートします。

接続問題が発生するのは、OpenSDAの一部です（表内にFRDM-KE02Z40Mが無いのは不安ですが、記載漏れだと思います）。FRDM-KL25Z（Cortex-M0+/48MHz、General Purpose）のOpenSDAは、MCUXpresso IDEと問題なく接続できています。

接続問題解決には、Figure 1のMSB Bootloaderを、MCUXpresso IDE対応済みの最新版へUpdateすることが必要です。

MSB Bootloader更新注意点（Windows 10）

MSB Bootloader更新方法は、評価ボードのリセットボタンを押しながらPC（Windows 10）とUSB接続し、エクスプローラーに現れるBootloaderフォルダへ、最新版：BOOTUPDATEAPP_Pemicro_v118.SDAをドラッグ＆ドロップするだけです（FRDM-KE02Z40Mの最新Bootloaderは、コチラから取得できます）。

この操作後、再度評価ボードとPCを接続すると、今度はエクスプローラーに通常モードのFRDM-KE02Z40Mフォルダが現れ、更新完了となるハズです。ところが、筆者の評価ボードは、Bootloaderモードから通常モードへ復帰しません。

従って、MCUXpresso IDEとFRDM-KE02Z40MをUSB接続しても、IDEは評価ボード無しに認識します。

簡単に説明しましたが、実際はWindows 10でのBootloader 更新時、「Windows 7では不要であったストレージサービスの一時停止が必須」です（詳細は、コチラのNXP情報のStep 2を参照してください）。

調べると、Windows 8以降に一般的なユーザには知らせずに追加したWindows PCのUSBメモリへの隠しフォルダ書込み機能（これが上記一時停止するストレージサービス）が、諸悪の根源のようです。

FRDM評価ボードOpenSDA接続問題整理と対策（Windows 10）

以上を整理し、対策をまとめます。

・旧Freescale製FRDM評価ボードが、新しいNXP MCUXpresso IDEと接続できない原因は、評価ボードOpenSDAのMSB Bootloaderにあり、対策は、MCUXpresso IDE対応版Bootloaderへの更新を、Windows 10ストレージサービスを停止させた状態で行うことが必要。

旧Freescale製（つまりWindow 7対応）のまま入手したFRDM評価ボードは、FRDM-KE02Z40M以外でもIDE接続問題が発生することがありますので、上記まとめを参考に対策してください。

このまとめと対策にたどり着く前に、Windows 10でストレージサービスを停止せずにFRDM-KE02Z40MのOpenSDA MSB Bootloader更新を何度か繰返しました。評価ボードが、Bootloaderモードから通常モードへ復帰しない理由は、これかもしれません😥。

筆者は、Windows 7時代からFRDM評価ボードを活用してきました。まさか、Bootloaderモード時にWindows 10ではサービス一時停止が必須だとは思いもしませんでした。しかも、このサービスは隠しフォルダ対応なので、通常ではWindows 7と同様にBootloader更新が正常終了したように見えます。

事前に調査しなかった筆者が悪いのですが、旧Freescale評価ボード記載Windows 7対応マニュアル通りに対処すれば、筆者と同じトラブルに出会う人は多いハズです。

また、OpenSDAユーザズガイドにも上記トラブルからの復帰方法の記載はありません。ネット検索か、NXP communityが解決手段でしょう😥。解決方法が見つかれば、本ブログでお知らせします。

エンドユーザを無視したかのようなWindows 10の度重なる変更に起因するトラブルは、今後も増える可能性があると思います。次章は、その対策です。

Windows MCU開発者向けLinuxカテゴリ新設

筆者は、昨年からLinux MintでのMCUXpresso IDE開発環境もWindows 10のバックアップ用に構築しています。このLinux環境でも、残念ながら今回のトラブル回復はできていません。

今回はLinux/Windows両方NGでしたが、Windows以外の第2のMCU開発環境があると、何かと便利です。

そこで、本ブログで、Windows MCU開発に慣れた開発者が、簡単にLinuxを使うための情報も発信したいと思います。このための新設カテゴリが、PC：パソコン＞Linuxです。
※親カテゴリPC：パソコンへ、LibreOfficeとWindowsも移設しました。

Windows 10、Linuxともに単なるPC OSです。Linux上でMCU開発アプリケーション、本ブログではNXP MCUXpresso IDEやSTM STM32CubeIDEを利用するために、最低限必要な情報に絞って説明する予定です。

Linux情報量もまたWindows同様多いのですが、Windowsに慣れたMCU開発者としては、当面不要な情報も多く、Windowsの代わりにLinuxを短期間で効率的に活用するMCU開発環境構築が目標・目的です。今回のようなWindows PCでのトラブル発生時、Linux PCへ移ってMCU開発を停止することなく継続するのが狙いです。

MCU Devopments Windows and Linux 2 Routes

Linuxのシステム動作要件は下記で、Windows 10よりも低いので、古いPCでも快適に動作します。ただし新しいOS利用なら「64ビットCPUは必須」ですが…😅。32ビットPC OSの新規開発は、終了しました。

1GB RAM (2GB recommended for a comfortable usage)
15GB of disk space (20GB recommended)
1024×768 resolution

COVID-19の影響で、市場に中古PCが安価で数多く出回っていますので、これら活用も一案かと思います。

MCUXpresso Config Toolsの使い方

2020年7月17日2020年7月31日 WithHappy

前稿に続きMCUXpresso SDKベースのMCUソフトウェア開発に欠かせないMCUXpresso Config Toolsの使い方を説明します。SDKサンプルプログラムに少しでも変更を加える時には、Config Toolsが必要になります。

Config ToolsとSDK

MCUXpresso IDEのSDKサンプルプロジェクトは、そのままコンパイルして評価ボードで即動作可能です。ユーザが変更を加える箇所は、sourceフォルダ内に限られています。sourceフォルダ以外は、ライブラリフォルダです（詳細は、前稿を参照してください）。

Config Toolsは、このSDKライブラリに変更を加えるツールです。

SDKサンプルプロジェクトは、MCU内蔵周辺回路の動作例ですが、逆に言うと、「その周辺回路しか動作させない例」です。低電力動作が必須のMCUでは、しごく当然のこのソフトウェア作法、つまり無用な回路は動作させない方針で開発されています。

ところが、SDKサンプルプロジェクトにユーザが変更を加える場合、サンプルプロジェクトで動作中の回路以外の周辺回路動作を新たに加える時があります。

この時には、MCUXpresso Config Tools>>をクリックし、MCU内蔵の眠っている（＝Inactive）周辺回路の目を覚ます（＝Activate）必要があります。

周辺回路をActivateした結果、サンプルプロジェクトのSDKライブラリに対して、相応の変更をConfig Toolsが自動生成（上書き）します。これが、Config ToolsとSDKの関係です。

Config Toolsの使い方

具体的にFRDM-KL25Z（Cortex-M0+/48MHz、General Purpose）評価ボードのSDKサンプルプロジェクト：gpio_led_outputを例に、Config Toolsの使い方を説明します。このサンプルプロジェクトは、いわゆるLチカサンプルで、評価ボード上の赤LEDを点滅させます。

ここでは、赤LEDの代わりに緑/青LEDを点滅させる変更をユーザが加えると想定します。

※他のサンプルプロジェクトも、殆ど赤LED（BOARD_RED_LED）1個のみを動作させますので、この緑/青LED変更方法は、多くのサンプルプロジェクトにも流用できます。

MCUXpresso SDKのgpio_led_outputソースコード（一部抜粋）

先ずConfig Toolsを使わずにL40とL41のRED_LEDをGREEN_LEDへ変更後、Buildします。その後、DebugでFRDM-KL25Z評価ボードを動作させても緑LEDは点滅しません。もちろん、ブレークポイントをL92に設定して動作は確認済みです。

LEDが点滅しない理由は、評価ボードの緑/青LEDに接続済みのgpioピンが、Inactiveだからです。

対策にMCUXpresso Config Toolsをクリックすると、Develop画面がPins画面へ変わります。

Routed Pinsタブ①に、GPIOB：LED_REDがリストアップされています。このリストは、Activate済みの全ピンを示します。

そこで、Peripheral Signalsタブ②で緑/青LEDのGPIOB、19とGPIOD、1に✅を入れると、リストに両ピンが加わります。Identifierは、LED_GREENとLED_BLUEにします。

MCUXpresso Config ToolsでActivateした緑と青LEDのgpioピン

この状態で、「緑色」のUpdate Codeボタン③をクリックすると、Update Filesダイアログが開き、上書き対象のSDKライブラリが一覧表示されます。この場合は、ライブラリ：board>pin_mux.c/hとboard>clock_config.c/hが上書き更新されます。

ダイアログのOKクリックで最終的にSDKライブラリへ変更が加わり、自動的にDevelop画面に戻ります。上書きされるライブラリのソースコードは、Pins画面上のCode Previewタブ④でも更新前に確認ができます。

戻ったDevelop画面で、RED_LEDをGREENやBLUE_LEDへ変更し、Build を再実行、Debugすると、今度は評価ボードの緑/青LEDが点滅します。

Config Toolsが、緑/青LED接続のgpioピンをActivateしたSDKライブラリに上書き更新したからです。

このようにSDKサンプルプロジェクトは、必須周辺回路とクロックルートのみをActivateした例で、その周辺回路単体でのMCU消費電力も判ります。この時のクロック周波数は、MCU最高動作周波数です。周波数を下げることで消費電力も減らせますが、その分ソフトウェア開発の難易度は上がります。

機能的には似た周辺回路がある場合や、特に電力消費が大きい回路を比較・最適化し、MCUトータル消費を改善する手段としてもサンプルプロジェクトは利用できます。

MCU電力低減方法は、SDK/Config Toolsデフォルトの最高周波数でソフトウェアを開発し、次に周波数を下げるアプローチが適すと言えるでしょう。

Config ToolsのUpdate Code

SDKサンプルプロジェクトに何も変更を加えずに、Config Toolsをクリックしても、Update Codeボタンが「緑色」になる場合があります。Update Codeボタンの灰色は、上書きするSDKライブラリが無いことを示します。この場合は、変更を加えていないので、本来「灰色」のハズです。

これは、元々のSDKライブラリが手動生成、または旧Config Toolsで生成していて、IDE付属の最新Config Toolsの上書き版と（機能的には同じでも）異なる場合があるからです。例えば、ライブラリコメントが変わる場合などが相当します。

気になる方は、SDKサンプルプロジェクトを最初にIDEへImport後、直にConfig Toolsを起動し、Update Codeを一度実行しておけば、次回からユーザ変更が無ければ、灰色でボタン表示されます。

新規プロジェクトのConfig Tools

Config Toolsの使い方に本稿では、SDKサンプルプロジェクトのLチカサンプル点滅LED変更を例にしました。この使い方は、MCUXpresso IDEで新規プロジェクト作成時でも同じです。

新規プロジェクト作成時、初めからMCU内蔵周辺回路のSDKドライバを全て実装したとしても、消費（浪費）されるリソースはFlash/RAM容量のみです。周辺回路やクロックルートのほとんどは、Inactiveが初期値で、ActivateはUART0程度です。

そこで、IDE新規プロジェクト作成後、先ずConfig Toolsで使用予定の周辺回路やクロックルートをActivateし、それらに対応したSDKライブラリをUpdate Codeで上書き更新、最後にユーザ処理を記述するという順番になります。

MCUXpresso IDEソフトウェア開発要点

NXPのMCUXpresso IDEは、SDKベースのMCUソフトウェア開発を行います。

SDKには、多くのサンプルプロジェクトがあり、これらを上手く活用すると、効率的で汎用的なMCUソフトウェア開発が可能です。

SDKサンプルプロジェクトは、対象周辺回路とクロックルートのみを動作させる基本に忠実な作法で開発しているため、ユーザがプロジェクトへ変更を加える時、新たな周辺回路のActivateが必要な場合があります。

Config Toolsは、MCU全内蔵回路とクロックルートを、GUIで簡単にActivate/Inactive変更ができ、その結果として、更新の必要があるSDKサンプルプロジェクトのライブラリを上書き更新します。

NXPのMCUソフトウェア開発は、MCUXpresso IDEに備わったSDKとConfig Tools両方の活用が必須で、前稿と本稿の2回に分けてその使い方を説明しました。

MCUXpresso SDKの使い方

2020年7月10日2020年7月22日 WithHappy

NXP MCUXpresso IDEを使ったFRDM-KE02Z40Mテンプレートv2開発にあたり、MCUXpresso SDKベースのMCUソフトウェアの開発方法を示します。

MCUXpresso SDK全般の使い方

MCUXpresso SDKの全般的な使い方は、IDE付属のGetting Started with MCUXpresso SDKやコチラの動画で判ります。どちらも初めてSDK：Software Development Kitを使う時には役立ちますが、具体的にSDKを使ってMCUソフトウェア開発をするにはどうすれば良いのかの説明はありません。

「導入説明だけで活用説明がない」典型例です。

MCUXpresso SDK構造

本稿はソフトウェア開発初心者が、一番知りたいハズだと思うSDKの具体的な使い方：活用の説明をします。SDK全般の使い方：導入説明に関しては、上記リンク先を参照してください。

OpenSDA接続問題

現時点では、FRDM-KE02Z40M（Cortex-M0+/40MHz、5V Robust）のOpenSDAとIDEデバッガ間が接続できない問題があり、代わりにFRDM-KL25Z（Cortex-M0+/48MHz、General Purpose）も使います。FRDM-KL25Zには、接続問題はありません。

※FRDM-KE02Z40MのOpenSDA接続問題は、内容とその解決策を次回以降投稿予定です。

SDK Version

投稿時点のSDK_2.x_FRDM-KE02Z40M（Version 2.7.0）とSDK_2.x_FRDM-KL25Z（Version 2.2.0）が上図です。MCUXpresso IDEへインストールされたSDK Versionが異なることには注意が必要です。

Versionが異なると、SDK提供サンプルプロジェクトやその中身が異なることがあるからです。多くの評価ボードの最新SDK Versionは2.7.0ですので、テンプレートもSDK Version 2.7.0を前提とします。

Hello_worldサンプルプロジェクトと新規作成プロジェクト

Hello_worldサンプルプロジェクト（左）と新規作成Templateプロジェクト（右）

FRDM-KE02Z40Mのhello_worldプロジェクトが上図（左）です。CMSISやboardなど多くのフォルダがあり、その中にcソースファイルと、hヘッダファイルが混在しています。sourceフォルダ内にhello_world.cとmain関数があります。

このsourceフォルダが、ユーザの開発するc/hファイルを格納する場所で、他のboardフォルダなどは当面無視して構いません。New Projectをクリックし新たなプロジェクト（プロジェクト名：Template）を作成すると、この理由が判ります。

上図（右）が新規作成したTemplateプロジェクトです。sourceフォルダ以外は、hello_worldと同じ構造です。sourceフォルダ内のTemplate.c内に、コメント：/* TODO: inset other…　*/が2か所あることも判ります。この青色TODOコメントのソース位置は、ソースウインド右端の上下スライダに青で明示されています。

青色TODOコメントは、ソースコードのユーザ追記場所を示します。

最初のTODOコメントの下にユーザ追記インクルードファイルを、次のTODOコメントの下にユーザ宣言や定義を追記し、main関数内にユーザ処理を追記すればTemplateプロジェクトが完成します。

※main関数内にユーザ処理を追記するのは当然のことですので、main関数内にあるべき青色TODOコメントは、省略されています。

MCUXpresso SDK活用のMCUソフトウェア開発方法

前章までのSDK構造をまとめます。

ユーザが新規に開発（追記）するソース/ヘッダファイルは、全てsourceフォルダ内に配置
IDEが生成したsourceフォルダ＞プロジェクト名.cのユーザ追記場所は、目印として青色TODOコメントがあり、上下スライダにも明示される
sourceフォルダ以外は、IDEがSDK Versionに応じて自動生成するライブラリフォルダ
ライブラリフォルダの中身は、ユーザ編集は不要

SDK付属のサンプルプロジェクトは、SDK構造に基づいてNXPが作成した周辺回路の利用例です。
※サンプルプロジェクトでは、青色TODOコメントは全て省略されています。

MCUが異なっても、同じ処理を行う場合は、sourceフォルダ内のユーザ追記処理も同じハズです。例えば、FRDM-KE02Z40MとFRDM-KL25Zのhello_worldプロジェクト＞sourceフォルダ＞hello_world.cは、全く同じソースコードで実現できています。

MCU差やSDK Version差は、sourceフォルダ以外のSDK構造部分で吸収されます。導入説明：Getting Started with MCUXpresso SDKの図1は、このことを図示したものです。

MCUXpresso SDK Laysers（出典：Getting Started with MCUXpresso SDK, Rev. 10_06_2019） — MCUXpresso SDK Laysers（出典：Getting Started with MCUXpresso SDK）

もちろん、旧SDK Versionで未提供なAPIが、新SDK Versionで新たに提供される場合もあります。ただ基本的なAPIは、新旧SDKで共通に提供済みです。

FRDM-KE02Z40MのSDK VersionとFRDM-KL25ZのSDK Versionは現時点で異なるため、IDEが自動生成するフォルダ数は異なります。しかし、ユーザ開発（追記）処理が、sourceフォルダ内で全て完結するSDK構造は同じです。

これが、hello_worldサンプルプロジェクトのようにFRDM-KE02Z40MとFRDM-KL25Z両方に共通で記述できるユーザ処理（Application Code）がある理由です。

SDK構造に沿ったsourceフォルダへのユーザ処理追記と、基本的API利用により、汎用的で効率的なMCUソフトウェア開発が出来ることがご理解できたと思います。

あとがき

2章で、「具体的にSDKを使ってMCUソフトウェア開発をするにはどうすれば良いのかの説明はない」と書きました。しかし、本稿で示したSDK活用説明は、ソフトウェア開発者は当然知っていること・・・だから説明がないとも言えます😅。

このように組込みMCU関連の資料は、前提とするソフトウェア知識・経験をどの読者も既に持っており、本稿記述の当たり前の活用説明は省略する（≒すっ飛ばす）傾向があります。

弊社マイコンテンプレートは、初心者～中級レベルの開発者を対象としており、提供テンプレートも本稿で示したSDK活用方法で開発します。ご購入者様が、なぜこのようなテンプレートになったのか疑問を持った時、それに答えるため、このすっ飛ばした省略部分を補う説明を本稿ではあえて加えました😌。