2407772_ja-JP

Yes

MCXW716C: BOOT_CONFIGとSWDメールボックス経由でISPモードへの移行が確認されているにもかかわらず、ISP UARTが応答しない

概要

MCXW716CMFTA （48ピン、NXP評価ボードではありません）をベースにしたカスタムボード上でBLEを起動しようとしています。BLEの例をビルド・フラッシュする前に、まずNBUファームウェアをアップデートする必要があります (

mcxw71_nbu_ble_hosted.sb3

) 標準の「FRDM-MCXW71 入門」フローに従って ISP 経由で。ISPのUARTインターフェース(LPUART1)は、

Blhost

とはいえ、私は今、2つの全く独立した方法で、チップが何らかの制限された/ISPのような状態に入ることを確認しました。UART側が沈黙している理由、あるいはNBUイメージを書き込むためのサポートされている代替手段があるかどうかについて、何かご存知でしたら教えていただけると幸いです。

設定

チップ：MCXW716CMFTA（48ピン）、カスタムPCB

SDK/ツール:MCUXpresso Secure Provisioning Tool v25.06、SPSDK 3.0.1 (バンドル済み)

Blhost

/

nxpdevscan

/

nxpdebugmbox

）

デバッグプローブ:MCU-Link(PyOCDバックエンド)、ボードのJ4ヘッダーにSWD経由でコネクテッド — 一般的なデバッグアクセスで動作確認済み

USB-UARTアダプタ：DSD TECH SH-U09C5（純正FTDI FT232RNL）、ロジックレベル3.3Vに設定

ISPピンマッピング（AN14802表7参照、MCX W71/W72で同一であることが確認済み）：

BOOT_CONFIG = PTA4

LPUART1 ISP RX = PTC2 (ALT3)

LPUART1 ISP TX = PTC3 (ALT3)

カスタム基板では、これらのテストポイントはTP7（PTA4）、TP26（PTC2）、TP43（PTC3）を介してアクセスできます。

兆候

blhost -p COMx -- get-property 1

（そしてMCUXpressoセキュアプロビジョニングツールの「接続テスト」も）常に失敗します。

SpsdkNoDeviceFoundError: 与えられたインターフェース「uart」およびパラメータ「port=COM5, timeout=5000」のデバイスは検出されませんでした。

nxpdevscan -vv

mbootのpingバイトを表示します

[0x5A, 0xA6]

3回送信され、それぞれに続いて

SPSDKTimeoutError

そしてSDPへのフォールバック

読み取りステータス

タイムアウトするコマンド（

SdpConnectionError

)対象者からは一切応答がない。

私が既に除外したもの

配線の極性（両方の向きを試しました）

電圧レベル：TP7、TP26、TP43はすべて定常状態で3.3Vを示します。

アダプター/ドライバー:本物のFTDI、デバイスマネージャーで「正常に動作」が確認、COMポートが存在します

フロー制御（ループバックテストにより「なし」と確認済み）

別のアプリケーションによるポートロック

実際のハードウェア欠陥として、PTC3(ネット「WPT2_Drive_EN」)が0オーム抵抗を介して、ワイヤレス・パワー転送コイルドライバ用の4 LTC7068 DC/DCコントローラのENピンに直接負荷がかかっていました。これにより、TP43のアイドル時の高レベルが約2.3Vまで低下した。この抵抗器を取り外したところ、TP43が3.3Vで正常にアイドル状態になることを確認しました。これは確かにバグでしたが、ISP通信の障害は解決しませんでした。

PTC2ネット（当社のボード上の「POWER_SW」ボタン入力と共有）へのロード：回路図をトレースし、このネットにプルアップ/プルダウン/RCフィルタリングがないことを確認しました。

PC→ボード方向が正しく動作することを確認するための物理的な検証

USBアダプターには、送受信状態を示すLEDが内蔵されています。その間

blhost get-property

試み：

TXD LEDが3回点滅し、3回のping再試行に一致します。

nxpdevscan -vv

— PCが実際に送信していることを確認する。

RXD LEDが点灯しないということは、基板が何も送信していないことを示しています。

同じテスト中にTP26（PTC2）でオシロスコープでキャプチャした波形は、合計時間（約350µs）が57600ボーのUARTバイト2つが連続して送信される際の予想されるタイミングと一致しており、pingバイトが実際に電気的にピンに到達したことを示しています。

