OpenSDA接続トラブル解決方法

ブログ読者様のおかげで、不明だった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
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 Block Diagram(出典:ユーザズマニュアル)
FRDM-KL25Z Block Diagram(出典:ユーザズマニュアル)

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

さいごに

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

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

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

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

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に加筆)
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 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
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が安価で数多く出回っていますので、これら活用も一案かと思います。