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

NXPのFreeMASTER

FreeMASTERは、NXP組込みMCUのアプリケーションのリアルタイム変数モニタと、モニタデータの可視化ツールです。関連投稿:STマイクロエレクトロニクスのSTM32CubeMoniterとほぼ同じ機能を提供します。

NXP資料FreeMASTER Run-Time Debugging Tool – Overview を使ってFreeMASTERの特徴を示します。

FreeMASTERとIDEデバッガ機能差

FreeMASTERと、開発者が普段使うIDEデバッガとの差が一目で解る図がP13にあります。

FreeMASTERとデバッガの違い(出典:FreeMASTER Run-Time Debugging Tool – Overview)
FreeMASTERとデバッガの違い(出典:FreeMASTER Run-Time Debugging Tool – Overview)

両者の機能境界が、ソースコードのデバッグ機能です。IDE(MCUXpresso IDE)でも変数ロギングやグラフ化機能はありますが、プログラム開発者向けの最低機能に絞ったものです(limited functionality)。

これに対し、FreeMASTERは、msec分解能のグラフ化と、μsec分解能のデータ取得が可能です。更に取得データを利用し、Field-tune parametersやRemote controlなど多くの機能を持つツールです。データの取得は、MCU実装のUARTやUSB、SWD経由です。

FreeMASTERを使うと、外付け制御パネルの代替やGUIアプリケーションとしても活用できます。例えば、下図のようなモータ制御パネルが、PC上でFreeMASTERソフトウェアのみで実現できる訳です。

FreeMASTERを使ったモータ制御パネル例(出典:FreeMASTER Run-Time Debugging Tool – Overview)
FreeMASTERを使ったモータ制御パネル例(出典:FreeMASTER Run-Time Debugging Tool – Overview)

 FreeMASTER構成

Windows PCにおけるFreeMASTER構成がP20です。詳細は、P21~25に示されています。Linux PCでの構成は、P26に示したFreeMASTER Liteが使われます。

FreeMASTER Windows PC構成(出典:FreeMASTER Run-Time Debugging Tool – Overview)
FreeMASTER Windows PC構成(出典:FreeMASTER Run-Time Debugging Tool – Overview)

MCU開発トレンド:ビジュアル化と脱Windows

組込みアプリケーションのビジュアル化は、最近のMCU開発トレンドです。

MCU本体の性能を使わずに変数データを取出し、そのデータを高性能PCとプラグイン機能を利用し、データ可視化やリモート制御を実現します。本稿で紹介したNXPのFreeMASTERやSTのSTM32CubeMoniterがこのトレンドをけん引する技術です。

また、オープンソースLinux PCへのMCU開発環境移行や各社IDEマルチプラットフォーム化、つまり脱Windowsもトレンドの1つです。

上級開発者向けというイメージが強かったLinux PCですが、一般ユーザへも普及し始めました(Wikipediaより)。筆者も昨年から、MCU開発Main-PCのWindows 10とは別に、Backup-PCにLinux Mintを新規インストールし試用中です。

半年間の試用では、OSインストール、大型/定期更新、セキュリティに関してもLinux Mintの方が、Windows 10より安定感があります。

もはや現状のWindows 10では、信頼性があったWindows 7のレベルにはならない気がします。

既存Windows 10に手を加えるよりも、新OSを開発するほうが、早道で、安心してPCを利用したい一般ユーザ要求も同時に満たせるのではないでしょうか? 商業的理由は、セキュリティ対応強化とすれば、内容不明ながら大多数の納得も得られるでしょう。※あくまで、ソフトウェア開発経験者個人の見解です。

NXP新CEO Kurt Sievers氏

2020年5月28日、蘭)NXPのCEOがリチャード・L・クレマー(Richard L. Clemmer)氏から、カート・シーヴァーズ(Kurt Sievers)氏への交代発表がありました。こちらのEE Times記事に新CEOカート・シーヴァーズ氏の経歴や、米中貿易摩擦下でのNXP中国分析などが示されています。

欧州MCUベンダNXPのアフターCOVID-19への布石、さすがに早いです。