c - 割り込み処理モジュールをどのようにテストしますか？

Question

組み込みプロセッサの割り込みコントローラハードウェアを制御する割り込み処理モジュールがあります。今、私はそれにさらにテストを追加したいと思います。現在、テストは、ISR内から2つのソフトウェア割り込みを作成することによって割り込みのネストが機能するかどうかのみをテストします。1つは優先度が低く、もう1つは優先度が高くなります。このモジュールをさらにテストするにはどうすればよいですか？

Answer 1

他の刺激も作成することをお勧めします。

多くの場合、ハードウェア割り込みは、ソフトウェア（自動テスト）またはデバッガーによってフラグを設定することによってトリガーできます。または、I/Oを介した割り込みとして。またはタイマー割り込み。または、シングルステップ中にデバッガーを介して割り込みコントローラーの割り込みビットを設定することもできます。

発生するはずのないことについて、いくつかのランタイムチェックを追加できます。時々、外部で監視するように出力ピンを設定することを選択します（オシロスコープまたはロジックアナライザを使用している場合は便利です...）

low_prio_isr(void)
{
    LOW_PRIO_ISR=1;
    if (1 == HIGH_PRIO_ISR)
    { this may never happen. dummy statement to allow breakpoint in debugger }

}

high_prio_isr(void)
{
    HIGH_PRIO_ISR=1
} 

ソフトウェア割り込みの欠点は、モーメントが固定されることです。常に同じ命令。私はあなたがそれが常に機能するという証拠を見たいと思っていると思います。デッドロックフリー。

割り込みサービスルーチンの場合、コードレビューは非常に価値があります。結局、あなたはあなたが想像した状況をテストすることができるだけであり、ある時点でテストの努力は非常に高くなるでしょう。ISRはデバッグが難しいことで有名です。

次のテストを提供すると便利だと思います。-isrは優先度の低い割り込みに対して割り込みされません-isrは同じ優先度の割り込みに対して割り込みされません-isrは優先度の高い割り込みに対して割り込みられます-スタック制限内の最大ネスト数。

一部のテストは、インストルメンテーションとしてコードに残る場合があります（たとえば、最大ネストレベルを監視できます。

ああ、そしてもう1つ：私は通常、ISRを非常に短くして、ネストを控えることができます。可能であれば、これにより、さらに単純になり、パフォーマンスが向上します。

[編集] もちろん、ISRはシステムのハードウェアでもテストする必要があります。ビットごとの段階的なアプローチとは別に、次のことを証明する必要があります。-最大割り込み負荷でのシステムの安定性（できれば予測される最大負荷の数倍。115kbpsシリアルドライバーでも2MBpsを処理できる場合）大丈夫です！）-isrを有効/無効にする正しい瞬間、特にシステムがスリープモードに入る場合-割り込みの数。機械式スイッチ、機械式ロータリー（安定した状況に達するまでの数百の破損/接触モーメント）を追加すると、驚く可能性があります。

Answer 2

実際のハードウェアテストをお勧めします。割り込み処理は本質的にランダムで予測不可能です。

信号発生器を使用して、方形波を適切な割り込みピンに供給します。複数のジェネレーター（または複数の出力を備えたジェネレーター）を使用して、複数のIRQラインをテストし、優先順位の処理を検証します。

信号発生器で周波数を上下にダイヤルしてみて（それらの間でレートを変えて）、何が起こるかを確認してください。さまざまな状態の割り込みコントローラーの状態を確認するための診断コードがたくさんあります。

代替方法： プラットフォームに割り込みをトリガーできるタイマーがある場合は、外部ハードウェアの代わりにそれらを使用できます。

Answer 3

私は組み込み開発者ではないので、これが可能かどうかはわかりませんが、割り込みを処理するコードをコールバック登録メカニズムから切り離してはどうでしょうか。これにより、割り込みイベントを発生させるシミュレータコードを好きなように書くことができます...

Answer 4

このようなものについては、SPINモデルチェッカーのようなものを強くお勧めします。コードではなくアルゴリズムをテストすることになりますが、テストは徹底的に行われます。当時、私はこのテクニックを使用する際にバグを見つけました。gdb