NXPテクニカルサポートチーム様
S32K328プラットフォームでマルチコア操作を有効にした後、HSE_Bサービスがハングアップ（応答なし）する問題について、技術的なサポートをお願いしたくご連絡いたしました。
1. 環境とセットアップ
- MCU: S32K328 (デュアル Cortex-M7 + HSE_B)
- 設定ツール：EB tresos（MCAL設定用）
- コアロール: M7_0 と M7_1 は Autosar-OS と同時に実行されます。
M7_0は、メッセージ記述子用の共有SRAMを使用してHSE_Bと通信します。
2. XRDCおよびペリフェラルの設定（テスト用）
権限の問題を切り分けるために、非常に寛容な構成を適用しましたが、M7_0とHSE_Bを単一のドメインにグループ化するか、別々のドメインに分離するかに関わらず、症状は同じままです。
- メモリ構成: すべてのSRAM領域へのフルアクセスが許可され、特定のPFLASH/DFLASH領域がHSEに割り当てられます。
- 周辺機器設定 (PDAC): CONFIGURATION_GPR、PFC/PFC_ALT、FMU/FMU_ALT、および MU_0 / MU_1 にフルアクセス権限が割り当てられています。
3. ブートシーケンス
アプリケーションは以下の起動シーケンスに従います。
3.1 M7_0 ブート → クロック初期化。
3.2 HSE STATUS が INIT_OK であることを確認します。
3.3 リソースマネージャの初期化（XRDC セットアップ用の RM_Init）。
3.4 ペリフェラルの初期化
3.5 M7_1 (コア 1) を開始します。
3.6 OSを起動する。
4．問題の説明と症状
M7_0とM7_1はどちらもOS環境内で正常に起動し、動作します。しかし、その後HSEサービスリクエストが呼び出されると、HSEは応答せず、ハングアップ状態になる。ハング発生時のレジスタの状態は以下のとおりです。
- XRDC登録状況:
XRDC_DERRLOC[3]が0x00020000に変更されます。
ただし、DERR_W3_0/1/2 レジスタまたは DERR_W3_16/17/18 レジスタにはエラー値は記録されません。
- メッセージングユニット（MU_0）ステータス：
MU_0_TSRレジスタでは、フラグTE1とTE2は「空でない」状態のままで、クリアされません。
MU_0_FSRレジスタでは、F3フラグは変更されません。
5. 質問
5.1 XRDC_DERRLOC[3]がシフトしているにもかかわらず、DERR_W3_xレジスタに特定のエラーの詳細が表示されない場合、この動作を引き起こしている原因は何でしょうか？これは、HSE内部のDMAまたはバスマトリックス構成による暗黙的なアクセス違反に関連している可能性がありますか？
5.2共有SRAMはMPUによって明示的にキャッシュ不可として構成されているにもかかわらず、HSEがディスクリプタを読み取ることを妨げるような、既知のマルチコア制約やOS環境下での隠れたキャッシュ動作はありますか？
5.3 HSE_STATUS_INIT_OK チェックまたはコア 1 の起動に関連して、RM_Init (XRDC 初期化) の実行タイミングに関する既知の制約または前提条件はありますか？
5.4 MU送信ステータスレジスタ（TE1/TE2）がスタックし、HSEが記述子を処理しない理由を特定するために、どのような手順または追加のレジスタを確認する必要がありますか？
このボトルネックを解消するためのご意見やご指導をいただければ大変ありがたく存じます。
よろしくお願いいたします。
こんにちは、 @NewbieNerd さん
HSEは常に回答を返すことになっている。応答がない場合、HSEはシャットダウンモードに移行した可能性が高いです。これは致命的なエラーが発生した場合に起こります。例えば、アクセス権限の不足、ダブルビットECCエラー、無効なアドレスなどが原因でHSEがデータを読み書きできない場合。
これは、MU_0のGSRレジスタを読み取ることで確認できます。ビット「0」が設定されている場合、HSEはシャットダウンモードです。
XRDCでエラーの詳細を確認するには、「19.7.3.2」の項に従う必要があります。S32K3リファレンスマニュアルの「ドメインアクセス違反エラーの処理」を参照してください。
ステップ2では、DERRレジスターの詳細を確認することが重要です。
デバッグを迅速に行うには、MDA_W0_0_DFMT0にDID=3を書き込むことで、Cortex-M7_0 / Cortex-M7_0_debugをドメイン3に移動できます（S32K328ではHSEは常にドメイン3にあります）。
すると、DERR に詳細が表示されます (これは、HSE によって何らかのエラーが発生したときにデバッガーで確認した例です)。DID = 0 の場合は、これは表示されませんでした。
これは何が問題だったのかの手がかりになるはずだ。
もう一つ重要な点は、HSE_STATUS_INIT_OKが設定された後にXRDCを有効にする必要があるということです。これはHSE FWリファレンスマニュアルに明記されています。
よろしくお願いいたします。
ルーカス
迅速なご返信ありがとうございます。ご要望いただいた開発環境の具体的なバージョン情報は以下のとおりです。
1. ソフトウェアおよびファームウェアのバージョン
- HSEファームウェア: S32K358_0_2_40_0
注：このバージョンを使用しているのは、ドキュメントにS32K328派生版をサポートしていると明記されているためです。
- RTD (リアルタイム・ドライバ): AUTOSAR リリースバージョン: 4.7.0、ソフトウェアバージョン：3.0.0
2. 開発ツールチェーン
IDE: このプロジェクトではS32DSを使用していません。
設定ツール：EB tresos Studioは、すべてのMCAL設定に使用されています。
EB tresos バージョン: 27.1.0
3. 追加情報
私は現在、ホスト側（Cortex-M7）の開発を主導しています。私たちは既に、この行動について社内のHSE FW開発チームと徹底的に協議し、合意形成を図っています。しかしながら、HSE FWの観点からは根本原因や異常は見つからなかったため、これはマルチコア/OSの初期化中に発生したホスト側のランタイム構成または同期の問題である可能性が高いと推測されます。
あなたのご指導のもと、正確なボトルネックを特定できることを心から願っております。EB tresosプロジェクトから、さらに設定ダンプやレジスタキャプチャが必要な場合はお知らせください。
よろしくお願いいたします。
使用されているHSEファームウェアのバージョン、RTDおよびS32DSのリビジョンを具体的にご指定いただけますでしょうか？ありがとう
貴重なデバッグガイドと洞察をありがとうございました。
ご提案いただいた件について、さらに調査を行い、弊社側で以下の結果を確認いたしました。これらの調査結果を共有し、ツール構成の制約を回避する方法についてご助言をいただきたく存じます。
1. RTDバージョンの明確化
前回のやり取りでお伝えしたとおり、現在弊社では以下のものを使用しています。
- RTDソフトウェアバージョン：3.0.0
- AUTOSAR リリースバージョン: 4.7.0
2. EB tresos構成制約（ドメイン割り当て）
S32K328では、HSEはドメイン3に恒久的に割り当てられているとおっしゃっていましたね。
しかし、EB tresos (v27.1.0) ではRTD 3.0.0 環境プラグインの場合、リソースマネージャ（RM）の構成構造では、ドメイン2（ドメインID 0、1、2）までしか割り当てることができません。
設定ツールではドメインの最大数が2に制限されているため、EB tresosを介してドメイン3にマスター/スレーブを適切に設定または割り当てることはできません。
質問：S32K328派生機種のEB tresosでドメイン3の設定を公式に有効化するRTDバージョンまたはパッチを具体的に教えていただけますか？それとも、実行時コードを使ってXRDCレジスタを手動でオーバーライドする必要があるのでしょうか？
3. XRDCエラーレジスタの状態（DERRLOCとDERR_Ww_iの比較）
リファレンス・マニュアルの手順に従って、エラー状態中に以下の動作を確認しました。
XRDC_DERRLOC[3]はダンプによって0x00020000としてキャプチャされますが、周辺機器ビューではキャプチャされません（DERRLOC[3]は存在しません）。
しかし、エラー処理の手順に従ったにもかかわらず、すべてのDERR_Ww_iレジスタは0のままです。
ご指摘のとおり、DERRに詳細情報が不足しているのは、ホストコア（Cortex-M7_0）が別のドメイン（例えば、DID=0または1）で動作しているため、ドメイン3（HSE）によって生成されたエラーログを読み取ることができないことが原因のようです。
4. 実行タイミングの検証
ブートシーケンスを再確認した結果、HSE_STATUS_INIT_OKが設定された後にXRDCが明示的に有効になっていることを確認しました。これはHSE FWリファレンスマニュアルの要件に準拠しています。
5．指導依頼
上記のツール制約により、Cortex-M7_0またはそのデバッグマスターをEB tresos内のドメイン3に容易に移動できないため、以下の点についてアドバイスをいただけますでしょうか。
MCALの初期化を壊さずに、デバッグのためにMDA_W0_0_DFMT0を強制的にDID=3にオーバーライドする適切な方法はありますか？
RTD 3.0.0において、ドメイン0/1からドメイン3のエラーレジスタを検査するための既知の回避策はありますか？
引き続きサポートいただき、誠にありがとうございます。
ドメイン3が欠落していることは、RTD 3.0.0における既知の問題です。バージョン4.0.0以降で修正されています。推奨される解決策は、RTDを最新バージョンにアップグレードすることです。そうでなければ、XRDC レジスタの書き換え、構成ファイルの書き換え、新しい RTD で構成ファイルの生成、そしてそれをプロジェクトで使用するなど、何らかの回避策を手動で実装する必要が生じます。しかし、これは一時的な応急処置に過ぎず、推奨されるクリーンな解決策は、新しい RTD を使用することです。
「19.7.3.2」の項によるとドメインアクセス違反エラーの処理」では、エラーハンドラのためにドメインを再設定するのが一時的であるべきです。この段階では、デバッガーを使ってDIDを修正し、エラーの詳細を読み取れるようにしてみるのが良いでしょう。
MU_0のGSRレジスタのビット0が設定されていることを確認しましたか？
よろしくお願いいたします。
ルーカス