新たな発見:ISPモードのエントリーは2つの独立した方法で成功しますが、UARTはどちらの場合も死んでいます

使用

nxpdebugmbox

(同じMCU-Linkプローブ経由でSWD)を使い、ISPモードに入る全く別の方法を2つ試しました。

方法A — 物理的なBOOT_CONFIGピン: 電源を入れる瞬間にTP7(PTA4)をVDDにジャンパー接続し、フル電源サイクル(USBを完全に切り抜いて再接続)を行いました。

方法B — SWD/デバッグメールボックス、ピンストラップなし:

nxpdebugmbox -i pyocd cmd -f mcxw716c start nxpdebugmbox -i pyocd cmd -f mcxw716c ispmode -m 1

どちらのコマンドも成功を報告しています（「デバッグメールボックスの開始に成功しました」／「ISPモードへの移行に成功しました」）。

どちらの場合も、直後に、

blhost -p COMx -- get-property 1

それでも返される

SpsdkNoDeviceFoundError

どちらの方向でもUARTからの応答は一切ありません。

また、以下の点にも留意すべきです。

nxpdebugmbox mem-tool test-connection -d debug_port

通常の起動状態とBOOT_CONFIGが保持されている状態の両方で成功します。しかし

mem-tool read-memory -a 0x0 -c 16

通常ブート中に成功(アプリケーションのベクターテーブルを返す)が失敗します。

SPSDK:メモリアクセスポートが見つかりません!

BOOT_CONFIGが保持されている間、つまりBOOT_CONFIGが主張されるとチップのデバッグやメモリアクセスの設定に何か変化がありますが、なぜUARTが沈黙を保つのかは説明できません。

質問

BOOT_CONFIGピンとSWDデバッグメールボックスの両方でISPモードへの移行が成功したことが確認されたため、

ISPモード

コマンドで、LPUART1 ISPインターフェース(PTC2/PTC3、ALT3)が標準のmbootpingに反応しない既知の理由はありますか?

UART ISPインターフェースが有効になるための追加の前提条件(クロック構成、チップリビジョン固有の動作、ライフサイクル状態の制限など)はAN14648/AN14802でカバーされていないものはありますか?

代替案として：SWD/Debug Mailbox 通信は完全に機能するため（

接続テスト

そして、

メモリ読み出し

通常の動作中に成功し、NBUファームウェアを書き込むためのサポートされている方法はありますか（

mcxw71_nbu_ble_hosted.sb3

ターゲットとする

ラジオフラッシュ

0x48800000) で UART ISP ではなく SWD/Debug Mailbox 経由で実行しますか？MCUXpresso Secure Provisioning Tool の MCXW716C のターゲット定義には、

「接続」: [「uart」]

— SWD ベースのプロビジョニング

ラジオフラッシュ

可能

nxpdebugmbox

/

nxpimage

もしそうなら、手順はどうなっているのでしょうか?

「Xの本当の根本原因はこれです」とか「代わりにSWD経由でNBUをフラッシュする方法はこれです」といったヒントでも構いませんので、ご提供いただければ大変ありがたいです。必要であれば、追加のログやスコープキャプチャを提供いたします。

Re: MCXW716C: ISP UART unresponsive despite confirmed ISP-mode entry via BOOT_CONFIG and SWD mailbox

こんにちは、 @chocola_saka さん。お元気でお過ごしでしょうか。

既にヒューズを焼損させてしまったかどうか、確認させてください。もしそうなら、どの作品かを明確にしてください。これは重要です。なぜなら、ヒューズ17にはISPパスを無効にする機能があるからです。

さらに、この現象が発生する前にIFRのセクター0に何らかの設定を書き込んだことがあるかどうかをお知らせください。このセクターはROMブートとISP設定専用です。

以前にNBUをボードにロードできましたか？

また、SWD経由でNBUをロードするという質問については、 AN14397 - 大量生産中のシリアルワイヤーデバッグによるMCXW71フラッシュのアプリケーションおよび無線ファームウェアのプログラミングを参照することをお勧めします。アプリケーションバイナリをNBUファームウェアにマージし、最終バイナリをSWD経由で読み込むためのガイドを提供します。

ご依頼いただいた情報と、共有した資料がお役に立てたかどうかをお知らせください。