デバッグスパイラルからの脱却
デバッグスパイラルとは
組み込みCPUを搭載したボードを開発したときのことを思い出してみてください。基板が実装から仕上がってきた時、最初にすることは何でしょうか。
注意深く電源をつなぎ、煙や異様な発熱などがないことを確認したら、回路を設計したハードウェア技術者は、その設計した回路が正しく動作しているかどうかを確かめなければなりません。
しかし、基板がCPUを中心として構成されている場合、そのデバッグは困難を極めます。
なぜならば、回路や基板をデバッグする際には、基板上の中心部品であるCPUの端子を自由に操作することができなければなりません。CPUの端子に全く変化がなければ、回路は少しもデバッグできないでしょう。
しかし、CPUの端子を自由に操作するには、少なからず「テストプログラム」が必要になります。
例えば、LEDチカチカのような単純なプログラムを動かすことによって、回路の各部分、例えば、メモリやI/Oの配線が正しくつながって正常に動作していることを確認します。
ところが、そのような「テストプログラム」が動くためには、ハードが確実に動いていなければならない、という事実があります。
そうなると、ソフトよりも先にハードをデバッグしなければなりません。
これでは、ハードをデバッグしたかったのにソフトを動かさなければならず、ソフトを動かすためにはハードがデバッグできなければならない、という悪循環に陥ってしまいます。
これがデバッグ・スパイラルです。
つまり、従来のようなやり方で、組み込みCPUを活用した基板をデバッグすると、デバッグスパイラルに陥ってしまい、時間を浪費してしまいます。
JTAG-ICEはハードウェア技術者の助けとならない
各社から発売されている従来のJTAG-ICE(エミュレータ)は、デバッグ・スパイラルを抜け出すためのツールとはなりません。
なぜならば、JTAG-ICEは、基本的にソフトウェア技術者のためのデバッグツールであるからです。
JTAG-ICEは、CPUごとに多少の差はあるものの、基本的には「CPUに対してJTAG経由でさまざまな機械語コードを送り、ソフトウェア的な処理によってデバッグを行う」という仕組みで動いています。
したがって、部品実装から仕上がってきたばかりの不完全なハードウェアに対してJTAG-ICEを用いるのは無謀ともいえる行為です。
例えば、クロックが正しくつながっていなかったり、モード設定端子が正しくつながっていないような基板に対してJTAG-ICEは正常に動作してくれるでしょうか？
ハードウェア技術者が必要とする「基板の初期のデバッグ」には、JTAG-ICEは効果がないのです。
JTAG-ICEは基板のデバッグが終わった後でソフトウェア技術者が使うものです。いくらJTAG-ICEがマルチタスクOS対応や仮想何々対応などという高度な機能を謳っていても、それらはハードウェア技術者がやりたいデバッグにとっては、全く無用の長物です。
どのようにして、デバッグスパイラルを抜け出せばよいか
ハードウェア技術者が望むことは、
- 任意の端子を自由に操作できること。
- ソフトウェア（アセンブラ命令やコンパイル方法）や、CPUのアーキテクチャの知識を必要とせずに、回路図だけを見ながらデバッグできること。
ではないでしょうか。
そのような要求に答えられる唯一の手段が、JTAGバウンダリスキャンです。
JTAGバウンダリスキャンは、MITOUJTAGによって可視化され、容易に使用することができるようになります。
MITOUJTAGのバウンダリスキャンを使えば、回路が動いているかどうかを、目で見て確認することができます。また、望みのI/O端子や、望みの制御信号（RD/WRなど）を自由自在に操作することができます。クロックやモード設定が間違っていても、バウンダリスキャンならば動作する可能性はあります。
それに対してJTAG-ICEは、CPUの持つ汎用ポート程度ならばそこそこ自由に動かせるかもしれませんが、制御信号を独立して動かすことができません。ハードウェアのデバッグには力不足です。
ぜひとも、MITOUJTAGのバウンダリスキャンを使うことによって、組み込みCPU活用ボードにおけるデバッグスパイラルから速やかに脱出してください。