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

モダンPCとPINコード

2019年12月27日2020年10月29日 WithHappy

本稿が2019年最後の投稿です。

前稿Windows 10 2PCトラブルにもめげず、2020年1月6日発売のCypress PSoC CapSenseテンプレートに向けて急ピッチで開発を進めてます。本稿は、Windows 10トラブルで気になったモダンPCと、公開鍵暗号方式PINコードを紹介します。

モダンPC

創造性と生産性を上げるのがモダンPCで、Windows 10とOffice 365がその要素のようです。

Windows 7サポート終了2020年1月14日を前に、MicrosoftはモダンPCへの移行を呼びかけています（Windows 7稼働予測グラフ有り）。今でもネットカフェで稼働中の多くのWindows 7 PCは、果たして安定性・メンテナンス性に問題あるモダンPCへ移行するのでしょうか？

Windows 7並みの信頼性が無ければ、宣伝文句は良くてもPCのOSとしては、どうかな？と個人的には思います。
2023年までのWindows 7有償再延長サポートも選択肢としてあるので、7を使い続け、開発者よりも一般エンドユーザを重視する次期Windows Xに期待する声も少なくないかもしれません。

筆者は最新OSの最重要機能は、セキュリティだと思います。

Windows 10付属セキュリティツールだけで安心しているエンドユーザが、どれ程いるかは解りません。しかし、多くのネットカフェが設定するWindows 7＋市販セキュリティソフトとのOSセキュリティ能力差が、どれ程あるかも不明です。

2020年以降のWindows 7稼働予測と、モダンPCへの移行状況が、Microsoftの思惑通りになるか気になります。

PINコード

Windows 10インストールで新たに要求されるPIN（Personal Identification Number）コードは、個人識別番号のことです。普通、数字4桁です。

PINコードは、IDとパスワードの代わりに登場してきたセキュリティ用語で、筆者の理解では、PINコードが公開鍵暗号方式、パスワードは秘密鍵暗号方式です。PINコードとパスワードの解り易い違いは、コチラのP1図です。

通信中の鍵が公開鍵なので、秘密鍵パスワードよりも安全で、公開鍵とペアの秘密鍵は、デバイス（Windows 10/MCUなど）内部保存、開発コストや運用コストが低く、強固なセキュリティが実現できるそうです。ペア秘密鍵がデバイス内なので、なりすまし対策にもなります。

PIN、FIDO（ファイドと読む）で検索すると様々な情報が得られます。iPhoneは少し違うようですが、AndroidスマホではPINコードが標準になりつつあるようです。

筆者のWindows 10は、前投稿トラブル回復直後のため、テンプレート開発以外は、今のところあまり手出し（調査）したくない心境です。簡単、安心、低コスト、セキュリティ強固なPINコードなら、MCUへも実装できるかもしれません。

…以上のように今年最後の本稿は、あいまいな推量となりました。
安心してPCが使えるまでは、最高プライオリティ：CapSenseテンプレート開発を優先したいからです。すいません😌。

本年も本ブログをご覧いただき、まことにありがとうございました。
皆さま、よいお年をお迎えください（Ladies and gentlemen, I wish you a happy New Year）。

Windows 10 1909トラブル回復録

2019年12月20日2020年10月29日 WithHappy

年末年始の忙しい時に限って自作Windows PCにトラブルが発生するのは、日頃の行い、またはマーフィーの法則？

Backup PC（Windows 10 1903）のWindows 10 1909アップデートトラブルに続き、Main PC（Windows 10 1909）にもWindows起動トラブルが発生しました。Backup PCトラブルは、暫く様子見でも良いと考えていましたが、Main PC起動トラブルは、即回復が必要です。

Windows 10トラブル内容

Backup PCは、Windows 10 1903から1909への更新プログラムインストールに失敗するトラブルです（0x800F0922）。1903からの新機能追加も少ない1909への更新は、Backup PCのため急ぐ必要はありません。この更新失敗トラブルは少なくないようで、ネットに多くのトラブル対策があります。更新プログラム直接インストール、クリーンブードも既に試しましたが回復しません。

Main PCは、突然起動NGになりました。きっかけは、複数アプリケーション更新と更新履歴消去です。Boot起因ですので、自動修復やコマンドプロンプト手動修復も試しましたが回復しません。唯一の救いは、1909更新成功直後のシステムバックアップがあることです。

トラブル回復策

Main PCは、11月14日の1909更新直後のシステムリカバリで回復しました。但し、今回の起動トラブル発生までの約1か月間のユーザデータ更新とアプリケーションソフト更新が必要で、このために半日がつぶれます。また、Backup PCは、その症状から「最後の切り札」：1909クリーンインストールが必要かな？と感じていました。

