マイクロコントローラー回路のデバッグにおける冒険

マイクロコントローラー回路のデバッグにおける冒険 2026年8月30日 | カテゴリ: Floppy Emu | 著者: Steve 誤作動するマイクロコントローラー回路のトラブルシューティングはどのように行いますか？数ヶ月前、私は新しいバッチのFloppy Emuディスクエミュレーターを製造しました。そのうちのいくつかは工場でQAを通過できず、長年のこのデバイス開発で一度も見たことのない一連の症状を示しました。ほとんどのものは、電源が良好でMCUが正しくプログラムされていることを確認したにもかかわらず、まったく起動しませんでした。一部は「幽霊」のような動作を示し、プログラムコードのランダムなセクションにジャンプしているかのように見え、コンテキストを考えると無意味なメッセージを表示しました。一つはスローモーションで動作しているように見え、LEDの点滅やディスプレイの更新が通常よりも明らかに遅かったです。これは少なくとも奇妙でした。 私はATMEGA1284マイクロコントローラーとそれを囲むFloppy Emuの回路に多くの経験があり、誤作動するボードの症状に基づいて何が間違っているかを推測する専門家になりました。これらはすべて私にとって新しく奇妙な症状でした。これらは異なる問題から生じるのでしょうか、それともすべて一つの共通の根本的な問題を示しているのでしょうか？私の直感は、何らかの体系的な組み立て問題を示唆していました。私の契約製造業者は、このバッチのFloppy Emuボードのために新しい下請け業者を使用していたので、プロセスへの静かな変更が予期せぬ問題を引き起こしたのでしょうか？部品の交換？不良部品？偽造チップ？これらのQAの失敗は、回答を待って、数ヶ月間私の机の上の山に積まれたままでした。 プローブ、ポーク、そして理論化 昨日、私は「起動しない」デバイスに集中することにしました。それが最も対処しやすい問題のように思えたからです。私はいくつかのボードをテストハーネスに入れ、電源とハードウェアデバッガを接続しました。電源電圧は良好に見えました。はんだ付けの問題は明らかではありませんでしたが、念のためいくつかのボードのはんだをリフローしましたが、改善は見られませんでした。多くのボードでは、ハードウェアデバッガはマイクロコントローラーと通信でき、チップが正しく設定されプログラムされていることを確認できましたが、プログラムは実際には実行されていないようでした。起動時にボードは…何も起こりませんでした。そして、より少ない数のボードでは、デバッガはチップと通信することも、検出することさえできませんでした。 これらの症状を引き起こす可能性のあるものは何でしょうか？私はブレインストーミングしました：不良電源。私の測定によって除外されたようです。誤ってプログラムされたチップ。設定を確認し、いくつか再プログラムしましたが、改善しませんでした。不良チップ。リセットでスタックしたチップ。クロックの問題。他の回路コンポーネント（SDカード、CPLDなど）による電気的またはプログラム的な障害。不良マイクロコントローラーチップのバッチが最も可能性の高い説明のように思えたので、ボードからATMEGA1284をはんだ付けし、私のストックから新しいものと交換しました。しかし、チップを設定してプログラムした後、ボードは以前と同じように動作せず、起動を拒否しました。それはチップ自体の問題を排除したように思えました。 Floppy Emuのプログラムコードでは、デバイスが最初に起動すると、ディスプレイに何も描画される前に、SDカードとCPLDとの通信が行われます。私は、それらのステップ中に何かが間違って起こり、プログラムがフリーズまたはクラッシュして、空白のディスプレイにつながっているのではないかと疑いました。それをテストするために、プログラムを変更して、main()の開始時に他のことをする前に、証拠としてステータスLEDを20回点滅させるようにしました。はい、私の手元にあるすべてのハードウェアツールで、私はLED点滅による原始的なデバッグに戻っていました。しかし、まだ喜びはなく、LEDの点滅もなく、起動中のプログラム活動もまったくないようでした。一体どうなっているんだ？ ここで私は、良好なマイクロコントローラー、良好な電源、正しくプログラムされていることが確認され、長年正常に使用されている回路とボードデザインを持っています。それはLEDさえ点滅しませんでした。点滅はプログラムの最初のステップであるはずだったので、その不在は、SDカードのような他の回路コンポーネントとの相互作用の失敗に関連する説明をほとんど排除するように見えました。そのため、私は残された唯一の可能性であるリセット信号とクロックに焦点を当てました。 クロッククリスタルの謎 Floppy Emuのマイクロコントローラーは、速度と精度のために外部20MHzクリスタルを使用していますが、内部に8MHzオシレーターも内蔵しています。この特定のボードはまだハードウェアデバッガと通信できていたので、試しにチップのヒューズ設定を変更して、内部8MHzオシレーターをクロックソースとして選択してみました。驚いたことに、うまくいきました！デバイスは起動し、正常に動作しているように見えましたが、当然ながら通常の速度の40％でしかありませんでした。私は他のいくつかのボードでも同じ結果を確認しました――デバッガ通信を取得してクロックソースを内部オシレーターに変更できた場合、ボードは起動しました。これは修正ではありませんでした。Floppy Emuは8MHzオシレーターでは正常に動作しないからです。しかし、それは外部クロッククリスタルに重大な問題があることの証明でした。 外部クリスタルが確実に動作しない場合、マイクロコントローラーは信頼できるクロックソースを持ちません。おそらくまったく実行されないか、非常に不安定な動作をするでしょう。デバッガ通信にも問題を引き起こします。これらすべては、私の観察された症状とよく似ています。では、このクリスタル発振器回路について話しましょう。ほとんどすべてのマイクロコントローラーと同様に、ATMEGAシリーズには外部ピエゾクリスタルを駆動し、ピアース発振器と呼ばれる回路を使用して発振させるための組み込みアンプハードウェアがあります。動作理論についてはもっと知っているべきですが、私はほとんど無知です。 私が知っているのは、クリスタルの2つの端子を、可能な限り短いPCBトレースを使用して2つのATMEGAピンに接続し、ピコファラッド範囲の値を持つ2つの外部コンデンサを追加することです。その値は公式によって決定され、その後すべてが機能します。さらに調査したところ、問題のあるボードすべてが、以前使用していたものとは異なるクリスタルメーカーを使用していることがわかりました。それは問題ないはずですが、状況を考えると重要だと思われました。ボードの以前のエディションはこのNDKクリスタルを使用していましたが、これらの問題のあるボードは類似のECSクリスタルに交換されていました。どちらも同じ物理フットプリントを使用し、8pFの負荷容量を広告していました。 推測と次のステップ 今日現在、直接的なデバッグはここまでですが、決定的な説明を探し続けています。悪いクリスタルのバッチを手に入れたのでしょうか？可能性はありますが、ボードを修理してクリスタルを交換してみることはできます。しかし、その説明は私にはあまり可能性が高くないように思えます。発振回路の一部を形成する2つのコンデンサはどうでしょうか？それらの値は発振器の動作にとって重要であり、値が最適な値から大きく外れていると、クリスタルが正しく発振しないか、まったく発振しない可能性があります。これらの小さなSMDコンデンサにはマーキングがないため、視覚的に正しいコンデンサであることを確認する方法はありません。もしかしたら、下請け業者は一部のボードで間違った値のコンデンサを使用したのでしょうか？ そういえば、正しい値は何でしょうか？ここで、私はあまりよく理解していないピアース発振器のアナログの怪しげな領域に入ります。2つの外部コンデンサの正しい値は、Cext = 2 * (Cload – Cstray) という公式で与えられます。Cloadはクリスタルの負荷容量です。この場合8pFです。CstrayはマイクロコントローラーピンとPCBボードトレースの寄生容量の尺度です。これを直接測定する簡単な方法はありませんが、2層PCBの短いトレースの場合、約3pFから5pFの見積もりを見たことがあります。それを4pFと呼びましょう。したがって、Cext = 2 * (Cload – Cstray) = 2 * (8pF – 4pF) = 2 * (4pF) = 8pFとなります。理論的には、クロッククリスタルとペアで2つの外部8pFコンデンサを使用する必要があります。実際には、コンデンサは18pFです。18pFの外部コンデンサです。元の値をどのように指定したか覚えていません。Floppy Emuの初期開発段階の霧の中に失われています。しかし、それを再び見ると、確かにそれは…