こんにちは、チームの皆さん
お客様は、RTD 5.0.0を搭載した SAF パッケージSW32K3_SAF_1.0.6_CD02_D2508を使用しており、現在、MCU0 (S32K324) および MCU1 (S32K388) 用の FCCU モジュールの構成に取り組んでいます。
S32K324:
- Tresos で eMcem モジュールを構成しました。
- Tresos で Safebase モジュールを構成しました。
- アプリケーション ソフトウェアの起動シーケンスの一部として eMcem_Init() を呼び出しました。
- FCCU ペリフェラルは、Tresos 構成に従って設定されます。インジェクト機能を使用してテストし、ALARM ISR を正常にトリガーしました。
S32K388:
- Tresos で eMcem モジュールを構成しました。
- Tresos で Safebase モジュールを構成しました。
- アプリケーション ソフトウェアの起動シーケンスの一部として eMcem_Init() を呼び出しました。
- 問題: eMcem の初期化に失敗します。OPR 要求 (障害のクリア、状態の構成など) はいずれも機能していません。
BareMetal コードを使用して FCCU ペリフェラルを構成することをテストし、期待どおりに動作した場合、FCCU は正常に構成されました。S32K388 に関してエラッタや特別な考慮は必要ですか?
詳細は下記をご覧ください。追加情報が必要な場合はお知らせください。
ベアメタル構成:
アラームハンドラーISRは偽の注入によってトリガーされます
SAF パッケージのeMCEM モジュールを使用する場合、ステップ実行せずにコードを実行すると、コア リセットが発生します (このプロセス中にブート マネージャーに到達しないため、完全なマイクロコントローラ リセットではありません)。
ただし、eMcem_Init 関数を実行すると、 CONFIG状態への移行時に失敗します。このCASE、コア リセットは発生せず、システムはRUNNING状態に移行しますが、FCCUは未構成のままになります。
Tresos 構成: (前述のとおり、同じ構成が S32K324 でも動作します)
ここでのどんな助けも大歓迎です。
こんにちは@vamsilankaさん、
SAF 1.0.6 CD02 は RTD 6.0.0 でのみテストしたと思いますが、いずれにしても RTD バージョンはここでは問題にならないと思います。
以下を試していただけますか:
- Config タイムアウトが検出されて、appl_Fccu_Cfg_TimeoutCallback() に到達できるか試していただけますか?いいえの場合は、ISR 190 が有効になっていることを確認してください。
これは、FCCU によってタイムアウト イベント情報が検出されたかどうかを確認するためのものです。
- 構成されたロック タイプを SOFT_LOCK から NO_LOCK に変更し、それが機能するかどうかをもう一度試してください。
これは、内部関数 378,5: eMcem_Fccu_UnlockTrans() が期待どおりに動作するかどうかをテストするためのものです。
- FCCU_MAX_LOOP_COUNT_U8 を 20 から 200 に変更してみます。
お客様の時計設定に関してタイムアウトが十分かどうかをテストします。
これら 3 つの回避策を個別に試して、どれが機能するか教えてください。
敬具、
ラドスラフ
こんにちは@RadoslavB 、
お客様がデバッグ モードを有効にし、すべての構成が FCCU ペリフェラルに適用された状態でシステムが正常に CONFIG 状態になります。ただし、CONFIG 状態から NORMAL 状態には遷移しません。eMcem_Fccu_ExecuteOperationAndConfigureCtrlReg() 関数を複数回実行しましたが、結果は同じままでした。
さらに、デバッグ モードを有効にすると、fccu_configure までのコードをステップ実行しないと、システムが継続的にリセットされ、デバッグ ポートが失敗します。デバッグ ポートの障害のため、MC_RGM レジスタにアクセスしてリセットの原因を特定することができません。Trace32 に再接続するにはデバッガーで手動でリセットする必要があり、その結果、外部リセットが記録されます。
こんにちは@vamsilankaさん、
「デバッグ モードの有効化」を有効にしてみることもできます。RM ではあまり説明されていませんが、デバッグ中にタイムアウトがフリーズされる可能性があります。このオプションを有効にすると何らかの変化があるかどうかお知らせください。
私の側で試してみたところ、 eMcem_Fccu_ExecuteOperationAndConfigureCtrlReg() によるデバッグではオペレーションモードの変更が機能しないことが確認されました。そのため、FCCU オペレーションモードを適切に変更するには、この関数全体をステップオーバーする必要があります。RM には、この理由を説明する以下のヒントがあります。
ステップオーバーした eMcem_Fccu_ExecuteOperationAndConfigureCtrlReg() の呼び出しを除くすべての eMcem_Init コードをステップごとにデバッグでき、最終的に eMcem_Init() は BusFaults なしで OK を通過します。
リセットが発生した場合は、リセットステータスレジスタを確認し、根本原因を特定してください。FOSUリセットフラグの場合、何らかの障害が発生したものの、想定されたタイムアウト時間内に応答が実行されなかったことを意味します。この場合、どのFCCU/DCMROD障害が発生したかを特定してください。
Busfault についてですが、BusFault 発生時の StackFrame とすべてのシステム制御レジスタを表示できますか？FCCU init の実行で Bus Fault が発生するのは一般的ではありません。
また、OS はどの時点でも eMcem_Init の実行を中断してはなりません。OS スケジューラは他のタスクに切り替えていないと思いますか?
敬具、
ラドスラフ
こんにちは@RadoslavB 、
こんにちは@vamsilankaさん、
私の側ではこのシナリオを再現できません。
デバッグ モードを有効にし、ソフト ロックを適用しましたが、すべて期待どおりに動作します。
デバッグセッションを作成しましょう。
HW へのアクセスをブロックする設定がある場合は、MPU と XRDC を無効にしてみることができます。
OS がプロセスを中断していないか、常にスーパーバイザー モードになっているかを確認します。
関連するクロック FIRC、AIPS_PLAT_CLK を確認できます。
そして、実際の FCCU 障害がないかどうかを確認できます。
敬具、
ラドスラフ