こんにちは。ここ数ヶ月、T1024のCPUに問題が発生しています。
よろしくお願いします。
問題の説明：
私たちはインダストリアルPLC内でT1024NSE7KQA CPUを使用しています。
昨年まではMQX OS(シングルコア実装)を使っていましたが、その後SDKLINUXを使ってデュアルコアLinuxに移植しました(OSは主にサードパーティによって実装されています)。
ハードウェアは、以前のMQX OSバージョンと物理的に同じです。
すべてのユニットがLinuxの起動時に問題を示します:MCUが固まる(MCU自体がRESET_REQ_Bを主張します)。
このイベント情報はデターミニスティックではなく、起動サイクルの10%のみが影響を受けますが、常に同じOS起動フェーズで発生します。
定期的な起動・電源オフのシーケンスを実行することで、この問題を再現することができました。
イベント情報が電源アップ後に発生する場合、それはハードウェアの起動・初期化から常に約40秒後に発生し、OS起動完了から5〜8秒後に発生します(起動からイベント情報までの時間はOSのプロセススケジュールのわずかな変動によりわずかに変わります)。
そうしないとイベント情報は再び表示されず、電源サイクルを待つ必要があります。
RCWは正しく、PBLフェーズも正しく完了します。
オシロスコープでイベント情報前にO1VDD、OVDD、G1VDD、VDD、VDDCのレール電圧を確認しましたが、安定していてCPU許容範囲内です。
イベント情報中にRESET_REQ_B:H->L遷移を測定しました。
RESET_REQ_Bから搭載回路への搭載接続を中断して(RESET_REQ_BがHRESET_BやPORESET_Bの遷移を強制しないように)、同じ起動サイクルまたは次のサイクルでDCFG_CCSR_RSTRQSR1レジスタを読み込みましたが、結果としては常に 0x0 値になります。CPUが内部的にリセットを要求しているのは確かですが、その理由が見つかりません。
OSログに最大字数を設定しましたが、問題のある起動時にはイベント情報直前には何も違いが見られません(問題のないスタートアップと比べて):カーネルメッセージなし、プロセスメッセージなし、例外なし、...
私たちはUARTを通じてDCFG_CCSR_RSTRQSR1レジスタを定期的にログしています。イベント情報終了後、CPUはそれ以上何も書き込めません。
リセットの原因をすべてマスクしようと試みましたが（DCFG_CCSR_RSTRQMR1 の予約されていないビットをすべて 1 に設定）、問題は依然として発生しています。
質問：
• DCFG_CCSR_RSTRQSR1にマッピングされていないRESET_REQ_Bの原因はありますか？DCFG_CCSR_RSTRQMR1で非予約の部分はすべてマスキングしましたがうまくいきませんでした。
• どのCPU機構がRESET_REQ_Bを要求したのか、どうやって掘り下げればよいのか?
• CPUが低消費電力のパワーマネージメント状態に入り、したがって RESET_REQ_B をアサートできますか？
ご説明ありがとうございます。
ジャコモ・ガスパリーニ。
ちなみに、公式アカウントにアクセスできませんが、こういった問題をサポートするためのリファレンスメールはどれですか？ありがとう
こんにちは、
ご 質問 3点 について ：
1) DCFG_CCSR_RSTRQSR1 に マッピングされ ていない RESET_REQ_B 原因 は あります か ？
はい： CPU/コア ウォッチ ドッグタイマーの リセット要求の 原因は RSTRQSR1 には マッピング されません 。 ウォッチ ドッグ リセット 要求 モード に 設定されている 場合、 それら は DCFG_CCSR_RSTRQWDTSR に キャプチャされ ます 。T1024 RM に は、 RSTRQSR1 コア ウォッチ ドッグタイマー ソース を除外し 、 RSTRQWDTSR 専用 の ウォッチ ドッグ ステータス レジスタ である と 明記されています 。
文書化されたウォッチドッグ以外の原因については、 RSTRQSR1は少なくとも次のものが含まれます: IFC_RR 、 WDT_RR ( RSTRQWDTSRで少なくとも1 つのウォッチドッグビットが設定されていることを示す要約)、 SW_RR 、 CCM_RR 、 PBL_RR 、 SFP_RR 、 SEC_RR 、 SDC_RR 、 MBEE_RR 、 RPTOE_RR 、およびSRDS_RST_RR 。
2) どうや ってさらに 掘 り下げるか?
次に 最も 有用な 手順 は 、 RSTRQSR1 だけ でなく 、 同じ 失敗した ブート サイクル で より広範囲の リセット スナップ ショット を取得する こと です 。以前の T1024 サポート ケース では 、 推奨 される レジスタ セット は DCFG_CCSR_RSTCR 、 DCFG_CCSR_RSTRQPBLSR 、 DCFG_CCSR_RSTRQMR1 、 DCFG_CCSR_RSTRQSR1 、 DCFG_CCSR_RSTRQWDTMR 、 DCFG_CCSR_RSTRQWDTSR でした。
症状 の タイミング(Linux が完全に 起動し、 その後 5 〜8 秒 後に 故障 が発生する) を考慮する と、 注目 すべき フィールド は以下の通りです:
RSTRQWDTSRスレッドごとのウォッチドッグの有効期限詳細RSTRQSR1[SW_RR]ソフトウェア がDCFG_CCSR_RSTCR[RESET_REQ](ビット 30) を直接 または リセット 経路 で 書き込む 場合RSTRQSR1[RPTOE_RR]コア 停止/停止/リセット 要求 処理 に関連する RCPM タイムアウト リセット 要求 イベント の場合RSTRQSR1[MBEE_RR] プラットフォーム内部 メモリ 用マルチ ビット ECC- 有効な SerDes PLL の
RSTRQSR1[SRDS_RST_RR] がロックされ ません
ソースコードに基づいた デバッグ に関する いくつ かの 考察：
RESET_REQ_Bいつでも アサート される 可能性があり 、 一度 アサートされると 、PORESET_BPORESET_B アサートさ れる まで アサートされた まま に なります 。- 設計 チェックリスト では 、 デバッグやRCW オーバーライド シナリオのために
RESET_REQ_BをPORESET_BまたはHRESET_B から切り離 す オプション を 残すこと を推奨 しています 。 なぜなら 、 リセット ループ が繰り返される場合、診断 が困難になる から です。 - 同様の ケース における NXP のサポート ガイダン スでは、 CPLD は壊 滅的な 内部 イベント情報 後の 実用 的な
RSTRQSR1記録 装置 として は一般的に は存在しない と されています 。 リセット レジ スタ を 読み取 る デバッガ は SoC の関与 を 最小限 に抑える ことが より 実用 的と考えられ ています。
So, with the ドキュメント I found, the most direct debug approach is:
- デバッグ 中に
RESET_REQ_B即座 に POR パス を引き起こさない ように してください 。 RSTRQSR1とRSTRQWDTSR、 さらにRSTCR、RSTRQPBLSR、 および マスク レジスタ の 両方 を取得します 。- 可能であれば 、
RESET_REQ_Bアサートされた 直後 、 かつ 外部 リセット が伝播する 前 に 、 JTAG を使用して 停止してください 。
3) CPU が 低消費電力 状態 に入 り、 それによって RESET_REQ_B を 主張 できるか?
標準 的な T1024 電源管理 状態(PH10/ドーズ、 PH15/睡眠、 LPM20/睡眠) については 、 取得した T1024 のドキュメント では 、これらの 状態 への 進入 が RESET_REQ_B 原因 として 記載 されていません 。これらの モード は 入力 され RCPM 制御 を通じて 終了します ウェイクアップ イベント情報、 割り込み、 ハード リセット、 または その他の 文書化された ウェイク メカニズムによって。
ディープ スリープ は 異なります。 ディープ スリープ からの復帰時には、EPU 有限 状態 マシン が 終了 時 に ウォーム デバイス リセット を 明示 的に 要求します （ Exit.2: XTRIG[9]: Request warm device reset ）。
また、 ホワイト ペーパーの Linux サスペンド/ディープスリー プフロー には 、EPU が ブート コード 再開 前に ディー プスリープ のウェイク アップ の 一環 として デバイス ウォーム リセット を発行 すると 書かれ ています。
しかし、 それ は ディープスリープからの 復帰メカニズム で あり 、 通常 の 実行 中に PH10/PH15/LPM20 に入った 場合の 通常 の 結果で はありません 。
よろしくお願いします。
まず、詳細かつ迅速なご回答をありがとうございました！
1) ご回答に基づき、DCFG_CCSR_RSTRQWDTSRレジスタ値0x3を使用してウォッチドッグリセットの原因もマスクしようとしましたが、問題は解決しませんでした。
2) CodeWarrior TAPを使用してJTAG経由でレジスタを読み取ることができました。イベント直後に「Suspend」コマンドを出し、以下のレジスタ値を読みました:
原因はソフトウェアリセット(DCFG_CCSR_RSTRQSR1[SW_RR]=1)のようです。
これは、RESET_REQ_B の原因が DCFG_CCSR_RSTRQMR1 レジスタでマスクできないという事実と一致しています。これが、この問題が繰り返し発生する理由です。
このリセットの原因について調査中です。
3) 私の最初の質問では、原因と結果が逆でした。CPUが低電力状態に入り、その後でRESET_REQ_Bアサーションが発生する可能性はありますか？
もしよろしければ、最後に今日行ったCPUレジスタ読み取りの試行中にCPUからJTAG TAPへの接続問題に関する関連質問を追加します。
CodeWarriorのTAPをCPUに接続した状態でCodeWarriorにSuspendコマンドを出した後、CPUレジスタを読み取れたのは1回だけでした。それ以外の試行錯誤は毎回出てしまい(写真参照)、CPUとの接続が切れてしまいました。
CodeWarriorの設定の問題でしょうか？どうすれば解決できるでしょうか?
改めてありがとうございました。
ジャコモ。