RTOSの間欠的クラッシュ：ログ、コアダンプ、再現試験

RTOSの間欠的クラッシュは、再起動前に適切な証拠を残すことで調べやすくなります。障害のたびにコンソール出力を増やすだけでは、タスクのタイミングが変わり、「どのビルドか」「どの実行コンテキストが停止したか」「直前に何が起きたか」が分からないままになりがちです。

本手順はRTOSを使うMCU向けです。例外レジスター、保持RAM、ダンプ機能は実際のチップとソフトウェア版に合わせます。例は診断設計であり、Obeita製品の実測障害報告ではありません。

1. クラッシュと呼ぶ前に症状を分類する

CPU例外、ウォッチドッグリセット、電圧低下、明示的なソフトウェア再起動、アプリケーション停止を区別します。割り込みは動くがコマンドを処理しない状態と、給電が失われた状態は別物です。起動コードが消去する前の可能な限り早い段階でリセット原因を読み、複数ビットが立つ場合の解釈も記録します。

元ビルド、対応ELFなどのデバッグイメージ、リンカーマップ、設定、コンパイラー情報を保存します。別版のバイナリーでPC値を解析すると、もっともらしい無関係な行を指すことがあります。起動表示と永続診断にビルドIDを入れ、対応成果物を機器の外に保存します。

可能なら電源波形と外部実行指標も取ります。ロジックアナライザーでGPIOハートビートを観測すれば、電源降下より先にソフトウェアが停止したかを確認できます。ログのないリセットをすべてスケジューラー不具合と考えないでください。

2. 上限のあるイベント履歴を作る

無制限のテキストより、コンパクトなリングバッファーが有効な場合があります。単調時刻またはtick、イベントID、タスク・割り込みコンテキスト、処理番号、小さな引数を記録します。要求投入、DMA開始、完了確認、バッファー解放などの状態遷移を残します。所有権が問題なら全バイト記録は必須ではありません。

並行処理モデルを明確にします。単一書き込み元と複数書き込み元では同期方法が異なります。割り込み内から、中断されたタスクの持つmutexを待ってはいけません。マルチコアでは自コアの割り込み禁止だけで他コアを直列化できません。独自ロガーに正当性試験がなければ、プラットフォームの公式トレース機能を優先します。

バッファー周回、欠落数、時刻周回、満杯時方針を記載します。Zephyrは即時処理・遅延処理と設定可能なバッファーを提供しますが、実行文脈と遅延は変わります。ログ機能を使っても時間コストは消えません。対象版のZephyrログ文書を確認します。

3. 最小限の故障スナップショットを残す

例外理由、関連CPUレジスター、実行コンテキスト、失敗経路を復元するのに必要なスタックを採取します。対応Cortex-Mでは故障状態レジスターと例外スタックフレームが有用ですが、存在するレジスターと構造はコア機能や例外状態で異なります。万能なHardFaultコードをコピーせず、実際のアーキテクチャ用の処理を使います。

故障ハンドラーは疑わしい機能に依存させません。メモリー割り当て、通常mutex、複雑なドライバー経由の表示は二次障害を招きます。採取時間を制限し、不完全記録を識別し、保存途中の再リセットも考慮します。故障時のFlash書き込みでは、コード実行場所、電源、ドライバー状態を特に確認します。

ESP-IDFでは、設定した先へタスク状態を保存し、対応ビルドで解析できます。ただし採取範囲と容量は設定依存です。ダンプ成功は必要な全バッファーの取得を保証しません。Espressifの手順に従い、実機で抽出を確認します。

Zephyrにも設定可能な出力先とメモリー採取範囲があります。オフライン解析ではダンプとアプリケーションELFを使います。別実装なのでコマンドや形式を混同しないでください。Zephyrコアダンプガイドを参照します。

4. 例外を待たずにハングを観測する

CPU例外にならないデッドロックもあります。収集完了、仕事の消費、状態機械の進行など、実際の成果で進捗を測ります。ループ冒頭でハートビートを書くだけでは、有効な処理が永久停止していても正常に見えます。

監視機構が必要な進捗を評価してからハードウェアウォッチドッグを更新します。動作モード別の必須タスクと正常処理の許容時間を定義します。そうしないと更新、無線校正、深い睡眠への移行をハングと誤認します。タスク状態を無視する無関係なタイマー割り込みからの給餌は避けます。

診断ビルドではキュー占有、割り当て失敗、タスク状態、観測したスタック余裕を定期採取し、頻度を制御します。空きメモリー減少は調査の手掛かりですが、意図的なキャッシュやプールの充填中などは、それだけでリークと断定できません。

5. 現場の説明を制御可能な再現条件にする

基板版、ビルドハッシュ、電源、周辺ファームウェア、入力、乱数seed、コマンド列、経過時間を再現表にまとめます。許可される範囲で障害トラフィックを残し、共有前に認証情報と不要な個人データを除きます。

• 負荷の相互作用：関係する生成処理を組み合わせ、一つずつ速度を上げます。与えた負荷と受理された負荷を記録します。
• 資源不足：対応テストフックで割り当て失敗やキュー満杯を発生させます。無制御に資源を枯渇させず、エラー経路を確認します。
• 時間窓：試験ビルドで疑わしい所有権移転付近に制御された遅延を入れ、どの遅延で発生したか記録します。
• 切断と再接続：電気的安全限界内で、特定の状態遷移時に周辺機器や試験ネットワークを切断します。
• カウンター境界：対応する時刻・番号周回の模擬試験を行います。稼働時計を無計画に変更し、その副作用を元の障害と取り違えないでください。

正常と分かっている構成から開始し、対照実行を残します。ログ有効化で消えるなら、イベント内容を同じにしてログコストと転送先を変えます。時間依存を示唆しますが、原因の競合までは特定しません。

6. 証拠は結論ではなく時系列として読む

コピー処理での故障は、それ以前のメモリー破壊が原因かもしれません。最後の正常な所有権移転、アドレスと長さ、割り当て寿命、割り込み文脈を比較します。タイムアウトでプールへ返却済みのバッファーに完了通知が届いていないか確認します。デッドロックでは各資源の所有者と、その所有者が実行可能かを調べます。

不自然なバックトレースは、まずELF一致、スタック破壊、巻き戻し制約を確認します。記録が残らなければ、意図的な故障で採取経路を独立に試験します。保持RAMは通常特定のリセットでのみ維持され、任意の電源断には耐えません。実際のリセットと起動を測定します。

7. 回帰試験を残して修正を完了する

有効な修正は、破られた不変条件、最小トリガー、改善後の動作を説明します。旧版と修正版で再現試験を繰り返し、合意した広い負荷も実行します。間欠故障が絶対に起きないとは言わず、期間、回数、未試験条件を示します。

引き渡しには採取設定、解析手順、対応シンボル、代表ログ、回帰試験を含めます。ObeitaのESP32-S3 Edge DTUプロジェクト構成はシリアル、ネットワーク、離散I/Oがあり、合意した複合負荷が必要になる範囲例です。公開済みクラッシュ調査ではありません。証拠一式の設計にはファームウェア・BSP診断を参照してください。