2391427_ja-JP

はい

S32N55 HSE2 CRS セキュアデバッグ: SDC-600 TX FIFO が 20 バイト後に停止する

こんにちは、

CRSドメインのSecure Debug認証の問題についてのフォローアップ
前回の投稿(「S32N55 HSE2 CRSドメイン認証」で議論されています
「未完了」)、より具体的な新発見を報告したい
私はそれが根本原因を示していると信じています。これを別々に投稿します
提案した。

セットアップ:
- S32N55、HSE2、CRSドメイン(APP_CHALLENGE)、ラウターバッハTRACE32 / SDC-600
- 認証フロー:COMM_START -> AUTH_MODE_REQ -> APP_CHALLENGE(StartCmd)
-> チャレンジを受信 -> ProofProvCmd (debugSignalMap(4B) + を送信
appChallengeAuth(16B) via AES-CMAC)

調査結果：
debugSignalMap(4B) + appChallengeAuth(16B) = 20バイトを送信後
ProofProvCmdパケットを介した合計、ホストのSDC-600 TX FIFOステータス
レジスタ（MU ベース +0xD2C のビット [7:0]）は、二度と空き領域を報告しません。
言い換えれば、HSE2はSDC-600チャネルの排水を停止しているように見えます。
まさにこの20バイトの境界線です。ホストの低レベルのSend()ルーチン
このステータスレジスタはタイムアウトなしでビジーウェイトループでポーリングしますので、
この時点で無期限にブロックされています。

この動作は、16バイトの後に何が続くかに関わらず一貫しています。
appChallengeAuth:
- 追加のパディングバイトを追加するかどうか（
debugAuthProof を 32 バイトに結合して、またはそれ以上何も送信せずに
FLAG_ENDに直接到達すると、FIFOは同じ20バイトでドレインを停止します。
ポイント。これは問題がパケット長やフレーミングではないことを示唆しています
不一致ですが、そのHSE2はすぐにチャネルのサービスを停止します
16バイトのappChallengeAuthを受け取りました。

質問:
これはAPP_CHALLENGEフローに対して期待される挙動でしょうか(例:HSE2は
ホストの他の動きを待つためにここで一旦一旦止めてください
チャネルの排水を続けているのか、それとも
この時点で受信したパケット内容(debugSignalMapまたは
appChallengeAuth)がHSE2側で却下・誤った形で通知されたのでしょうか?

参考までに:
- FSSドメイン(FSS_CHALLENGE)認証と同等のフロー
同じSend()を用いて(AUTHSTATUS=0xBBB)正常に完了します。
ルーチンおよびSDC-600ベースで、4B信号マップ+32B応答を送信します。
子供はない。
- CRSドメイン（APP_CHALLENGE）ターゲット = HSE_DEBUG_DOMAIN_APP（0x1B）、
hse_srv_debug_auth_protocol.h に対して確認済み。

APP_CHALLENGEのこの段階でHSE2が何を期待しているかについてのガイダンスはありますか？
フローを教えていただけると大変ありがたいです。

ありがとう、

Re: S32N55 HSE2 CRS Secure Debug: SDC-600 TX FIFO stalls after 20 bytes

こんにちは、チェンインさん

ご指導と脚本の校閲、ありがとうございました。

スクリプトの問題に関する詳細なフィードバックをお待ちしています。
修正プログラムの準備が整い次第、適用してください。

二段階アプローチに関して、我々が現在どのような立場にあるのかを明確にするために
あなたが提案した: 我々が報告したハング (SDC-600 TX FIFO がもはや
debugSignalMap + appChallengeAuth の後にドレインが発生すると、
フェーズ1の終了時、具体的には送信直後
hseDebugAuthorizeProofProvCmd_t に進む前に
hseDebugCardCmd_t は全くありません。ですので、フェーズ1はまだ確認されていません
エンドツーエンドで成功裏に完了します。現在、この数列はで停止しています。
このまさにフェーズ2(CardCmd)に到達する前の段階です。

お客様からのフィードバックを受け取り次第、以下の対応をいたします。
1. スクリプトに修正を適用する。
2. 段階的アプローチに従って再テストし、応答を記録します。
hseDebugCommStartCmd_t から各コマンドまで
hseDebugAuthorizeProofProvCmd_t を個別に確認し、
次のステップに進む前に、各ステップにおける期待値を算出する。
3.フェーズ 1 が完了したら、hseDebugCardCmd_t の検証に進んでください。
正常に完了したことが確認されました。
4. 更新されたログを報告してください。

改めて、皆様のサポートに感謝します。

よろしくお願いします、
エディ

Re: S32N55 HSE2 CRS Secure Debug: SDC-600 TX FIFO stalls after 20 bytes

こんにちは、 @EddiePark

投稿ありがとうございます。

1. ご提供いただいた元のスクリプトを確認したところ、いくつか問題点が見つかりました。近日中にフィードバックをお送りいたします。

レビューの過程で、文書化された手順と一致しないと思われるいくつかの問題点が判明しました。したがって、実際のパケット交換とHSE FW インターフェースのコメントで説明されている要件を慎重に比較することをお勧めします。

2. スクリプトで見つかった問題を修正したら、テストを行い、ログを確認します。

3. それでも問題が解決しない場合は、デバッグ手順を2つのフェーズに分けて、問題を特定することをお勧めします。
まず最初に、hseDebugCommStartCmd_t から hseDebugAuthorizeProofProvCmd_t までの認証シーケンスが正常に完了することを確認してください。そして、各コマンドの応答をログに記録し、次の段階に進む前に、返された値が期待どおりであることを確認します。

第2段階では、hseDebugCardCmd_tに注目してください。HSE FW Interfaceドキュメントに記載されたコメントに基づき、このステップに関わるすべてのパケットを厳格に検証し、その内容と順序が文書化された要件に合致しているかを確認することをお勧めします。

BR

チェイン