ロジアナ

こんばんはuzakadeuです。

今回はロジアナ(ロジック・アナライザ)についてお話しします。
文章だけでは分かりにくいので、図を入れられる所は少しずつ改良して行こうと思います。


ファーム開発ではロジアナが大活躍します。ロジアナがないと仕事にならないので、安価な中古品を何台も購入しました。ロジアナへの投資は何十倍ものリターン(経費節減、品質)になって返ってきました。
以降、どんな事にロジアナを使っていたのかを詳しく見て行きます。

クロック周波数の確認

立ち上げ当初は、各種クロック周波数をすべて確認します。また最近はクロック周波数も動的に変更するので、それができているかも確認します。
間違ったクロック周波数でボードを壊すくらいはまだしも、間違ったまま開発を進めてしまうと取り返しがつきません。

観測信号の観測

それなりに設定*1すれば、チップはいろんな観測信号を出力できるようになっています。例えばDMAリクエスト - uzakadeuのブログでお話ししたDMAリクエストや、DSPのアイドル状態、DSPを含む電源ドメインの省電力状態、などなどを出力できます。

これらの信号を観測することにより、設計通りのDMA転送になっているか、本当にDSPを含む電力ドメインがretentionに落ちているか、などを検証します。

総処理量の測定

DSP/BIOSのスレッドの種類 - uzakadeuのブログDSPが何もやっていない時はIDL(バックグランド・スレッド)を実行させると話しました。逆に言うと、IDLが走っていない時はDSPが何か処理をやっているわけです。
空いてるGPIOポートを観測用に拝借し、IDLの実行中はLowを、それ以外の期間(何か処理を行っている期間)はHighを出力するようにします。そしてそのGPIOをロジアナで観測すれば、デューティー比から総処理量の概数を調べる事ができます。

ちなみにRTOSが用意している時間計測機能はあまり信用していません。

個別処理の処理量の測定

例えば、符号化処理や復号処理、各種音響処理(エコーサプレッサやノイズサプレッサ、イコライザなど)それぞれにかかる処理量を測定します。最終的にはタイマーカウンタをログに採って精度の高い処理量を出しますが、最初の頃はもっと素早く測定できる方法を使います。総処理量の測定と同様に空いているGPIOポートを観測用に拝借し、該当処理実行中はHigh、それ以外はLowを出力するようにします。そしてそのGPIOをロジアナで観測すれば、デューティー比から処理量を調べる事ができます。

ちなみにこの処理量はタイミング設計の検証&改善*2に用いるたいへん重要な数値です。

各種シリアルポート(McBSP, I2C, UARTなど)の信号測定

見出しのとおりです。各シリアルポートのクロックやフレーム同期信号、データなどを観測してデバッグや動作検証に役立てます。通話遅延を測定するのにもかかせません。

が、だんだんシリアルポートの信号を観測しにくいボードを設計してくるようになりました。せめてMICTOR 38へ出して欲しいと訴え続けてます。

タイミング設計の検証

各タスク間の処理時間差、割り込み発生位置などを測定して、タイミング設計の検証&改善に用います。測定は空いてるGPIOポート数本を利用して行います。

各種デバッグ

デバッグする時もロジアナは威力を発揮します。
デバッガでステップ実行するデバッグは、実行中に割り込みがどんどん発生して本来の状況を再現できないことがありますし、そもそも数時間に1回しか発生しないようなバグはステップ実行だけで追うのは不可能です。
ログを使ったデバッグは、時間軸での関係を把握するのが難しく、増加したデータやプログラムによりメモリ配置が変わってメモリ破壊系のバグが発生しなくなる事がありますし、何よりコード追加に時間がかかるのでいろんな可能性を探ってアレコレやる段階では効率が悪くなります。
その点、空きGPIOポートとロジアナを使ったデバッグは、短時間で準備ができ、ほぼ本来の処理に影響を与えず、実時間で観測でき、その観測信号が時間軸の関係をそのまま表現していて分かりやすい、というメリットがあります。

実際には、上記三つあるいはそれ以外のデバッグ方法を適宜組み合わせて原因を絞って行きます。

*1:観測信号の選択、ピンMUX、場合によってはボードのパターンカットなどの設定です。

*2:DMA転送に処理が間に合うか、想定範囲の割り込みが入っても破綻しないか、もっとDSP CPUのクロック周波数を落とせないか、もっと通話遅延を低減できないか、などなど。