デバイス: S32K312
ツールチェーン：Green Hills ELXR（コンパイラ）
HSEファームウェア：s32k312_hse_fw_0.13.0_2.55.0_pb250129.bin
デバッガ:Lauterbach TRACE32
ソフトウェア:AUTOSAR RTDベースのブートローダー(FBL)+アプリケーション(APP)、2イメージ構造
問題の概要
一部の生産ユニットでは、機能処理の直後にCPUがハングします
(ソフトウェア)リセット。同じユニットは破壊的
（電源投入）リセット。このフリーズは、当社の基準品／正常品では再現しません。
NMIがアプリケーションコード実行前に発生している証拠
1) ハングポイントでキャプチャされるCPUコンテキスト(自動スタックされた例外フレーム):
- R0-R3 = 0x00000000、R12 = 0x00000000
- LR = 0xFFFFFFFF(デフォルトリセット -> まだBLが実行されていない)
- PC = 0x00416904(Reset_Handlerの最初の命令アドレス)
- xPSR = 0x01000000
2) SCB->ICSR = 0x00000802
- VECTACTIVE[8:0] = 2 -> NMI は現在アクティブな例外です
- RETTOBASE = 1
これは、CPUが現在NMIハンドラ内で実行されていることを確認するものです。
3) NMIオフセットのベクトルテーブルエントリが自分のオフセットを正しく指している
デフォルトの例外ハンドラなので、これはベクターではなく本物のNMIイベントです
テーブルの破損。
レジスタはすべて同じハング状態（すべてクリーン／非アクティブと読み取られる）でチェックされました。
- MC_RGM_DES = 0x00000000(破壊的なリセットではない)
- MC_RGM_FES = 0x20000000(ビット29のみ)(「ソフトウェア機能リセット」のみ)
フラグセット、他の関数なし
リセットソースフラグが設定されています)
- FCCU:STAT、N2AF_STATUS、A2FF_STATUS、N2FF_STATUS、NCF_S0、IRQ_STAT
all = 1 0x00000000
- CMU_FCインスタンス0、3、4:SR = 0x00000000(高低周波数フォルトなし)
- PMC LVSC = 0x00000000(LVD/HVDフラグなし、ラッチまたはライブ)
- ERM(0x4025C000):良好または故障したユニットで読み取れませんでした
(おそらく私たちの設定ではクロックゲートされているため)、ERMの状態は未確認です。
質問
1. FCCU / CMU_FC / PMC / MC_RGM以外にNMIの情報源はありますか?
アプリケーションのReset_Handlerが実行する前に、
最初の指示?
2. HSEサブシステムはアプリケーションコアとは独立して動作するため、
アプリケーションコアの機能リセットが可能である(ただし、
リセットHSE)を起動して状態の不一致を作り、NMIをトリガーします。
アプリケーションコア?
3. この症状に一致するS32K312の既知の訂正表はありますか?(NMIのみ)
機能/ソフトウェアのリセットで、電源オン時のリセットは一切ありません)。
追加のレジスターの確認や、ドキュメントについての指針はありますか?
FCCU/ERM/CMU_FC/PMC以外のNMIの情報源があれば大変ありがたいです。
こんにちは、 @Chibeom さん。
ハング状態のレジスタMU_0.MUB CSSR0とMU_1.MUB CSSR0を読み取り、ビット0(NMIC)がどちらかに設定されているか確認していただけますか?
よろしくお願い申し上げます。
こんにちは、 @danielmartynek さん、
MU_0.MUB / MU_1.MUB CSSR0 をご指摘いただきありがとうございます。
MU_0.MUBとMU_1.MUBの両方のCSSR0(ビット0、NMIC)0x00000000は
ハング状態で故障したユニット、したがってMU->NMIリクエストパス(CCR0[NMI] /
CSSR0[NMIC])は保留中ではないようです。
しかし、既知の良品ユニットと
故障したユニット（両方とも同じハング状態のアドレス範囲でキャプチャされました）、
一貫した違いが見られました。
良好なユニット 不良ユニット
MU_0.MUB VER 0x0300000F 0x0300000F (同一)
MU_0.MUB PAR 0x20200404 0x20200404 (同一)
MU_0.MUB CR 0x00000000 0x00000000 (同一)
MU_0.MUB SR 0x00000000 0x00000002 <- MURIP セット
MU_1.MUB VER/PAR/CR: 正常ユニットと故障ユニットで同一
MU_1.MUB SR 0x00000000 0x00000002 <- MURIP セット
SO、両方のMUインスタンスで、SRビット1(MURIP)は故障した
部分のみに設定されています。一貫して。リファレンス・マニュアルによると、MURIPは次のように示しています。
「プロセッサA」はMUリセットを発行しており、クリアできるのは
システムリセット(多数ユニットリセットによるものではありません)。
CPUはNMIハンドラー内でフリーズし、実行前に何も実行しません
アプリケーションコード自体がこのフラグをクリアできなかったはずなので、
この起動シーケンスの前またはその一部として設定されている必要があります。
以下の点についてご意見をお聞かせいただければ幸いです。
1.MU_0.MUBおよびMU_1.MUBの場合、どのプロセッサが「プロセッサA」(すなわち
MURIPは誰が設定しているのでしょうか?ヘッダーは「MUB」レジスタブロックのみを公開します。
アプリケーションコアアクセス可能なアドレスは、
アプリケーションコアは常に「プロセッサB」、HSEは常に「プロセッサA」となります
こういう場合に?
2. 「システムリセット」(MURIPをクリアするために必要)には機能型/ソフトウェアが含まれますか?
アプリケーションコアのリセット、それとも破壊的/PORリセットだけ?もし
MURIPは機能リセットによってクリアされないため、
電源投入後はクリアされるが、ソフトウェアリセット後も設定は維持される。
3. NMI の問題とは関係なく、MURIP フラグ自体がセット/スタック状態になっているか。
通常運転中に想定される、あるいは異常とみなされる事象か？
4. CSSR0[NMIC] が現在0を読み取っているため、ハードウェアは
NMI例外エントリ時にNMICを車載クリアするのか、それとも以下でのみクリアされるのか
明示的なソフトウェア書き込み(この場合、NMIC=0はMU->NMIチャネルはそもそもアサートされていませんでした)?
改めて、これまでのご助力に感謝します。
こんにちは、 @Chibeom さん。
遅れて申し訳ありません。私は2日間オフィスを不在にしていました。
1. はい、HSE_BコアはMU_0とMU_1のMUAインターフェースを制御します。
2. システムリセットはMURIPをリセットする。
3. これは例外的なことだと考えています。私自身はあまり情報を持っていません。
4. これはW1Cレジスタであるため、明示的な書き込みが必要です。
機能リセットがトリガーされた時点でHSE_Bが非アクティブであることを確認できますか?
また、アプリケーションがNMIハンドラーに閉じ込められている間、どのような状態HSE_Bですか?
MU_0 B面の標準HSE GPR(0x4039_C028)、FSR、GSRレジスタを読めますか?
アプリケーションでNMIピンを使っていますか?
よろしくお願いいたします。
ダニエル
こんにちは、ダニエルさん。
添付されている3つの結合レジスタダンプのスクリーンショットをご覧ください。
皆様からのご質問に基づいて整理した調査結果です。
--------------------------------------------------------
添付ファイル
--------------------------------------------------------
添付資料1：正常なユニット（セキュアデバッグ有効、正常に動作中）
添付資料2：機能リセット直前の故障ユニット
トリガーされました（通常動作）
添付資料3：機能リセット後、故障したユニットが
NMIハンドラ（ハング状態）
--------------------------------------------------------
調査結果
1) 機能リセットがトリガーされた時点での HSE_B アクティビティ、
2) NMIハンドラで停止している間のHSE_Bの状態:
添付ファイル2（リセット前）と添付ファイル3（リセット後）を比較すると、
故障したユニットでは、ハング状態）で、チェックしたすべてのレジスタが読み取られます。
リセット前とリセット後、全く同じ状態：
- MU_0.MUB / MU_1.MUB TSR = 0x0000000F、RSR = 0x00000000(保留なし)
送信/受信チャネル上のメッセージはリセットによって変更されませんでした)
- MU_0.MUB GSR = 0x00000000(変更なし)
- MU_0.MUB FSR = 0x03600000(変更なし)
- HSE GPR(0x4039C028)= 0x000001C1(変更なし)
- MU_0.MUB / MU_1.MUB SR ビット1(MURIP)= 0x00000002 -- すでに設定済み
リセットがトリガーされる前、そして設定されたまま、変更されず、その後も
リセット
SO、このリセットサイクルの前にすでにMURIPが設定されており、
機能リセット自体はこれらのHSE関連のいずれも変えません
レジスター。
参考までに、同じセキュアデバッグ機能を備えた良質なユニットでは
構成（添付ファイル1）では、MURIPは両方とも0x00000000を読み取ります
MU_0.MUBとMU_1.MUBは、HSE GPRとWKPU NCRは同じ内容です。
故障したユニットとしての値。
3) セット/スタックしたMURIPが異常かどうかについて：
承知いたしました。ご確認いただきありがとうございます。
4) NMIピンの使用:
WKPUルーティング済みのNMIパスは使っていません(WKPU_IP_USEDは有効ではありません。
WKPUのドライバーコードはブートローダーにコンパイルされていません。
アプリケーション画像)。WKPU NCR (0x402B4008) = 0x60000000 全く同じ
3つの添付ファイルすべてにおいて。NSR = すべての場合において0x00000000。以来
これはすべてのユニットと条件で変更されていません。
外部/WKPU経由のNMIソースが関与しています。
これまでの調査結果の概要
MURIP (MU_0.MUB および MU_1.MUB SR ビット 1) は既に障害発生時に設定されています
機能リセットがトリガーされる前のユニットであり、
吊り下げ期間中、変化はなかった。同じ仕様の良品では0と表示されます
セキュアなデバッグ構成。これが唯一一貫して再現可能な方法です
比較したすべてのレジスタ(FCCU、
CMU_FC、PMC、WKPU、MU CSSR0/GSR/TSR/RSR/GPR/FSR)を担当しています。
MURIPは「プロセッサA」(HSE_B)によって設定されており、クリアされるべきです。
あなたの回答によれば「任意のシステムリセット」と呼ばれ、すでに設定されているので
機能リセットがトリガーされます(リセット自体は表示されません)
変更するために)、これはHSE_B以前にMUリセットを発行したことを示唆しています
HSE_Bが認識した「システムリセット」で解除されなかったポイントです。
質問
1. HSE側から、何が原因になるのかを判断する方法はありますか?
そもそも(プロセッサA)はMUリセットをHSE_Bするのでしょうか?私たちは
MURIPがそもそも設定される理由を理解したい。
2. リセットをトリガーする推奨方法はありますかHSE_B
アプリケーションから「システムリセット」(MURIPをクリアするため)として認識します
ソフトウェア、フル電源サイクル以外は?
3. アプリケーションコア側で詰まったMURIPフラグは、
観測しているNMIでしょうか、それともこれらはより独立している可能性が高いのでしょうか
以前の同じイベント情報の症状?
この件に関して引き続きご協力いただき、改めて感謝申し上げます。
こんにちは、 @danielmartynek さん、
最新情報のご提供、そしてMURIP/NMIパスのエスカレーションに感謝いたします。
社内の安全衛生チームに質問してください。感謝します、そして待ちます
彼らの意見。
その間に、関連性のある追加のデータポイントを発見しました。
だから待つのではなく、今のうちに共有したいと思いました。
UTEST Flash領域のOTPフィールドを良品と比較すると
また、故障したユニットでは、ライフサイクル スロットに違いが見られました。
CUST_DEL (0x1B000220-22F) と OEM_PROD (0x1B000230-23F) は同一です
良品ユニットと
故障したユニット。
違いはIN_FIELDスロット（0x1B000240-24F）にあります。
- 正常ユニット：プログラミングが開始される
- ユニットの不具合: プログラムされていない (0xFFFFFFFF) と読み取られます
IN_FIELD内の正確なバイトパターンを現在も再確認中です。
我々の側のスロットだが、このスロットでの良し悪しの差は
一貫性のある。
もう少し詳しく教えていただけますか:
1.これは故障したユニットの構成が
移行の途中で破損または不完全になった
IN_FIELD?
2. 未完成または欠落したライフサイクルの進展がIN_FIELD
この件で調べているNMI/ハングの挙動について説明してください
Thread?
3. このライフサイクル進行を安全に確認または完了する方法はありますか?
故障しているユニットに対して、完全な生産リフローなしで?
ご協力ありがとうございました。
こんにちは、 @Chibeom さん。
メモリビューに基づくと、OEM_PROD = 非アクティブ、IN_FIELD = 消去済みとなります。
まずDCMの登録簿を読んでいただけますか:RM、rev.12、セクション 39.3.1 DCM メモリ マップ。
セクション38.2.3 破壊的リセット時の読み取り専用GPR 3 (DCMROD3) はどうでしょうか？
HSE_FW APIを使ってLC属性を取得することもできますよね?
よろしくお願い申し上げます。
こんにちは、 @Chibeom さん。
詳細なレジスタダンプをありがとうございます。MURIPの動作と、HSE_BとCM7_0間の潜在的なNMI経路に関する疑問点について、社内のHSEチームに報告しました。これは文書化されていないようです。彼らからの意見が届き次第、改めてご連絡いたします。
こんにちは、 @danielmartynek さん、
DCMメモリマップとDCMROD3について教えていただき、ありがとうございます。両方のユニットでDCMSTAT（0h）、DCMLCS（8h）、DCMLCS_2（80h）、およびDCMROD3（208h）をキャプチャし、RM rev.9に対してデコードしました。
----------------------------------------------------
捕捉された価値
----------------------------------------------------
良いユニット:
- DCMSTAT (0h) = 0x00000E11
- DCMLCS (8h) = 0x00000000
- DCMLCS_2 (80h) = 0x00000000
- DCMROD3 (208h) = 0x00000000
不具合のあるユニット:
- DCMSTAT (0h) = 0x00000E03
- DCMLCS (8h) = 0x06184104
- DCMLCS_2 (80h) = 0x00000006
- DCMROD3 (208h) = 0x00400000
----------------------------------------------------
デコードされたフィールド（正常なユニットはすべてゼロを読み取るため、故障したユニットのみ）
----------------------------------------------------
DCMSTAT:
- bit1 DCMERR = 1 (DCMがエラーで完了) -- 正常なユニットではこのビットは0です
- bit4 DCMLCST = 0 (LCスキャン状態が「正常に完了」していない) -- 正常なユニットではこのビットは1になります
DCMLCS:
- ビット 21-19 DCMLCC4 (IN_FIELD マーキング) = 011b = "領域は消去済み/未使用です"
- ビット 15-13 DCMLCC3 (OEM_PROD マーキング) = 010b = "非アクティブとしてマークされています"
- ビット 27-25 DCMLCC5 (Pre-FA マーキング) = 011b = "消去済み/未使用"
- 関連するすべての *_ECE/*_CFE/*_CSS ビット = 0。
DCMLCS_2:
- ビット 3-1 DCMLCC6 (FA マーキング) = 011b = "消去済み/未使用"
DCMROD3:
- bit22 LC_ERR = 1 ("ライフサイクルスキャン中にエラーが発生しました")
これは、以前共有したUTEST OTPダンプと一致しています。故障したユニットのIN_FIELDスロットは、消去済み/未使用と読み取られます。
----------------------------------------------------
障害発生ユニットにおけるHSE_FW APIの結果（HseReadLifecycle）
----------------------------------------------------
HseReadLifecycle() は 0x10 = HSE_LC_IN_FIELD を返します。したがって、HSEファームウェアの観点から見ると、現在のライフサイクルはすでに十分IN_FIELDです。
これは上記の DCM/OTP データと矛盾しているようです。DCM の DCMLCC4 フィールドは IN_FIELD として「消去済み/未使用」と表示され、UTEST OTP の IN_FIELD スロット (0x1B000240h 以降) は未プログラム (0xFFFFFFFF) と表示されますが、HSE API はライフサイクルが IN_FIELD として確認されていると報告しています。
HSEがDCMフラッシュマーキングとは独立した別の安全なストレージを通じてライフサイクルを追跡しているのか、あるいはこれがマーキング自体に問題があることを示しているのかが不明なため、結論を出すのではなく、現状のまま共有することにしました。
よろしくお願いいたします。
チボム
こんにちは、 @Chibeom さん。
データ提供ありがとうございます。
IN_FIELDスロットがまだ消去された状態なので、属性をもう一度設定して進めてみることはできますか?
先ほども述べた通り、この事件は現在内部で議論中です。
新しい情報が入り次第、このThreadを更新します。
こんにちは、 @Chibeom さん。
おそらく、ライフサイクル（LC）の推進を担当するHSEサービスが中断されたため、LCがこのような状態に陥ったのだろう。
LCおよびLC制御（DCMLCC）レジスタはHSE_FWと同様に0x77（IN_FIELD）を報告するが、UTEST領域は正しくプログラムされていない。理論上は、デバッガを使ってUTEST IN_FIELDスロットをプログラムでき、DCMエラーをクリアできるはずです。
よろしくお願いいたします。
ダニエル
こんにちは、 @danielmartynek さん。
ご提案いただいたとおり、不具合が発生しているユニットでIN_FIELD属性を再度設定してみました。
結果: HSE_SRV_RSP_NOT_ALLOWED (0xAA55A21C)
よろしくお願いいたします。
チボム