タスクごとのウォッチドッグでは、すべてのタスクがウォッチドッグを開始できるように、優先度の高いタスクが適切な時間に渡される必要があります。どのタスクに問題があるかを判断するには、他のタスクを枯渇させているタスクを見つける必要があります。実際の原因を突き止めるには、ウォッチドッグ チェック間のタスク実行時間を測定する必要があります。
これは先制ですか？そうしないと、他のタスクのいずれかがスタックした場合にウォッチドッグ タスクが実行されないためです。
OSについては言及していませんが、ウォッチドッグタスクが単一のタスクがチェックインしていないかどうかを確認できる場合、各タスクとウォッチドッグの間に個別の通信チャネルが必要です。
おそらく、ウォッチドッグを変更して、チェックインしていないタスク番号を何らかの方法でダンプし、タスク制御ブロックとメモリをダンプして、事後分析を行う必要があります。
OS によって、これは簡単な場合と難しい場合があります。
私もここ数週間、ウォッチドッグのリセット問題に取り組んでいました。しかし幸いなことに、(ARM 開発環境の) ramdump ファイルには、1 つの割り込みハンドラー トレース バッファーがあり、各割り込みに PC と SLR が含まれています。したがって、トレース バッファから、WD のリセット前に実行されていたコードの部分を正確に見つけることができました。
割り込みごとに PC、SLR を格納する同じようなメカニズムがあれば、犯人のタスクを正確に見つけることができると思います。
システムは正確にどのように機能していますか? 私は常にソフトウェアとハードウェアのウォッチドッグを組み合わせて使用しています。説明させてください...
私の例では、プリエンプティブなリアルタイム カーネルを使用していて、CPU/マイクロコントローラーでウォッチドッグがサポートされていることを前提としています。このウォッチドッグは、一定時間キックされなかった場合、リセットを実行します。次の 2 つのことを確認します。
1) 定期的なシステム タイマー (「RTOS クロック」) が実行されている (そうでない場合、「スリープ」などの機能が機能しなくなり、システムが使用できなくなります)。
2) すべてのスレッドは妥当な時間内に実行できます。
私の RTOS (www.lieron.be/micror2k) は、RTOS クロック割り込みハンドラでコードを実行する可能性を提供します。これは、ハードウェア ウォッチドッグを更新する唯一の場所であるため、クロックが常に動作していることを確認できます (そうでない場合、ウォッチドッグはシステムをリセットします)。
アイドル スレッド (常に最低の優先度で実行) では、「ソフトウェア ウォッチドッグ」が更新されます。これは、変数を特定の値 (たとえば 1000) に設定するだけです。RTOS クロック割り込み (ハードウェア ウォッチドッグをキックする場所) で、この値をデクリメントしてチェックします。0 に達した場合は、アイドル スレッドが 1000 クロック ティックの間実行されていないことを意味し、システムを再起動します (ハードウェア ウォッチドッグを再起動させるために、割り込みハンドラ内で無期限にループすることで実行できます)。
元の質問に進みます。システム クロックは動作し続けると想定しているため、システムをリセットするのはソフトウェア ウォッチドッグです。RTOS クロック割り込みハンドラでは、ソフトウェア ウォッチドッグの状況が発生した場合に備えて、いくつかの「統計収集」を行うことができます。システムをリセットする代わりに、(問題が発生した後) 各クロック ティックでどのスレッドが実行されているかを確認し、何が起こっているかを調べることができます。理想的ではありませんが、役に立ちます。
もう 1 つのオプションは、異なる優先順位で複数のソフトウェア ウォッチドッグを追加することです。アイドル スレッドで VariableA を 1000 に設定し、(専用の) 中優先度スレッドで Variable B を設定します。RTOS クロック割り込みハンドラで、両方の変数をチェックします。この情報により、ループ スレッドの優先度が「中」より高いか、「中」より低いかがわかります。必要に応じて、3 つ目または 4 つ目、または好きな数のソフトウェア ウォッチドッグを追加できます。最悪の場合、使用される優先度ごとにソフトウェア ウォッチドッグを追加します (ただし、余分なスレッドが必要になります)。
割り込み駆動のウォッチドッグの場合、タスク スイッチャーが現在実行中のタスク番号を変更するたびに更新するようにするだけで、どのタスクが生成されなかったのかを特定できます。
ただし、ウォッチドッグを自分でタスクとして作成したことをお勧めします。したがって、再起動する前に、ウォッチドッグは飢えたタスクを確実に識別できますか? これは、ウォーム リブート後も保持されるメモリに保存するか、デバッグ インターフェイス経由で送信できます。これに関する問題は、飢えたタスクはおそらく問題のあるタスクではないということです: 原因を特定するために、最後のいくつかのタスク スイッチ (および時間) を知りたいと思うでしょう。
単純化されたナプキン アプローチの裏側は次のようになります。
int8_t wd_tickle[NUM_TASKS]
void taskA_main()
{
...
// main loop
while(1) {
...
wd_tickle[TASKA_NUM]++;
}
}
... tasks B, C, D... follow similar pattern
void watchdog_task()
{
for(int i= 0; i < NUM_TASKS; i++) {
if(0 == wd_tickle[i]) {
// Egads! The task didn't kick us! Reset and record the task number
}
}
}