こんにちは、NXP。現在、S32K312 MCUを使ったプロジェクトに取り組んでいます。
現場で不具合のある製品に遭遇したため、お問い合わせさせていただきます。不良ユニットの解析中に、正常ユニットのダンプファイルと正常ユニットのダンプファイルを比較したところ、両者の特定の領域に違いが見られました。
左の写真は通常のDUMPファイルで、右の写真は高品質なDUMPファイルです。
この不具合は、暗電流の問題に関連しています。Trace32経由でアクセスしたところ、コントローラの スリープ処理中にウォッチドッグが継続的にリセットをトリガーしていることを確認しました。
左側の画像は正常なダンプファイルを示しており、右側の画像は欠陥のあるダンプファイルを示しています。
.mapを確認するとこの問題はLINセクションに関連しています(Mcal_LIN)。私たちのプロジェクトではLINトランシーバーは使っておらず、LIN関連機能はブロックされています。
私たちは2つの可能性を検討しています。
1. 書き込みプロセス中のノイズによるデータ改ざん
2. 現場のノイズによるCodeFlashの改ざん
現場で静電気や停電によるノイズがCodeFlashエリアの改ざんを引き起こす可能性はありますか?Wdgによるリセットはスリープモードに入ると発生します。このWdgリセットの原因を特定する方法はありますか？
こんにちは、 @jeongwoo さん。
これはSレコードで、タイプはS3、バイト数は0x25です。
レコードはアドレス0x0046D0E0から始まります。
データペイロードではアドレス0x0046D0F8の4バイトのみが異なり、0x11 00 02 00が0x40 78 09 78に変更され、Sレコードのチェックサムもそれに合わせて0x89から0x63に変更されます。
注目すべき点は、ビットが1から0、そして0から1へと両方向に反転されることである。
NORフラッシュでは、ビットは1から0までしかプログラムできません。0から1に少し切り替えるには、まずセクター消去が必要です。
したがって、0から1への遷移は単純なプログラミング操作の結果ではありえません。
消去せずにビットを0から1に変更するには、分離された浮遊ゲートから電荷を除去する必要があり、そのためにはエネルギーと放電経路の両方が必要となる。EMIはこれを提供できません。浮遊ゲートを放電させるのに十分なエネルギーを持つESDは、ほぼ確実に広範囲にわたる損傷を引き起こすだろう。SEUに関しては、4つの異なるバイトにわたって多数のビット反転が観測された。
より可能性の高い説明としては、欠陥のあるユニットは最初から異なるバイナリでプログラムされており、初期生産時のプログラミング以降、フラッシュメモリの内容は一度も変更されていないということが考えられる。その場合、フラッシュに保存されたECCチェックサムはデータと整合し、フラッシュを読み取ってもECCエラーは報告されません。これを確認していただけますか?プログラミング後に内容が破損した場合、アドレス 0x0046D0F8 のフラッシュを読み取ると ECC エラーが発生するはずです。TRACE32 から読み取ったときに、この場所に ???? が表示されますか？さらに、DCMROD4[12]を読んでいただけますか?
ウォッチドッグリセットについてですが、どのウォッチドッグのことでしょうか？それはSWT、外部ウォッチドッグ、またはPOR_WDOGのいずれかである可能性があります。
SWT（または外部ウォッチドッグ）のリセットは、ウォッチドッグが処理されない場合にトリガーされます。これは通常、実行がループに陥っていることが原因です。もしそうなら、ウォッチドッグを無効にしてデバッガをMCUに接続して、実行が停止する部分をキャプチャすることはできますか?POR_WDOGリセットの場合は、レジスタDCMROPP1～DCMROPP4を読み取ってください。より詳細な情報が得られます。
よろしくお願いいたします。
ダニエル