2396971_ja-JP

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

2396971_ja-JP

2396971_ja-JP

S32G274 覚醒異常

こんにちは、NXPチームの皆様、

プロジェクトの背景:

当社では、同じ基板上に2つのS32G274チップを搭載しており、それぞれチップ1とチップ2と呼んでいます。チップ2はチップ1のバックアップとして機能します。つまり、チップ1が故障した場合、チップ2がその機能を引き継ぎます。

問題の説明:

両方のS32Gチップはコマンドに従ってスリープ状態に入ります。MCUはスタンバイに、PMICはスタンバイに入ります。CANやKL15で起こすことができます。ある特定のテストにおいて、チップ1は正常に起動して正しく動作したが、チップ2は正常に動作しなかったことが判明した。

PMIC電圧を測定したところ、PMICの出力は3.3V、1.8V、1.1V、5Vであり、PMICの電源電圧は正常でした。しかし、チップ2のシリアルポートには出力がなかったため、Aコアには入力されていなかった。当時、私たちはそれがブートローダーの段階で停止しているのではないかと疑っていました。

次にチップの温度を測定したところ、チップ1は50℃、チップ2は40℃だった。チップ2がどこで動作停止しているかを特定するために、チップ2の主電源を切断して再度電源を入れることで復旧させ、以下のテストを実施しました。

  1. チップ2を停止 while(1) Aコアをロードした際のループで、チップ温度は45℃でした。
  2. チップ2を停止 while(1) クロック初期化前のループ — チップ温度は42℃でした。
  3. リセットピンを継続的に短絡させることでチップ2を永久的にリセット状態に維持したところ、チップ温度は40℃となり、これは故障発生時に観測された温度と一致した。

問題の概要:

チップ2のウェイクアップ機能が異常な動作をしており、チップ2がリセット状態から抜け出せなくなっているのではないかと疑っています。しかし、正確な根本原因は依然として不明である。

原因の分析を手伝っていただき、今後もこの問題をどうやってデバッグできるかアドバイスをいただけませんか?

ご返信をお待ちしております。

よろしくお願いいたします、チェンイン

Re: S32G274 Wake-up abnormalityこんにちは、ジョーイ。

迅速なご対応ありがとうございます。ご質問への回答は以下にご記入ください。

質問1:Chip2を起動できない問題は非常に低い確率の問題です。私たちはほぼ1年かけて運用していますが、このケースは1件しか出会っておらず、再現が難しいです。

質問2:Chip1とChip2の両方がCANメッセージで起動します。Chip1とChip2のコードロジックは一貫しており、違いが生じる可能性があるのはメインロジックの実行とフェイルオーバー処理部分のみです。

質問3:待機入室の手順は以下のとおりです。

MコアはIPCFを介してAコアに通知する。
Aコアはシャットダウン手順を実行します。
AコアはPMICにスタンバイモードに入るようコマンドを送信する。
Mコアはスタンバイモードに入ります。
さらなる分析のために追加の情報やログが必要な場合はお知らせください。

ご返信をお待ちしております。

よろしくお願いします
Re: S32G274 Wake-up abnormality

こんにちは、Jerry_cao

もう少し詳しい情報を教えていただけますか?
1.チップ2を目覚めさせられない現象は、あなたの作品の中でのみ起こったことです。再現は可能でしょうか?
2. チップ1とチップ2はKL15を通じて同時に目覚めているのか?
3. スタンバイおよび起床プロセスは?MコアとAコアの両方が関係しているのでしょうか?MコアはまずAコアをオフにしてから、スタンバイ状態に入るのでしょうか?

BR

ジョーイ

Re: S32G274 Wake-up abnormality

こんにちは、 Jerry_cao

ご返信と詳細な情報、ありがとうございます。

1.チップ2が起動しなかった状況について、Mコアは起動しましたか?また、Aコアにはログはありますか?チップに関する有用な情報は得られましたか?

2. チップの正常な動作範囲内での故障ですか?
3. この問題が発生しているのは、この基板だけですか?他の掲示板でも同様の問題が発生していますか?温度測定だけでは、問題の分析には不十分かもしれない。自動テスト方法を導入して、問題が再発できるか試してみるのも良いでしょう。

BR

ジョーイ

Re: S32G274 Wake-up abnormalityこんにちは、ジョーイ。

引き続きご支援いただきありがとうございます。

さらに調査を進めた結果、根本原因は外部監視犬(GPTドライバ)のフィーディング操作に関連していることが特定されました。

現在の調査結果:

コードの冒頭で外部ウォッチドッグを無効にすれば、スタンバイ状態への移行とウェイクアップは問題なく正しく動作します。

外部ウォッチドッグをスタンバイモードに入る直前にのみ無効化した場合(メインロジック中は正常に動作している)、問題は依然として再現します。

これは、ウォッチドッグの給餌動作がスタンバイモードへの移行タイミングに干渉していることを示しています。現在の仮説では、PMICにスタンバイモードへの移行を指示するコマンドが、ウォッチドッグタイマーのフィード動作によって妨害され、タイミング違反が発生してデバイスが正しくスタンバイモードに移行できない可能性があると考えています。

質問:

ウォッチドッグフィーディング操作(GPTドライバー)がPMICスタンバイエントリコマンドのタイミングに影響を与える可能性があるかどうかの分析を手伝ってもらえますか?
PMICスタンバイモードへのエントリーコマンドには、従うべき特定のシーケンスやタイミング要件はありますか?
S32Gプラットフォーム上のウォッチドッグ周辺機器とPMICスタンバイエントリシーケンスの間に既知のタイミング制約はありますか?
ご返信をお待ちしております。

よろしくお願いします
タグ(1)
評価なし
バージョン履歴
最終更新日:
金曜日
更新者: