マイクロコントローラーが予期せずリセットする原因は何ですか？

マイクロプロセッサで制御されたシステムで特にイライラするバグの1つは、マイクロプロセッサが予期せずリセットすることです。この種の問題をデバッグするための重要なツールは、考えられる原因のリストです。マイクロコントローラーが予期せずリセットする原因は何ですか？

PICおよびdsPICチップでは、次の予期しないリセットの原因が観察されています。

ハードウェア：

• リセットピンをローまたはフローティングに駆動します。最初に明らかなものをチェックしてください！
• リセットピンへのESD結合。これは、同じデスクでまったく関係のない機器の電源を入れたときに発生します。リセットピンに十分な容量、おそらく1 uFの容量があることを確認してください。
• プロセッサの他のピンへのESD結合。特にスコーププローブはアンテナとして機能し、ノイズをチップに結合し、奇妙なリセットを引き起こす可能性があります。「無効なオペコード」リセットコードの報告を聞いたことがあります。
• はんだ接合不良/断続ブリッジ。プロセッサまたはボード上のどこかで、電源レールを紛失または短絡している可能性があります。
• 電源レールのグリッチ/ノイズ。レギュレーターの損傷やアップストリーム電源の低下など、外部の問題が多数発生した可能性があります。プロセッサに給電する電源レールが安定していることを確認してください。どこかにもっと多くの上限が必要な場合があり、おそらくプロセッサの上限を直接切り離します。
• 一部のマイクロコントローラにはVcapピンがあります。VcapピンはVDDに接続しないでください。また、コモンへの独自のコンデンサが必要です。このピンを正しく接続しないと、予測できない結果が生じる可能性があります。
• アナログ入力を特定の制限を超えて負に駆動すると、RCONで電圧低下のようなレポートがリセットされます。同じことがデジタル入力にも当てはまります。
• 近くの電力変換器のdV / dtが非常に高いと、電圧低下リセットが発生する可能性があります。（この質問を参照してください。）これは2つのケースで見ましたが、1つでは容量結合まで追跡できました。IGBTが100〜200アンペアをスイッチングし、電源を切ると、3.3Vプロセッサで2Vから8Vを超える数マイクロ秒のノイズがフィードバック回路に発生していました。そのフィードバックレールのフィルターキャップを大きくすると、リセットが停止しました。トランジスタにdV / dtフィルタを追加すると、同様の効果が得られた可能性があると想像できます。

ソフトウェア：

• ウォッチドッグタイマー。ウォッチドッグタイマーは、特にEEPROM書き込みのように実行に時間がかかる可能性のあるコードのブランチでは、十分な頻度でクリアされるようにしてください。ウォッチドッグを無効にして問題が解決するかどうかを確認して、これをテストします。
• ゼロ除算。あなたが実行している場合は任意のコード内の除算演算を、必ず除数がゼロに等しくなることはありませんします。部門の前に境界チェックを追加します。これはモジュロ演算にも適用されることを忘れないでください。
• スタックオーバーフロー。ネストされた関数呼び出しが多すぎると、システムのスタックの動的メモリが不足し、コード実行の異常なポイントでクラッシュする可能性があります。
• スタックアンダーフロー。アセンブラでプログラミングしている場合、CALLを実行したよりも多くのRETURNを誤って実行する可能性があります。
• 存在しない割り込みルーチン。割り込みが有効になっているが、割り込みルーチンが定義されていない場合、プロセッサがリセットされる場合があります。
• 存在しないトラップルーチン。割り込みルーチンに似ていますが、十分に異なるため、個別にリストしています。ランダムにリセットされるdsPIC 30F4013を使用する2つの個別のプロジェクトを見てきました。原因は、呼び出されたが未定義のトラップに追跡されました。もちろん、なぜトラップが最初に呼び出されるのかという疑問があります。これは、シリコンエラーを含む、いくつもの可能性があります。ただし、すべてのトラップハンドラを定義することは、おそらく説明のつかないリセットを診断するための適切な初期段階です。
• 関数ポインターの障害。関数ポインターが有効な場所を指していない場合、ポインターを逆参照し、指された関数を呼び出すと、リセットが発生する可能性があります。これの面白い原因の1つは、NULL（関数ポインターの場合）および-1（intの場合）の連続値を使用して構造体を初期化したときでした。コンマがタイプミスされたため、関数ポインターは実際にNULL-1に初期化されました。したがって、CONSTであるという理由だけで、有効な値が含まれている必要があると想定しないでください。
• 無効/負の配列インデックス。すべての配列インデックス（上限と上限の両方）で境界チェックを必ず実行してください。に応じて、下限の。
• プログラムメモリの最大セクションよりも大きいデータ配列をプログラムメモリに作成します。これはコンパイルエラーをスローすることさえありません。
• 構造体のアドレスを別の型へのポインターにキャストし、そのポインターを間接参照し、間接参照されたポインターをステートメントのLVALUEとして使用すると、クラッシュが発生する可能性があります。この質問をご覧ください。おそらく、これは他の未定義の動作にも当てはまります。

