NFC CockpitのExtraタブにある「Load Secondary Firmware」オプションからNfcrdlib_SimplifiedAPI_EMVCo_Secondary.nnc.binをロードした後、PNEV5190Bが反応せず、NFC Cockpitから操作できません。
アップデートログによると、ファームウェアのダウンロードはエラー報告もなく正常に完了しました。アップデートが完了した後、ボードが応答しなくなった。
このスレッドで似たような問題を見つけましたが、根本原因を理解したいです。
ファームウェアのアップデートが成功したにもかかわらず、なぜ基板が反応しなくなるのでしょうか?
私のボードまたはファームウェアのバージョンに対して、間違ったセカンダリファームウェアイメージを使用した可能性はありますか？
なぜセカンダリファームウェアをロードすると、NFCコックピットがボードと通信できなくなる状態になるのでしょうか?
再開まで今しばらくお待ちください。
こんにちは、 @Miyazaki001さん
あなたの調子が良いといいのですが。
あなたのセットアップについてもう少し詳しく教えていただけますか?どのような手順に従っていますか？
私は以下の設定を試してみました。
- PNEV5190B
- FW v2.0B
- NFC Cockpit v9.0.0
- 「追加」タブ > 「セカンダリファームウェア」タブ > セカンダリファームウェアのロード
- NxpNfcCockpit_v9.0.0.0\firmware\Secondary_PN5190\K8x\Nfcrdlib_SimplifiedAPI_EMVCo_Secondary.nnc.bin を選択してください
NFC Cockpitは、COMポートを閉じてから再度開くように指示するはずです。
COMポートを再度開いた後、「Extra」タブでセカンダリファームウェアを起動できるようになります。
よろしくお願いいたします。
エドゥアルド。
こんにちは、@EduardoZamora さん。
ご返信よろしくお願いします。
私のシステム構成は以下のとおりです。
- PNEV5190B（B1チップ）
- PN5190 FW v02.05
- NFC Cockpit v7.4
- 追加タブ → セカンダリファームウェア → セカンダリファームウェアのロード
選択済み:
-NxpNfcCockpit_v7.4.0.0\firmware\Secondary_PN5190\K8x\Nfcrdlib_SimplifiedAPI_EMVCo_Secondary.nnc.bin
二次ファームウェアアップデートは正常に完了したようです。ログによると、ファームウェアのダウンロードはエラー報告なしに完了した。
ログの該当箇所を以下に示します。
アップデート後、NFC Cockpitからボード接続を手動で閉じてから再度開くように指示されます。私はこの手順に従い、さらにCOMポートを手動で切断して再接続することも試しました。
しかし、接続を再開した後、ボードはどのコマンドにも応答しなくなった。ログには、NFC Cockpitがボードとの通信を試みた際にタイムアウトが発生したことが記録されている。
参考までに、関連するログファイルを添付しました。
何かアドバイスをいただけますか:
PN5190 FW v02.05は、このセカンダリファームウェアと互換性がありますか？
NFC Cockpit v7.4とこのセカンダリファームウェアに関して、既知の問題はありますか？
このスレッドで似たような問題を見つけましたが、根本原因を理解したいです。
再開まで今しばらくお待ちください。
よろしくお願いいたします。
こんにちは、
この特定のセットアップで予期せぬ挙動が記録された例を見つけることはできませんでした。
NFC Cockpit v7.4.0は旧バージョンです。最新バージョン（v9.0.0）にアップデートし、PN5190のファームウェアアップデートを実行してください。その後、あなたの調査結果を教えてください。
設定を更新した後もこの症状が続く場合は、ジャンパーの設定と電源接続についてお知らせください（基板の写真も添付していただけると助かります）。
よろしくお願いいたします。
エドゥアルド。
こんにちは、@EduardoZamora さん。
ご返信よろしくお願いします。
お客様からのご意見に基づき、NFC Cockpitのバージョンを最新バージョンであるv9.0.0に変更いたしました。また、PN5190のファームウェアをv02.05からv02.0D（NXPのウェブサイトで入手可能な最新バージョン）にアップデートし、セカンダリファームウェアのアップデートを再試行しました。
しかし、結果は同じで、問題は依然として解決されていない。
参考までに、ボードの写真も添付しました。
以下のジャンパー設定が使用されます。
J8：閉鎖
J9：2-3（外部電源）
J12：閉鎖
J22：閉鎖
J23：閉鎖
このテストでは、電流制限が1Aの外部5V DC電源を使用します。
他に確認すべき設定や項目があればお知らせください。
こんにちは、
ジャンパー設定と電源構成は問題ないようです。
もしかして、デモ用のアプリケーション(例:)をフラッシュして実行することはできますか?PN5190の NFCリーダーライブラリ で提供されているDiscoveryLoop?詳細 PNEV5190B評価ボードクイックスタートガイド、第5.3章を参照してください。
追加のテストとして、別のPCとシステム言語(ディスプレイだけでなく)を英語に設定してみていただけますか?
よろしくお願いいたします。
エドゥアルド。
こんにちは、
評価ボードのクイックスタートガイドのセクション5.1 PNEV5190B述べているように、最新のNFCコックピットを使用してファームウェアの最新バージョンにアップデートすることが推奨されています。ファームウェアプログラミングには外部デバッガが必要であり、 これはNXP NFCコックピットユーザーガイド3.3節に記載されています。
残念ながら、ブートローダーバージョンとセカンダリFWバージョン間の正式な互換性マトリックスを提供する文書は存在しません。最も近い参照は 、VCOMソースパッケージ 内の バージョン変更ログ(NxpNfcCockpit_VCOM_UcBalFW\NNC_UcBalFW\phUcBal\src\NNC_uC_VCOM_Ver.h)です。
よろしくお願いいたします。
エドゥアルド。
こんにちは、@EduardoZamora さん。
ご返信よろしくお願いします。
ご提案いただいた方法を別途試してみます。
その間、弊社側でも追加のテストを実施し、以下の結果を得ました。
まず、J-Linkを介してNFC Cockpit v9.0.0に付属する以下のファームウェアをプログラムしました。
BootLoader_And_Nfcrdlib_SimplifiedAPI_EMVCo_Secondary.bin
その後、NFC Cockpitを使用して以下のセカンダリファームウェアをアップデートしました。
Nfcrdlib_SimplifiedAPI_EMVCo_Secondary.nnc.bin
この手順により、以前発生していたエラーは発生せず、アップデートは正常に完了しました。
この結果に基づき、ブートローダーとセカンダリーファームウェアのバージョン間に互換性の依存関係が存在する可能性があると推測されます。
以下の点について説明していただけますか?
1.NFC Cockpitのバージョンを変更する場合、セカンダリファームウェアだけでなく、ブートローダーも互換性のあるバージョンにアップデートする必要がありますか？
2. NFC Cockpitを使用してブートローダーをアップデートする方法はありますか？
それとも、ブートローダーをアップデートするには、J-Linkのような外部デバッガー／プログラマーが必要なのでしょうか？
3. 各NFCコックピットバージョンに付属するセカンダリファームウェアとブートローダーの互換性を説明するドキュメントはありますか?
例えば、どのバージョンのセカンダリファームウェアが同じブートローダーで使えるか知りたいです。
これらの疑問の背景には、私たちが解決したいと考えている別の問題も存在します。
私たちはNFC Cockpitではなく、COMポートを通じたシリアル通信を使って自社のアプリケーションからPNEV5190Bを制御しています。
NFC Cockpit v7.4.0に付属するセカンダリファームウェアを使用すると、アプリケーションはPNEV5190Bと正常に通信し制御できました。
しかし、NFC Cockpit v9.0.0に含まれるセカンダリファームウェアにアップデートした後、同じ通信方法で同じアプリケーションが通信エラーに遭遇します。
次の点についても説明していただけますか?
4. NFC Cockpit v7.4.0とv9.0.0に付属するセカンダリファームウェアの間で、初期化シーケンス、COM通信設定、通信プロトコル、コマンド仕様、または関連する動作に関して変更点はありますか？
これらの変更を説明したリリースノートやドキュメントがあれば、ぜひ共有していただけるとありがたいです。
こんにちは、
VCOMファームウェアは、弊社のNFCコックピットツールとの併用を想定しています。別のツール用のカスタム実装を作成しようとしている場合は、 NFC Cockpit VCOMのソースコードを参考にして、ニーズに合わせて修正することを検討してください。
よろしくお願いいたします。
エドゥアルド。
こんにちは、@EduardoZamora さん。
ご説明いただきありがとうございます。
ブートローダーを含むファームウェアのプログラミングには、外部デバッガーが必要であることを理解しています。また、BootLoaderとセカンダリファームウェアのバージョン間には正式な互換性マトリックスがなく、VCOMソースパッケージ内のバージョン変更ログが最も近い参照であることも理解しています。
他に言及した問題については、BootLoaderとセカンダリファームウェアをNFC Cockpit v9.0.0.0に更新した後、アプリケーションが正しく通信できなくなったため、追加調査を行い、DTRの取り扱いに関する違いを発見しました。
念のため説明すると、 私たちのアプリケーションは以前、NFC Cockpit v5.3に含まれるBootLoaderとセカンダリファームウェアを使って動作しており、v7.4ではありませんでした。
NFC Cockpit v5.3にBootLoaderとセカンダリファームウェアが付属しているため、COMポートを開いた後もDTRを静的にONに保つだけで、DTRの状態移行を明示的に行わずに正常に通信できました。
しかし、NFC Cockpit v9.0.0.0 に含まれる BootLoader と Secondary Firmware では、DTR を ON にするだけでは不十分です。ボードは、DTRをLOWからHIGHに明示的に切り替えた後にのみ応答を返すことがわかりました。この移行は、通信セッションの開始時に少なくとも一度は必要となるようだ。
Wiresharkを使用してUcBalPCTestApp.exeによって生成されたUSB通信をキャプチャおよび分析することにより、このDTR操作を特定しました。
以下の点について説明していただけますか?
PN5190 VCOM ファームウェアにおいて、DTRのLOWからHIGHへの遷移は、通信セッションの初期化や内部バッファプロセッシングなどの内部プロセッシングのトリガーとして使われていますか?もしそうなら、この挙動はどこかで記録されていますか?
VCOMファームウェアのバージョン間で、このDTRの動作が変更された可能性はありますか？特に、NFC Cockpit v5.3とv9.0.0.0に含まれるバージョン間で、DTR処理に関して何か変更はありましたか？
ホスト側でDTRをLOWからHIGHに明示的に切り替えることなく通信を開始するための、公式に推奨されている方法はありますか？例えば、特定のIOCTL、ベンダー固有のコマンド、またはその他のメカニズムなどです。
改めてサポートありがとうございます。
よろしくお願いいたします。
こんにちは、@EduardoZamora さん。
ご説明とサポートありがとうございます。
NFCコックピットとアプリケーションの両方で同じセカンダリファームウェアを使いたいと考えています。
したがって、NFCコックピットVCOMのソースコードを参照し、現在のVCOMファームウェア動作をサポートするようにアプリケーションを修正します。
改めてサポートありがとうございます。
よろしくお願いします、
宮崎