こんにちは、チームの皆さん
お客様 香港海事博物館 現在テスト中 睡眠と起床機能 上の S32N55 プラットフォーム上で予期しない動作が発生しました。
システムが外部ピン(例えば、 FSS_WKUP2 上の S32N55-RDB )、両方とも 破壊的なリセット そして 機能リセット がトリガーされます。さらに、 PREV_MODE レジスターは フルパワーモード 予想通りではなく STDBY_MODE 。
次の設定を使用してこの動作を再現しました。
SW32N5_GRAYVIP_1_0_22_0Reset_Handler 。ウェイクアップ後、システムはループ内に留まり、FSS FW からの干渉を効果的に回避します。 PREV_MODE = FULL_POWER_MODE の代わりに STDBY_MODE ?サポートをよろしくお願いいたします!
よろしくお願いします、
唐勝
こんにちは、アリナさん。
スリープ時間は約6.7秒です(下図参照)。PMICプロトコル違反によりウェイクアップされることはありません。また、POR_Bは常にHighです。
よろしくお願いいたします。
唐生。
唐生さん、こんにちは。
はい、スタンバイ信号は監視されますが、その時間枠内にウェイクアップがトリガーされない場合、スタンバイ タイマーが期限切れになり、リセットが発生すると理解しています。
あなたが提供したキャプチャから、最初のリセットは PMIC プロトコル違反 (RESET_OUT_B のため、他の信号は正常) が原因で発生し、2 番目のリセットはソフトウェアによってトリガーされたと思われます (または、ウェイクアップ後に Wdg が Pmic に間に合うように利用できないことが原因である可能性があります)。
PMIC_STANBY_MODE_B が低いままである時間も教えていただけますか?
よろしくお願いします、
アリーナ
こんにちは、アリナさん。
スタンバイ タイマーは、スタンバイ モード中にタイムアウトが発生したCASEに、デバイスを Deep Fail-Safe (DFS) モードに自動的に移行するために使用されます。ウェイクアップ信号を監視する必要はありません。
スリープ機能をテストしたところ、このパラメータでうまく動作しました。
よろしくお願いいたします。
唐生。
唐生さん、こんにちは。
スタンバイ タイマー期間ウィンドウが約 1 秒 (1024 ミリ秒) に設定されていることがわかります。そのウィンドウ内にウェイクアップのトリガーを受信しない場合、PMIC は低電力状態を終了し、SoC は POR を受信します。CAN時間枠を長くしたり、スタンバイタイマーを無効にしたりすることはできますか?
よろしくお願いいたします。
アリーナ
こんにちは、アリナさん。
ご尽力ありがとうございました!
ご質問に関して、
1.私は 2 つのシナリオをテストしました。SoC が数十秒間スリープ状態のままの場合と、数分間スリープ状態のままの場合です。正確な数を記録しませんでした。両者とも同じような起床行動を示した。
2. テストでは、Tresos の Sleep_Mode 構成を使用しました。
よろしくお願いいたします。
唐生。
こんにちは、唐生です!
機能リセットの問題については認識しており、これは現在調査中の既知の制限ですが、これまで CSSI からの破壊的な問題に遭遇したことはありませんでした。
SoC がサスペンド状態のままになる時間を教えてください。また、pmic tresos 構成から Pmic スタンバイ ウィンドウにどのような値が構成されますか?
「もしSOなら、ウェイクアップ後にウェイクアップソース情報を保持または取得する別の方法はありますか?」というご質問についてですが、残念ながら現時点ではございません。FSSサブシステムの起動時にフラグを消去しています。しかし、この問題については認識しており、対処する予定です。
こんにちは、ラドゥさん。
サポートありがとうございます。ご返信をお待ちしております。
こんにちは@Tangsheng_Zhouさん
チームがこのCASEを引き受け、できるだけ早く回答を提供します。
こんにちは、チームの皆さん
リセットからのウェイクアップ時に WKPU モジュール レジスタがクリアされることを確認しました。
これは CSSI によってトリガーされた破壊的なリセットによって発生した可能性がありますか?
もしSOなら、ウェイクアップ後にウェイクアップソース情報を保持または取得する別の方法はありますか?
ありがとうございます。
唐生。
唐生さん、こんにちは。
はい、機能リセットまたは破壊リセットが発生した場合、WKPU レジスタはクリアされます。
rev C. ボードの場合、ウェイクアップ後に機能リセットが発生していることが確認されています。この問題についてはまだ調査中です。Rev. A ボードではこの機能リセットは発生しません。
CSSI 破壊リセットを解決するには、SXOSC の CMU を有効にしないでください ( SXOSC の CMU が有効になっている行を Power_Platform_RunModeToLowPower から削除します)。この CMU を無効にした後、破壊的なリセットは当社側では発生しなくなりました。