一部のdsPICでは、RCONレジスタにリセットの原因を示すビットが格納されます。これはデバッグ時に非常に役立ちます。

RESETピンは、過電圧/不足電圧を監視し、十分な長さのリセット信号を生成するリセット回路によって適切に駆動する必要があります。それを念頭に置いて、制御されていないハードウェアリセットでの私の経験は、次に由来します。

• スイッチングラインからRESETピン/ラインへのクロストーク（短くする）
• 外部の高電流負荷のオン/オフを切り替えることにより生じるグランドシフト/ループ
• 電源によってフィルタリングされていない電圧スパイクで、適切なRESETをアクティブにするには短すぎます
• 上記の問題を引き起こすマイクロコントローラーによる外部負荷の切り替え（主にモーターのオン/オフ、リレー、または古いランプ（突入電流）などの誘導負荷で）
• マイクロコントローラピンのいずれかでの電圧/電流スパイク（最悪の場合は発振器）は、逆電流を引き起こし、内部レジスタを切り替える可能性があります（電源ラインの電圧スパイクと同じ）。一般に、ある種の産業環境に接続する場合は、注意を適用する必要があります（詳細については、http：//www.ichaus.biz/wp1_mcu_interfaceを参照してください）。IOのレベルシフト、入力フィルタリング、およびソフトスイッチング出力を考慮する必要があります。供給ラインをきれいにすることは、ハードウェア側の最優先事項です。次に、RESETピンと発振器ピン、次にIOライン。-mm

このリストになかったもう1つの可能性は、ICSPをサポートするデバイスです。回線シリアルプログラミングモードでトリガーするラインで不十分なプルアップが使用される場合、ランダムにそのモードに入ることができます。これにより、指定されたシリアルレシーバー回線にプログラムの更新が送信されない場合、少し後にリセットが発生します。ICSPが開始され、プログラミングデータが送信されない場合、内部ウォッチドッグタイマーが強制的にリセットされると思われます。これは私が犯した間違いであり、16F876を見つけるのに多くの時間を費やしました。

回路でCMOSまたはTTLロジックチップを使用している場合は、Vddとグランド（通常0.1 uF）の間に適切なデカップリングコンデンサがあることを確認してください。私はデザインでCD4021を使用していましたが、使用中にマイクロプロセッサを再起動させるスパイクが発生したようです。その後、サイクルが繰り返されます。これは、コードの開始時に明らかなテストシーケンス（LEDを数回点滅させるなど）を入れて、マイクロプロセッサが動作してコードを実行していることを確認することも良い理由です。

これは、ポップアップする可能性のあるまれなものの1つです。

マイクロコントローラーを含むプロジェクトがあり、散発的にリセットされました。要するに、一部のオプションは有効または無効にする必要があり、そうしないとリセットが発生する可能性があります。私は、他のすべてをあきらめた後、正誤表を読むことでこれを見つけました。

今では、チップを使って自分が何に夢中になっていて、それが何かを管理できるかどうかを知る前に、正誤表を読むことを習慣にしています。残念ながら、卒業後、私は一般的な慣行について私に教育する人を本当に持っていなかったので、私の実世界の学習の多くは失敗とフラストレーションを通してでした。