2018年05月31日

OpenThereminOnTeensy@テストベッドの調整とコードのデバッグを行う

ソフトウエア評価用に作ったテストベッドにMCUを組み込んだところ、静電容量が変動した影響でリファレンス側オシレーターのチューンが狂ってしまった。 

IMG_7957.JPG

変動はPitch/Volume双方ともが20kHz程上にズレていて、これは最大で8pFが限界のGiga-Trimの可変範囲を超えている。

ということで、チューニングのやり直し。

まさかMCUがここまで影響するとは思わなかったが、ダミーでもよいのでMCUと同程度のマスのものを基板に搭載してチューンを行う必要がありそうだ。

確認のために数回の通電を行ったが、立ち上げ時の動作も怪し気な雰囲気だ。観測ポイント設定用に伸ばした結線が悪さをしている可能性もあって、原因の判定が難しい。

能動的な対策としては、外乱による変動をキャンセルするためにオシレーター部を電磁シールドで覆うのが正道で、通信機器の基板でよく行われている手法ではあるが、これは一寸大げさだろう。 実験機に搭載したオシレーターの回路構成がアンテナ側とリファレンス側で異なる(片方はVariCapによる補正が効く)のが情況を余計にややこしくしている。 手元にある最新の基板(ただし修正箇所が存在する)ではVari-Cap搭載型を組み合わせているので、調整が少しは楽になるかもしれない。

いろいろと挙動が怪しいMCU搭載DACでVari-Capを駆動する方式だが、手動で補正を行う形式に変更したほうが良い感触がある。

結局、20pFコンデンサの値を追加することでオシレーターのチューニングを完了したものの、依然としてMCUの挙動が怪しい。 試しにロジック・アナライザで特定箇所の波形を測定したところ、オーディオ関連の信号処理が全く行われていないようだ。 LEDのドライヴに関しては問題なく行えているので、プログラム全体のおおまかなステップはこなされているようだ。

稼働実績のあるコードとの差分を中心に精査したところ、まずは不要なFTM3を稼動状態にしているのを発見したため、これを停止した。 構成をシンプルにするために、チューニング機構はフル手動に変更し、不必要な条件分岐を極力減らすことにした。 不具合の発生は変数宣言の段階で何かポカをやらかしている所為なのだろうか? 特に基板独自の仕様を定義した部分が疑わしい。

システムに通電しながらシリアル信号を読む手法はMCUの破壊を誘発する可能性があるため、LEDのマーカーを使ってモード切り替えの推移を観察することにしたが、この部分に問題はなさそうだ。 次に、DACのサブルーチンにマーカーを組み込んで出力を観察してみたが、LEDが点灯せずアクセスを確認できない。

念のため、ロジック・アナライザでMCUの各デジタル出力を計測すると、こちらも出力を確認できず。 コードを再検討してクロックソースに同期させてデータを出力する為の条件分岐を行う箇所が怪しいと判断し、ここに動作検証用のフラグ出力を追加して波形を観測しながら判定を行う構造をよりシンプルに改装した結果、チップセレクトの出力を確認できるようになった。

ところが、DACにデータを送信するためのシリアルクロックの出力が認められない。データストリームの波形も平坦なままで、これは何かがおかしい。 そこで、不具合が予想されるDACへのデータ送信ルーティン内のクロックとデータの記述を調べ直したところ、ADAT系のデータラインとの混同を発見した。 

これは、稼動状態にあるシステムからコードを移植する際にピンアサインが異なる部分の記述を間違えたのが原因で、混同したデータラインを修正することで、問題を解決できるはずだ。

コードを修正した後にロジック・アナライザでDAC出力のデータ・ストリームを確認した。

Screen Shot 2018-05-31 at 9.24.20.png

一番上の信号がD18に入力されているMCK/44.1kHzで、現状は半波長の間にオーディオ出力の処理を行っている。

残りの半波長では、アンテナのセンシングをループで行っているが、この間に何回処理が行われているか現時点では不明。 アンテナのセンシングを行うループ内に、オーディオ出力の処理を割りこませることは可能だが、何れにしてもadat出力(現時点では機能をキャンセルしている)とDACとの併用は難しいと思われる。

16bitシングルCHのオーディオストリームに費やされる時間を計測した画像。

Screen Shot 2018-05-31 at 9.21.14.png

二発目の処理はOverDriveモードを有効にした時点で稼動状態となる。

和音設定の変更で全体の処理が重くなると、WCK半波長分の処理スペース後半にDACへのデータストリームが追いやられることを確認している。

処理に余裕を持たせるため、OverDriveモードのデータストリームををWCK後半に移すことも考えるべきか。

こちらは、データストリームとSCK(シリアルクロック)との関係を測定したもの。

Screen Shot 2018-05-31 at 9.23.21.png

データ確定からSCKのアップエッジまでのマージンは約10nsと出た。 処理ステップの消化時間からクロックをフリーランさせた結果がこれで、MAX5717/5719ではギリギリのタイミングとなるが、、、

WS001293.JPG

MAX5541に至っては明らかに速過ぎる、、、。

WS001289.JPG

辻褄を合わせるためには、 __asm__ volatile ("nop");  等を使用した遅延処理が必要で、最終的には現物合わせで調整することになる。
posted by Yasuski at 13:24| open.Theremin