NXPサポートチームの皆さん、こんにちは。
以前発生したBISTのハードリセットの問題について:ご提案いただいた変更を適用したところ、BISTは正常にソフトリセットを実行するようになりました。
このソフトリセットに適応し、MCUクロックの初期化が二重になるのを避けるため、当初はアプリケーション内でMCUクロックの初期化を保持しました。しかし、BISTソフトリセットを実行してアプリを起動した後、時計の再初期化に異常に長い時間がかかっていた。この遅延とロックアップは、クロックがすでにブートマネージャーによって初期化されていたため、2回目の試み時に競合が生じたためと考えられています。
この極端な遅延を解消するため、アプリケーションからMCUクロックの初期化を完全に削除し、ブートマネージャーのみに残しました。残念ながら、これにより新たな問題が生じました。アプリケーションに切り替えた後、システムはペリフェラルの初期化(特にFlexCAN)中にフリーズし、クロックの可用性問題を示唆しています。
ここで正しいクロック設定戦略についてアドバイスいただけますか?具体的には、BISTソフトリセットがBMが初期化したクロックを妨げてアプリ内で再初期化が必要になるのか、またBMとアプリ間でロックアップや極端な遅延を起こさずに適切にクロックを渡すにはどうすればよいのか、ということです。
こんにちは、 @HazemIhab さん。
サポートチケットやコミュニティThreadの中には、以前のBISTハードリセットの問題は見つかりませんでした。
ST_DONEが機能リセットであることを理解しています。
リセット後はクロック設定がリセットされるため、初期化が必要です。
RTDドライバを使う場合、Clock_Ip_InitClock()関数はまずすべてのクロックをセーフステートにリセットします。これはおそらくブートマネージャとアプリケーションの両方でクロックを初期化した場合に見られる遅延です。
設定はブートマネージャーでのみ可能ですが、ドライバがアプリケーションに必要なすべてのクロック、つまりFlexCANクロックを有効にしていることを確認する必要があります。
また、すべてのシステムクロックは、RMに記載されているクロックオプションのいずれかと一致する必要があります。例:表156。オプションA - 高性能モード(CM7_CORE_CLK @ 160 MHz)(S32K388/S32K389用)。
BR、ダニエル
こんにちは、 @HazemIhab さん。
過失例外があると聞いていますが、確認できますか?
もしSOなら、例外が本当に時計に関係しているかどうかを確認するために、さらに詳しい情報を調べる必要があります。
https://community.nxp.com/t5/S32K-Knowledge-Base/Fault-handling-on-S32K14x/ta-p/1114447
例外が発生していないにもかかわらず、実行がループに陥っている場合、具体的にどの部分で発生しているのでしょうか?
また、前述したように、すべてのシステムクロックは、RM に記載されているクロックオプションのいずれかと一致する必要があります。表156。オプションA - 高性能モード(CM7_CORE_CLK @ 160 MHz)(S32K388/S32K389用)確認できますか?
ありがとうございました。
BR、ダニエル
こんにちは、 @danielmartynek さん。
ご説明ありがとうございます。
設定を明確にすると、ブートマネージャー(BM)とアプリケーション(アプリ)はすでに全く同じクロック構成を使っており、FlexCANのクロック設定も含まれます。
セーフステートリセットによる遅延を回避するため、BMにすべてのクロックを初期化させ、アプリからClock_Ip_InitClock()を削除しました。しかし、ジャンプ後にアプリがFlexCANを初期化しようとすると、システムはクロック関連のエラーでハングアップしてしまう。