そこで、Main PCでつぶれる半日で並列にBackup PCをクリーンインストールしようと決心した訳です。Main PCのアプリケーション更新時、Backup PCへのインストール必須アプリケーションも明確になります。退屈な回復作業ですが、PCの前から離れる訳にもいきません。2PC同時に回復することで、効率向上も狙えるかなと考えました。

トラブル回復作業と時間

ネットに溢れる回復作業内容よりも、作業に要した時間を示します。

もちろんPC性能やネットワーク環境で分単位精度は変わるでしょう。半年毎に繰返されるWindows 10更新トラブル対応の目安と考えてください。作業時間は、2PC回復トータルで丸1日程度です。が、精神的ダメージはかなりあります。Windows10更新トラブルがこのまま続くなら、Mac PCへの乗換を検討する程のダメージです。

Backup PC Windows 10 1909クリーンインストール作業時間

Windows 1909クリーンインストール：10分（Microsoftアカウントに加え、新たにPINコード入力要求）
クリーンインストール後のセットアップ：5分（OSセキュリティ内容などを設定）
セットアップ後の更新プログラム適用：40分

最新Windows 10 1909クリーンインストール自体は、上記1時間程で完了します。これなら、毎回クリーンインストールしても良いと思える程簡単です。が、この後のアプリケーションインストール、ユーザデータ復活に時間が掛かります。

セキュリティソフト、ブラウザ、FFFTP、圧縮解凍などOS必須ツールインストール：1時間
Officeアプリケーションインストールと更新プログラム適用：3時間
ベンダMCU開発ツールインストール：1時間
ユーザデータ復活：1時間（クラウドストレージ経由ではなく回復Main PCより直接コピー）

合計で7時間～8時間（＝丸一日）は、モニタ前で待たされます。並列で行ったMain PC回復作業も、システムリカバリと1か月間のユーザデータ復活で3時間程度です。Office（2010）アプリケーションインストールと更新は、LibreOfficeに比べ時間が掛かります。新しいOffice 2019/2016でも、同様に時間が掛かると思います。

※アプリケーションとユーザデータを引継いだままWindows 10 1909上書きインストールも可能です。しかし、Backup PCは、この上書きインストール（1.5時間）も失敗しました。更新プログラム直接インストール、クリーンブードと同様、「最後の切り札」より前の回復手段は、経験上あてになりません😫。

いろいろある回復手段を試して消費する合計時間と、「最後の切り札」で一発回復する上記8時間のどちらを選ぶかは、トラブル種類と回復作業内容・処理時間、個人の性格に依存します。本稿が参考になれば幸いです。

ビジネスPC要件

今回のトラブルで、筆者のWindows PCには、Mac PCへの乗換を妨げる利用アプリケーションは無いことが明確になりました。利用アプリケーション全てMac OS対応、または同等アプリケーションが有ります。

ビスネスPCのOSは？ — 信頼性重視ビスネスPCのOSはWindows、Mac、Unixのどれが良いか？

Mac PCの方が高性能なのでWindows PCより高価です。従って、このMac PC対Windows PC差額を払う分だけの信頼性が得られるか、費用対効果が乗換課題です（もちろん、経済的余裕と自作PCの楽しさが消えるのもありますが…）。

Backup PC、Main PCともに自作Windows PCですが、今回のようなOS起因トラブル無しで何年も動作し続けたPCです。ネットを見ると、Backup PCと同じ更新トラブルは、2019年最新WindowsノートPCでも発生しているようです。

以前のOS、特にWindows 7に比べ世間を騒がせるWindows 10更新トラブルは、Windows 10完成度・信頼性が低いとエンドユーザに感じさせるだけでなく、Microsoftの狙いは、OS更新毎に毎回Windowsをクリーンインストールさせ、アプリケーション本体は、Office 365のようにクラウド提供することが目的なのでは、という疑いを生じさせます。
OSクリーンインストールが短時間で簡単に終わり、OfficeアプリケーションのローカルPCインストールと更新にやたら時間が掛かることが根拠です。

ビジネスで使うPCは、Mac PC（Unixも含む）への乗換を考えるべき時期かもしれません。今後、Mac PC/OSのトラブルや回復方法も調べたいです。

ユーザ目線Windows 10 1903更新方法

2019年6月3日2020年10月29日 WithHappy

Windows 10サポート期限は、年2回の大型更新後、1年と半年です。つまり、1809なら2019年末まで。2020年1月14日のWindows 7に比べ超短期です。Windows 10ユーザは、大型更新1903 May Update（19H1）への対応は必須なのです。

前回の1809更新トラブルをまぬかれた筆者を含むラッキーなWin10ユーザが、今回の1903更新をどのように乗り切るかについて私案を示します。

3つの1903更新方法

Microsoftは、前回1809更新一斉配布→トラブル頻発の反省から、今回1903は、段階的配布に変えたそうです。それでも、前回同様、1903も重大な更新トラブルの記事、情報が多くあります。

