embedded - トラップとは

Question

プロセッサのデータシートには、BusFault、MemManage Fault、Usage Fault、Address Error など、さまざまな種類のトラップがリストされています。

彼らの目的は何ですか？障害処理にどのように利用できますか?

Answer 1

トラップは基本的に、命令のストリームで異常を検出したときにプロセッサによって強制されるサブルーチン呼び出しです。(一部のプロセッサはそれらを割り込みにしますが、それはほとんどの場合、より多くのコンテキストをスタックにプッシュするだけです。トラップにユーザーとシステムのアドレス空間間の切り替えが含まれている場合、これはより興味深いものになります)。

これは、ゼロ除算など、めったに発生しないが対処する必要がある状況を処理する場合に役立ちます。通常、除数がゼロになることは想定されていないため、除算命令を実行する前に除数がゼロかどうかをテストする命令のペアを余分に用意しても無駄です。したがって、アーキテクトは、除算命令の一部として実際の除算と並行してプロセッサにこのチェックを実行させ、除数がゼロの場合、プロセッサをゼロ除算ルーチンにトラップさせます。もう 1 つの興味深いケースは、 illegal-memory-address です。明らかに、使用する前に各アドレスをチェックするテストをコーディングする必要はありません。

多くの場合、対象となる可能性のあるさまざまな障害状態があり、プロセッサは設計により、さまざまな種類の障害ごとに異なるトラップ ルーチン (多くの場合、ベクトルとして設定されます) に制御を渡します。

プロセッサがトラップ機能を持つと、CPU アーキテクトは多くの用途を見つけます。一般的な用途は、デバッガーのブレークポイント、およびオペレーティング システム コールを実行するための OS へのトラップです。

Answer 2

マイクロプロセッサには、さまざまな障害状態に対するトラップがあります。これらは、実行中の OS / ソフトウェアがエラーに対して適切なアクションを実行できるようにする同期割り込みです。割り込みプログラム フローをトラップし、レジスタ ビットを設定してフォルトを示します。デバッガーのブレークポイントもトラップを使用して実装されます。

一般的なコンピューティング環境では、オペレーティング システムがユーザー プロセスによってトリガーされた CPU トラップを処理します。次のプログラムを実行するとどうなるか考えてみましょう。

int main(void)
{
    volatile int a = 1, b = 0;
    a = a % b; /* div by zero */
    return 0;
}

エラー メッセージが表示され、何事もなかったかのようにボックスがまだ実行されています。この場合の障害処理に対する私のオペレーティング システムのアプローチは、問題のあるプロセスを強制終了し、ユーザーにエラー メッセージを通知することFloating point exceptionでした。

カーネル モードでのトラップは、より問題があります。OS 自体に障害がある場合、OS が是正措置を取ることはそれほど簡単ではありません。システム プロセスの場合、下層の保護層はありません。これが、欠陥のあるデバイス ドライバーが実際の問題を引き起こす可能性がある理由です。

オペレーティング システムによる快適な保護なしでベア メタルで作業する場合、状況は上記の状況とよく似ています。継続的で正しい操作を実現するための第 1 の目的は、アサーションと高レベルのエラー ハンドラーを使用して、トラップがトリガーされる前にすべての潜在的なトラップ条件をキャッチすることです。トラップは、意図的に陥りたくないセーフティネットである最後の防衛線と考えてください。

トラップ ハンドラーの動作を定義することは、たとえ「発生してはならない」場合でも、検討する価値があります。それらは、最も極端なケースで RAM を変更する宇宙線が原因で、予期しない方法で問題が発生したときに実行されます。残念ながら、エラー ハンドラが何をすべきかについて、唯一の正解はありません。

コード コンプリート、第 2 版:

最も適切なエラー処理のスタイルは、エラーが発生したソフトウェアの種類に依存し、一般的に、正確性や堅牢性が高くなります。厳密に言えば、これらの用語は互いに反対側にあります。正確性とは、不正確な結果を決して返さないことを意味します。不正確な結果ほど良い結果はありません。堅牢性とは、たとえ不正確な結果につながる場合でも、ソフトウェアが動作し続けることができるように常に何かをしようとすることを意味します。

明らかに、私のオペレーティング システムの障害処理は堅牢性を考慮して設計されています。システムをクラッシュさせることなく、欠陥のあるコードを実行し、ほとんど何でも実行できます。堅牢性のみを目的とした設計は、可能な限り回復を試み、他のすべてが失敗した場合はリセットすることを意味します。これは、製品がおもちゃなどの場合に適したアプローチです。

安全性が重要なアプリケーションにはもう少しパラノイアが必要であり、代わりに正確性を優先する必要があります。障害が検出された場合は、エラー ログを書き込み、シャットダウンします。放射線治療ユニットが無効なガベージ値から線量レベルを選択することは望ましくありません。

Answer 3

ARMv7-M (ARM7 や ARMv7-A と混同しないでください) Cortex-M3 テクニカル リファレンス マニュアルは、新しい ARM ARM (ARM アーキテクチャ リファレンス マニュアル) の一部でもある可能性があります。これらの障害。

なぜ、なぜ、何が問題なのかが、おそらく問題の根底にあります。その理由は通常、回復するチャンスがあるためです。セットトップ ボックスまたは電話がこれらのいずれかに衝突したと想像してみてください。これらの障害のいずれかを予期していない限り (このコンテキストでは、x86 システムとその障害の一部はまったく別の話です)、これらのいずれかをヒットするのに十分長く生き残った場合、トリガーを引く可能性が高くなります。あなた自身（プロセッサ/システムをリセットすることによって自分自身を殺そうとするソフトウェア）。長いリストを調べて、回復できるものを見つけることができます。ゼロで割ると、これにつながる数学の間違いが何であるかを例外ハンドラーが知るにはどうすればよいでしょうか? 一般的にはできません。アライメントされていないロードまたはストア、そのコードが何をしようとしているのかをハンドラーが知るにはどうすればよいですか? ゼロ除算のように、おそらくソフトウェアのバグです。未定義の命令、コードは雑草に入り、データを実行しました。おそらくこの時点までに、あなたはすでに行き過ぎており、回復できませんでした. ハンドラーがハードウェアを修復できない、あらゆる種類のメモリ バス障害。

すべての障害を経験する必要があり、障害ごとに、それを処理する方法、その 1 つの障害に到達する可能性のあるすべての方法、およびそれらのパスのそれぞれから抜け出す方法または処理する方法を定義する必要があります。場合によっては回復できるかもしれませんが、それ以外の場合はデフォルト アクションが必要です。たとえば、ハンドラーの無限ループでプロセッサをハングさせて、ソフトウェア エンジニアが利用可能であれば、デバッガーを使用して侵入し、どこにあるのかを見つけようとすることができます。コードが停止しました。または、チップとボードの設計に応じて、チップの内部または外部にウォッチドッグタイマーを配置します（多くの場合、チップの外部でWDTがボード全体をリセットします）。障害を保存しようとする不揮発性メモリがある場合があります。リセットを許可または発生させる前に、それを行うのにかかる時間とコードにより、障害の原因に応じて別の障害が発生する可能性があります。

Answer 4

簡単に言えば、プロセッサで何かが発生したときにコードを実行できます。これらは、エラー回復のために OS によって使用されることがあります。