皆さんこんにちは、もうアイデアが尽きてしまったので助けていただけると嬉しいです...
PN5190B1HN/C121E(ホスト:CC1352 MCU over SPI)を搭載したカスタムボードを持っています。新生産ロット(約100台)では、約75%の故障率が示されています。RFフィールドが初めてオンになった瞬間にSPIで応答しなくなり、VENリセット後にのみ回復します。前のロットのユニット(プロトタイプ5個)は同じデザインとBOMで正常に動作します。測定結果から、アンテナ/マッチング、送信機のショート、静的電源、SYS3Vの電圧低下、チップのファームウェア、シリコンロットの問題は除外しました。我々は、確認済みの根本原因、考えられるシリコンの不具合、または見落としている可能性のあるEEPROM/電源構成を探しています。
ハードウェア
- NFCフロントエンド：PN5190B1HN/C121E — GetVersionレポートによると、HW=0x52、ROM=0x02、FW=0x0201です。
- TX電源＝内部TX_LDO。VUP_TX（ピン6）= 3.3V（LDO入力）。VDDPA（ピン9）＝TX_LDO出力（GNDのみにデカップリング）。VBAT / VBATPWR = 3.3 V。内部DC-DCコンバータは使用されていません（BOOST_LXインダクタは取り付けられていません）。
- メインレールSYS3V = TPS62840降圧コンバータ（最大0.7A）からの3.3V。
- 27.12 MHz水晶発振子（村田製作所製 XRCGB27M120F3M00R0）。
- DPCは無効になっています。ULPCD（超低消費電力カード検出）を使用。VDDPAを最小値に設定（TX_LDO_VDDPA_HIGH/LOW、EE 0x06/0x07 = 0x00）。
- 差動アンテナTX1/TX2、EMCフィルタ（L = 160 nH）+整合回路。測定された共振周波数は約12.56MHz（最終的な金属環境なし）（良品と不良品で同一）。
症状（詳細な特徴）
- フィールドONの前にフルSPIが動作します：SWITCH_MODE_NORMAL、GetVersion、GetDieId、EEPROMの読み書きはすべてSUCCESS（ステータス0x0000）を返します。
- 最初のFieldOn(RF_ON)では、ホストがフィールドオンイベントを待つためにタイムアウトします。その直後、すべてのSPIレジスタの読み取りがタイムアウトします（CLIF_STATUS、SYSTEM_CONFIG、GetDieIdの読み取りはすべてHAL IOタイムアウトを返します）。VENリセットを行うまで、このチップはSPIに対して全く反応しません。
- VENリセット後、チップは再び正常になります（GetVersion OK）。その後、FieldOnが再びチップを破損させ、無限リトライループが発生します。
- RFフィールドは放射されません(NFCテストLEDは点灯しません)。基板は約20mAの電流を消費し、低電力状態に戻ることはありません。
- 良品と不良品は、ファームウェア（0x0201）、DIEIDロット、EEPROM構成、アンテナ（VNA）、およびDC抵抗において同一である。唯一の違いは、FieldOnでは不良ユニットが破損してしまう点です。
- ホストMCUはハング中も生き続けます(I²Cキーパッドエキスパンダーが応答し続けます)。つまり、故障するのは基板全体ではなくPN5190側です。
- 正常ユニットと不良ユニットの電流消費量は約2.7秒までは同一ですが、約2.7秒で正常ユニットは処理を完了して低電力に低下し、不良ユニットは約20mAのままになります。
除外された項目（それぞれ直感ではなく、測定に基づいて）
| アンテナ／マッチング／チューニング | miniVNAを4つの良品ユニットと4つの不良品ユニットで測定したところ、両者は区別がつかなかった。共振周波数は良品12.565MHz、不良品12.593MHz、RL ≈ −9dB、|Z| ≈ 24.7Ω、SWR ≈ 2.08（いずれも同じ値）。 |
| TX短絡/過電流 | 直流抵抗 TX1–TX2 ≈ 1.2 kΩ、TX1–GND ≈ TX2–GND ≈ 1.15 kΩ、良品と不良品で同一 |
| 静電気による電源漏れ／デカップリング | 電流消費量は、約2.7秒までは正常と異常で同じである。 |
| SYS3V電圧低下 | 3.3Vで安定して測定。3.3Vレールすべてに47μFのバルクコンデンサを追加→変化なし、依然として故障。 |
| チップFW | ユニットを最新のPN5190ファームウェアにアップデートしましたが、依然として失敗し、同じ動作を示します。（未処理の良品と不良品の両方で、ファームウェアコード0x0201が報告される。） |
| シリコンロット | DIEID 正常 00000000 0DD0945E 5B38BDDC 892C0810 対 不良 00000000 0DD095A6 6938BDDC 892C0E64 — 同じプレフィックス/ロット構造 |
| TXドライバ振幅 | FieldOn前のCLIF_SS_TX1/2_RMCFG CW振幅の減少 → 変更なし |
| TX_LDO過電流保護 | TX_LDO_CONFIGビット11（0xAE → 0xA6）で無効化しましたが、変化はありませんでした。 |
| TX_LDO出力コンデンサ | VDDPA出力コンデンサ（4.7 µF + 100 pF）を取り外した → 変化なし |
EEPROM構成（良品と不良品で同一）
- DCDC_PWR_CONFIG (0x00) = 0x21 (DC-DCオフ、VUP = VBATPWR、ULPCD有効)
- TX_LDO_CONFIG (0x02 / 0x03) = 0xA7 / 0xAE (デフォルト)
- TX_LDO_VDDPA_HIGH / LOW (0x06 / 0x07) = 0x00 (最小値、約 1.5 V)
- DPCが無効になっています
質問
- これは報告された「最初の起動時/最初のRFフィールドオン時にPN5190チップ破損」と一致します。根本原因と最終的な解決策を確認できますか?(注:最新のPN5190ファームウェアをフラッシュしても解決しませんでした — 同じ失敗です。)
- このロット／日付コードに対応するシリコンに関する訂正情報はありますか？完全なDIEIDとチップの刻印の写真も提供できます。
- 当社のトポロジー（内部TX_LDO、VUP_TX = 3.3 V、VDDPA = LDO出力、DC-DCオフ、DPCオフ、ULPCD、VDDPA最小1.5 V）において、この構成は有効でしょうか？VDDPAを最低限の電圧で動作させることは問題でしょうか？また、比較対象となる正しいEEPROM電源構成（PNEV5190Bとの比較）は何でしょうか？
- 電源投入順序に関する要件（VENとサプライランプのどちらを優先するかなど）があり、それが満たされない場合にこのような問題が発生するのでしょうか？注:前の(動作中の)ロットと比べて、VENはI²Cエクスパンダ出力から直接MCU GPIOに移し、VENプルアップはDNPなので、ホスト起動時にVENは浮動します。
- ブラウンアウト、過電流、FW、シリコン、アンテナがすべて測定で除外されている中で、VENリセットまでチップがSPIに応答しなくなるRF_ON経路の他に何があるのでしょうか?
よろしくお願いいたします。
イグナシオ
お世話になります。
RF Fiel ONコマンドがICをハングさせる既知の問題は公表されていません。
ファームウェアの更新とEEPROMの内容をクローンした後、すべての影響を受けたPN5190デバイスで問題が解決したのか、教えていただけますか?この情報は、問題の範囲をよりよく理解するのに役立つだろう。
一部の端末で問題が継続する場合、正常に動作する端末と不具合のある端末との間でA/B比較テストを実施する機会はありましたか？このような検査は、根本原因がIC自体に関連しているのか、それともシステムの他の要素に関連しているのかを判断するのに役立ちます。
ロット追跡についてですが、代理店に製造ロットや影響を受けた部品の製造履歴について追加情報を提供できるか確認していただけますか?
不可解な点は、正常に動作するユニットと故障するユニットが、同じファームウェアバージョン（v2.01）、同じシリコンリビジョン（B1）、同じハードウェア、同じアンテナチューニング、そしてクローン作成後には同じEEPROMの内容を持っていることだ。しかし、うまくいくものもあれば、ほとんどはうまくいかない。
PN5190のファームウェアをv2.0Dにアップグレードすることで、不具合のあるユニットの問題が解決します。その理由と、v2.01に既知の問題があるかどうかを知りたいです。
1. 症状:
故障したユニットについて：
- 起動と初期化は正常に完了します。
- 最初のRFフィールドオン時には、チップは意味のある電流を引きず、RFフィールドを発生させません(NFC電源のLEDテストカードで確認済みで点灯しません)、SPIでは完全に反応しなくなります。
- ホストがIO_TIMEOUTを報告しました。ソフトリセットも失敗します（SPI応答が必要です）。
- チップを復旧させるには、ハードウェアリセットまたは電源の再投入のみが必要です。その後は次のRFフィールドオンまで正常に動作しますが、そこでまたフリーズします。完全に再現可能。
- 電源電圧（3.3V）は終始安定しており、電圧低下は発生しません。
- ボードの寿命で初めての電源アップ時に、一度きりの~600 mA(北欧PPK2で測定した0.62A)のイベントが観測されますが、その後のパワーアップでは二度と発生しません。
故障したユニットのNFCコックピットからのログ：
INFO:RFProtocolTuningService_PN5190:プロトコルをロード: RM_A_106
INFO:TypeACardViewModel:RM_A_106 プロトコルが正常にロードされました。
情報:RfFieldControlService:RFオン
警告:代表:PIN_IRQが高くなるのを待っていた。タイムアウトしました。
エラー:RfFieldControlService:フィールドオン中にエラー240、IO_TIMEOUTが発生しました。
正常に動作しているユニット（ファームウェア、設定は同じ）からのログ：
INFO:RFProtocolTuningService_PN5190:プロトコルをロード: RM_A_106
INFO:TypeACardViewModel:RM_A_106 プロトコルが正常にロードされました。
情報:RfFieldControlService:RFオン
情報:RfFieldControlService:RF Off(RF オフ)
ATQA 04 00 / SAK 0x08 / UID 04 8D12 33
2. テストセットアップ
自社のホストファームウェアを除外するため、NXPのナレッジベース記事「 外部PN5190を評価ボードPNEV5190BPに接続 する方法」(R5/R7設置、R6開)に従い、本番ボードをUSB↔SPIブリッジとして使うPNEV5190BPに直接接続しました。R20入賞;VBAT/VBAT_PWR/VUPジャンパーは撤去されました。SPI_CLK、SPI_MOSI、SPI_MISO、SPI_CS、NFC_IRQ、NFC_VEN、GND、外部ボードに配線)。
- NFC Cockpit v9.0.0
- PNEV5190BP with MCU FW NNC_uC_VCOM_04.00.00
- 外部基板はNordic PPK2から3.3Vで給電される（電流測定が可能）。
この故障はNXPホストとNXPソフトウェアの両方で再現されているため、ホストファームウェアが原因ではありません。
3．除外した項目（測定値付き）：
仮説 | どのようにして除外されたのか |
供給崩壊／停電 | 3.3Vレールは全体を通して安定して測定されました |
送信機の短絡 | 良品と不良品の直流抵抗値（TX1-TX2間、TX1-GND間、TX2-GND間）は同一（数kΩ） |
PAデカップリングにおけるリーク | 現場投入の瞬間までは、電流消費量は同じで、良い場合も悪い場合もある。 |
アンテナの同調ずれ／マッチング | VNA測定、良品4台＋不良品4台 — 下記参照 |
ICへの物理的損傷 | チップはハードウェアリセットで復旧するが、その後再び再現可能な形で故障する。 |
ホストファームウェア | NFC Cockpit + PNEV5190BPを使用して再現 |
PN5190ファームウェアバージョン | 良品と不良品の両方がv2.01、Hw B1にあります |
ユーザーEEPROMコンテンツ | 正常なユニットのEEPROM全体を不良ユニットにクローンしたが、それでも失敗する。 |
差：約29kHz（0.2％）、測定ノイズの範囲内。8つの掲示板で確認済み。アンテナは区別がつかない。
4. EEPROMの比較 - 1バイト
良いユニットと悪いユニットの両方のユーザーEEPROMを完全にFW v2.01でダンプし、それらをファレンジしました。
648個のパラメータのうち、正確に1つだけ異なる。
地域: DPC_SETTINGS
パラメータ: DPC_CONFIG
オフセット: 0x76
良品ユニット: 0x77
不良ユニット: 0x76
それ以外の部分はすべてバイト単位で同一です。
これは答えのように思えた。特にRN00003の注意書きを考慮すると尚更だ。
「対称」アンテナに接続されたIC(例:カスタマー開発ボードアンテナ)では、DPCを無効化せずRFフィールドを有効化しないでください。長期間にわたる過電流による送信機ドライバーの損傷が起こる可能性があります。
当社のアンテナは対称型(差動TX1/TX2)で、最初の電源を入れた時の一度きりの~600 mAの現象は過電流状態と一致しています。
しかし、バイトをコピーしてもユニットは修復されません
テスト | 結果 |
不良ユニットにDPC_CONFIG = 0x77を書き込み（v2.01）、読み出し結果を確認し、電源を再投入する。 | それでも失敗する |
正常ユニットの完全なEEPROMダンプを不良ユニットにロードし（v2.01）、電源を再投入する | それでも失敗する |
良好なユニット、未改造、v2.01 | 完璧に動作します |
つまり、DPC_CONFIG合格・不合格と関連していますが、原因ではありません。本当の違いが何であれ、それはユーザーのEEPROM領域には含まれていません。
5. 解決策：ファームウェアをV2.0Dに安全にアップグレードする
PN5190Firmware_2.0D.esfwu （LEDLフォルダ、B0/B1用レガシーダウンロード）を使用してセキュアファームウェアアップグレードを実行すると、不具合のあるユニットが正常に動作するようになります。
- アイドル時：約33mA
- RFフィールドオン:~240 mA持続、安定、LED点灯
- Layer3 をアクティブにすると、ATQA 04 00、SAK 0x08、UID 04 8D 12 33 が返されます。
- 自社製品ファームウェアで動作を確認しました
これまでに2ユニットがこの方法で回収されており、どちらも完全に機能しています。
副作用：PwrConfigが上書きされ、過熱を引き起こす。
アップグレード後、EEPROMオフセット0x0000 （ PwrConfig ）は0x21から0xE4に変更されます。0xE4の場合：
PwrConfig 0xE4 | PwrConfig 0x21 (復元済み) | |
アイドル電流 | 約290mA | 約33mA |
ダイ温度（ PMU_TEMP_REG@0x5B ） | 100℃ | 40 °C |
アイドル時は290 mAでRFフィールドなし、内部温度センサーは100°C(最大Tjは125°C)を読み取ります。アップグレード後には毎回PwrConfigを0x21に復元します。
0xE4は、v2.0DにおけるPwrConfigのデフォルト値として意図されているのでしょうか？これは他のユーザーにとっても問題になりそうです。
アップグレードによって変更された16個のEEPROMパラメータ
パラメータ | オフセット | 以前のバージョン（v2.01） | (v2.0D) 後 |
PwrConfig | 0x00 | 0x21 | 0xE4 |
DPC_CONFIG | 0x76 | 0x76 | 0x77 |
DPC_GUARD_TIME | 0x87 | 0x64 | 0xFF |
DPLL_CONTROL | 0x2AE | 0x00000C03 | 0x00000C63 |
DpllPhaseRfON | 0x2D2 | 0x012C | 0x00A0 |
DpllPhaseCeA | 0x2D4 | 0x012C | 0x00A0 |
RssiCtrl_00_AB | 0x2DE | 0x09 | 0x0C |
rssi_no_samples | 0x4CA | 0x02 | 0x00 |
極性 | 0x4CC | 0x00 | 0x01 |
LpcdExtDcdcDelayToOn | 0xCE1 | 0x00 | 0x64 |
LpcdExtDcdcDelayToOff | 0xCE2 | 0x00 | 0x64 |
ClifRXFrameLen | 0xCE4 | 0x00000000 | 0x00EF0003 |
RxGuardTO_Multiple | 0xCE8 | 0x00 | 0x01 |
デジタルTBシグナルインデックス | 0xCE9 | 0x00 | 0x9B |
デジタルTB信号ビット | 0xCEA | 0x00 | 0x04 |
AnalogTBSignal | 0xCEB | 0x00 | 0x78 |
良いユニットの完全なEEPROMを不良ユニットにクローンしても直らないため、この16バイトだけでは解決できず、ファームウェアコード自体に何かが関与しているはずです。
6. ダイID
全てのユニットは、受領時の状態のままハードウェアB1、ファームウェアv2.01です。
不良品 #1: 00 00 00 00 0D D0 94 5A 5F 38 BD DC 89 2C 04 22
不良品 #2: 00 00 00 00 0D D0 95 A6 69 38 BD DC 89 2C 0E 64
不良品 #3: 00 00 00 00 0D D0 95 62 5F 38 BD DC 89 2C 08 10
良品 #1: 00 00 00 00 0D D0 95 0E 5D 38 BD DC 89 2C 08 10
7. 質問
- FW v2.01で、RF Field ONがフィールドもSPI応答もないままICがハングしてしまう既知の問題はありますか?DPC_CONFIGレジスタはv02.03で初めて導入された（RN00003による）こと、そしてv02.07→v02.08とv02.08→v02.09の両方にDPC制御の修正が含まれていることに注意してください。
- ファームウェア、シリコンリビジョン、ハードウェア、EEPROMがすべて同じであるにもかかわらず、なぜ約25%のユニットは正常に動作し、約75%は動作しないのでしょうか？ユーザーEEPROMの範囲外(工場出荷時のトリムや内部状態)で、同じロットのユニット間で異なるものはありますか?
- 上記のダイIDは異なる生産ロットやウェハーバッチに特定できますか?
- v2.0Dにアップグレードした後、PwrConfig = 0xE4という値は意図された値ですか？その結果、当社の設計ではアイドル消費量~290 mA、ダイ温度100°Cとなります。
- PN5190デバイスは特定のファームウェアバージョンを事前にプログラムした状態で注文できますか?ツール自体がバージョン2.01が旧バージョンであることを警告しているにもかかわらず、バージョン2.01で出荷したため、生産バッチ全体が無駄になってしまいました。
- 残りの80~0ユニットの未使用ユニットに対して、一度きりの600 mAイベントを完全に回避するために、最初の電源アップ前にv2.0Dにアップグレードすることが推奨される緩和策でしょうか?
アドバイスをいただければ幸いです。