関連投稿：LibreOffice最新版6.2.4更新のWindows 10 May Update章

この段階的配布により、いつ始まるか判らない自分のPCの1903更新への対応法は、3つあります。

主体的に1903更新開始：例えば開発が一段落したなどユーザの都合が良い時に、ユーザ自身で1903更新を開始
受動的に1903更新受付：1903更新開始は、PCにお任せ、ユーザもそれに従う。多くの記事で推薦。
受動的に1903更新受付、更新延長の場合あり：1903更新の開始は、PCにお任せ。但し、ユーザの都合が悪い場合は、一時的に1903更新を延長

1：主体的に1903更新開始

1903段階的配布の目的は、徐々に明らかになる更新トラブルに対する策を、Microsoftが通常のUpdateで大型更新前に実施し、トラブル発生頻度を少なくすることです。多くの記事が、1903更新をひたすら待てというのは、Microsoftのこの意図を汲んだ結果です。

従って、主体的に1903更新の開始をする時は、更新トラブルの覚悟が必要です。方法は、「何回か更新プログラムのチェック」を押すことです。これにより主体的更新をMicrosoftが検知し更新が始まります。

ユーザメリットは、当然事前にシステムバックアップをしており、万一のトラブルが発生しても自己責任なので精神的に安定して回復できることです。トラブル発生時には回復し、2または3の選択肢となります。

2：受動的に1903更新受付

朗報です。1903からは、Homeユーザでも最大35日の大型更新延長が可能になったそうです。この機能は、次の大型更新後にその効果が明らかになるでしょう。

しかし、現行の1809 Windows Homeユーザには、大型更新延長機能がありません。例えユーザ都合が悪くても、開始した1903更新を受入れる以外に手はありません。

段階的配布で自分のPCの順番が来るのを待ち、トラブルが無い1903更新完了を祈りましょう。

3：受動的に1903更新受付、更新延長の場合あり

1809 Windows Pro以上のユーザが取りえる現在最も大型更新のトラブルリクスが少ない可能性がある方法です。

大型更新を延長する方法は、「更新開始前」に、Windows Updateの下記詳細オプションを設定します。

大型更新の延長設定（1809 ProのWindows Update詳細オプションデフォルト状態）

赤枠、これは更新インストールの制御であって、更新プログラムはPCへダウンロードされます。一方、橙枠の一時停止は、更新プログラムも再度ダウンロードする必要があります。どちらも、自分のPCに段階的配布順番が回ってきたのは同じですが、橙枠は、再び更新プログラムの配布を待たねばなりません。

いずれも、PCの通知アイコンや、いつもと違う大型更新プログラムダウンロード中の挙動にユーザが気づく必要があります。忙しくてこの挙動に気が付かずにいると、何らかのトラブルが発生する可能性もあります。

その理由は、上記更新延長機能を確かめた記事、情報が見当たらないからです。これらユーザに嬉しい機能はあっても、本当に機能するかは確かめようがありません。

1903大型更新リスクとまとめ

対応案	更新トラブル発生確率	トラブル時のユーザ精神安定度
1. 主体的に1903更新開始	＋＋＋	＋＋＋
2. 受動的に1903更新受付	＋	＋
3. 受動的に1903更新受付＋延長	＋＋	＋＋

色々な記事、情報が言うように、受動的に1903更新開始を待つのが大型更新トラブル回避としては、得策なようです。次回、秋の大型更新よりも前までに1903更新完了を待てる方は、リスクが少ない2の対応が良いでしょう。

ちなみに、1903更新でユーザが得られる新機能として筆者が良いなと思うのは、マウスポインタの大きさが大きくなるくらいですが…。

但し、ベンダ純正PCであっても事前にあらゆる組合せに対するトラブル回避策を施すことは不可能です。例えば、自作組込みPCや後付けパーツを組み込んだ純正PCなどに対しては、2や3の対応でもトラブル発生の可能性は、1と大差なしと言えるかもしれません。

更新開始を待ったのに運悪く2や3の対策でも更新トラブルになった時、回復できるバックアップがどの時点のものかが重要です。最悪イニシャルに回復するしかない場合、インストールしたアプリケーションやそれまでのユーザデータは無になります。時間的、精神的にも、かなりの負担です。

更新開始タイミングが主体的な1の対応のみが、最悪イニシャルを避ける策でしょう。

結局、頻繁なシステムとユーザデータバックアップのみが、大型更新トラブル回避策だと筆者は思います。更新開始を主体的にするか、受動的にするのかは、トラブル発生時の精神的な影響に差を生むのみだと思います。

1903 May Updateをどのように乗り切るかについて私案を示しました。筆者自身、どの策にするか未定ですが、ご参考になれば幸いです。