現在、FCCUを構成しており、NXPの障害マップ文書に基づいて、障害NCF[4]に対する推奨回復メカニズム（割り込みサービスルーチンで開始されるSBC開始POR回復に続く割り込み）を実装しようとしています。
私はS32K312マイクロコントローラとFS65 SBCを併用しています。コントローラーからSPIコマンドを使ってFS65 SBCにソフトウェアリセットを行い、すべての電源レールを再初期化することは可能かどうか、教えていただけますか?もし可能なら、正しい実装についてアドバイスをいただけますか?
SBC_FS65_FS_SF_OUTPUT_REQUEST_ADDRレジスタのrstbビットを有効にしようと試みましたが、SBCのリセットは確認できませんでした。
この復旧メカニズムを適切に実装する方法を教えてください。
BRサンディープ・シン
こんにちは、ピーター。
上記の回復メカニズムは、S32K3リファレンスマニュアル(Rev 8, 2024年1月)に添付されたNXPの故障マップ文書に記載されています。
さらに、私たちのCASEでは電源がSBC FS65で構成されており、これはMCUの電源供給に使われているため、MCUをリセットするだけではSBCが生成する電源を安定させることはできません。
よろしくお願いします、
サンディープ・シン
こんにちは、
その提案には少し戸惑っています。
割り込みサービスルーチンで開始された、SBC 開始の POR リカバリに続く割り込み。
この推奨されている復旧メカニズムは、技術的に妥当とは思えません。
NCF[4]は、MCUコア電源に影響を与える違反を含む電圧モニター故障を表します。コア電圧が有効な動作範囲を超えると、コアの正しい実行、フラッシュアクセス、SRAMアクセス、割り込みサービスルーチン自体を仮定できなくなります。したがって、ISRにSBCとのSPI通信を確立し、回復を開始することに依存することは、信頼できるセーフティ反応を提供しません。
このような障害はハードウェアセーフティパスを通じて処理されるべきです:
PMC → FCCU → MC_RGM → リセット
これはR3 FCCU反応に対応し、完全にハードウェアベースでソフトウェア実行に依存せずにチップ機能リセットを開始するものです。S32K3セーフティマニュアルには、R3故障に関するまさにこの挙動が説明されています。
完全なISRおよびSPIトランザクションに対して、明示的に有効なMCU実行を保証する未公開の仕組みや早期警告電圧閾値がない限り、提案された割り込みベースの復旧はアーキテクチャ的または機能安全の観点から正当化されません。
NCF[4]を割り込み後にSBC主導のPORで処理し、電圧違反後に有効なソフトウェア実行を保証するアーキテクチャ上の前提を添えて、正確な文書と改訂版を提供していただけますか?
この点が明確になるまでは、割り込みによるリカバリの実装はお勧めしません。
よろしくお願いいたします。
ピーター
こんにちは、
上記の回復メカニズムは、S32K3リファレンスマニュアル(Rev 8, 2024年1月)に添付されたNXPの故障マップ文書に記載されています。
はい、これはあくまで推奨事項です。セーフティに関わるシステムでは絶対に使いません。
さらに、私たちの場合は電源がSBC FS65で構成されており、これはMCUの電源供給に使われているため、MCUをリセットするだけではSBCが生成する電源を安定させることはできません。
安定はしませんが、リセットすればMCUは安全な状態になります。つまり、破損した可能性のある命令は実行されません。
もし電源に一度だけのイベント情報(例えばシールドの弱さによるインダクタンス)がある場合、SBCは正しい電圧でMCUを供給しますが、MCUの実行は損なわれます。したがって、割り込みからリセットを呼び出すのは私には意味が分かりません。
アップデート：
この問題についてセーフティチームに相談していました。
また、過電圧や低電力レールでの低電圧警告にはNCF[4]が呼ばれます。
電圧降下の場合はPOR(電源リセット)が実行されます。
LVD（低電圧検出）→警告→割り込み
LVR（低電圧リセット）-> POR
HVD -> 通知 -> FCCU NCF4
過電圧／合否判定障害はFCCU NCF4を介して伝播する。
LVDは早期警告通知です。
LVRはFCCUを完全に迂回し、直接PORに向かいます。
よろしくお願いいたします。
ピーター