DWMのARM基板のLVDDと、クロックの速度

このレポートは私がたまたま購入した付録基板で確認したものです。本レポートの結果をご利用される方は各自の責任の範囲内で行ってください。本レポートは内容の詳細な検討も行っておりませんし、デバイスのベンダーや、出版元に確認したわけでもありません。内容の正確さは保証しません。万が一のことが起きても、自己責任でお願いします。以上の点をご了承の上、お読みください。

DWMのARM基板で、シリアル通信(UART)の実験をしていて気になったことがあるので書きます。UARTを使おうとしている皆様の参考になればと思います。

サンプルのコードや、データシートを読んで、ボーレートジェネレータを適切にセットしたにも関わらず、UARTで送信したデータをパソコンで受信すると、文字化けしてしまっていました。
オシロで見ると、9600bpsになっていない！？のです。
ADuC7206のUARTは41.78MHzのクロックを分周してタイミングを作っているようなのですが、データシートには内蔵の発振器は3％の誤差がある、と書かれています。しかし、実測では3％以上ありました。正しく記憶していませんが6％くらいあったように思えます。

RS232Cは一般に、周波数が3％もずれてしまうとエラー発生率が高くなります。
分周器の設定を標準値から変えることで、なんとかパソコンで正しく受信できるようになりましたが、どのADuC7206でも一律にずれるのならばいいのですが、個体差があると良くないでしょう。

内蔵発振器の発振周波数ずれの原因は、LVDDの端子が3.3Vにショートされていることではないかと思い、再度、27番ピンの足上げをして確認してみることにしました。
なお、一度足を上げる値段は、夢と同じで57セントです。

さて、27番ピンの足を上げたら、その近くにパスコンを置きます。とりあえず、0.1uFを1個つけておきました。
そして、このLVDD端子を基板の外に引き出し、オシロと、デジタルマルチメータと、外部電源に接続しました。

外部電源をつないだのは、基板の外部から強制的にLVDDに電圧を注入し、LVDDの電圧がUARTの速度に影響するかどうかを確かめようというものです。

外部から3.3Vを注入したところ、およそ60～80mAの電流がLVDD端子に流れ込みました。しかし、周波数の変化はほとんど確認できませんでした。
一方、26番ピンと27番ピンをショートさせてみたところ、発振周波数が低いほうにずれるのを確認できました。

足上げをしてLVDDを切り離した場合


足上げをしたが、再度LVDDをIOVDDにショートさせた場合

26番(IOVDD1)と27番(LVDD)ピンをショート/オープンさせることで、通信速度に有意な差がでました。しかし、ショートさせる際に誤ってピンを折ってしまったので、これ以上の実験はできなくなってしまいました。

結果としては、LVDDに外から3.3Vを注入しても(一応2.7～3.6Vくらい変動させてみましたが)UARTの周波数は変わりませんでした。しかし、LVDDとIOVDDをショートさせると周波数が遅くなる、という一見不可思議な現象となりました。IOVDDの電源が下に引っ張られたことが原因なのでしょうか、ちょっとこれ以上はわかりません。

基板を壊してしまったのでこれ以上の実験はできなくなりましたが、LVDDの問題は、LEDチカチカが停止するということだけではないようです。電源とパスコンの問題だけではなく、内蔵発振器の周波数に影響している可能性もあります。UARTを使って通信するアプリケーションを作るなら、水晶発振器を載せたほうがいいのではないかと思われます。

ARMの開発環境

デザインウェーブのARM基板で実験するための私の開発環境を紹介します。

まずコンパイラが必要になります。ARM用のGCCを使うには、GCC自体をコンパイルしたり、リンカやライブラリ自体をコンパイルするといった作業から始まります。それはとても大変で長い時間を要する作業です。

そこで私は、「日本の組み込み情報」というサイトにある、GNUWingというツールを利用させていただいています。GNUWingというのは、アップウィンドテクノロジー・インコーポレイテッドさんが開発した、組み込み用開発環境のディストリビューションです。
現在は、ARM用、SH用、MIPS用、PowerPC用の4種類があり、プラットフォームはCygwin用とRedhatLinux用の2種類で、計8種類のものがリリースされています。

GNUWingは、GCCやGDBやリンカなどの開発環境一式をセットにしたものです。GCCなどの難しいことを全く知らなくても簡単にインストールできて、その瞬間からARM用の開発環境を使うことができるようになります。とてもおすすめです。

私は、間発環境サーバとしてRedhatLinux9を24時間動かしていて、そのRedhatにはGNUWingをインストールしています。Linuxのサーバは、SambaとWindowsのファイル共有でWindows環境からアクセスできるようにしています。
ソースコードの編集はネットワーク越しにWindows用のテキストエディタで行います。Linuxにログインするのは、GCCでコンパイルする時だけです。ソースコードの編集や出来上がったアセンブラコードのチェックなど、頭を使う作業は使いやすいWindows環境から行えるので、開発効率が低下する心配もありません。

パソコンとARM基板はJTAGを使って接続しています。シリアルのコネクタは使用していません。プログラムはRAMにダウンロードしています。

ADうC7026に内蔵されたフラッシュROMは使用していません。ADuC7026は、JTAGバウンダリスキャンでフラッシュROMに書き込むということが(たぶん)できないと思われます。したがって、ARM7に内蔵されたEmbeddedICE機能を使って、作成したプログラム(ELFファイル)をダウンロードすることになります。

JTAGのツールは、もちろんMITOUJTAGです。
MITOUJTAGは、Windows上から簡単なGUI操作で使用できます。XILINXやALTERAのパラレルケーブルや、ナヒテック製のSmartJTAG、Mobile JTAG CableといったUSB接続のものなど、いろんな方法でARMデバイスとつなぐことができます。

ケーブルをつないでボタンを押せば自動でデバイスが認識されます。

MITOUJTAGには、ARMデバッガが内蔵されています。このデバッガは、GCCが出力したLSTファイルを使って、機械語レベルで１命令ずつステップ実行させることができます。ネイティブに埋め込まれたARM用デバッガなので、GDBやInsightを使ってリモート接続するよりも、格段に高速なレスポンスが得られます。

また、MITOUJTAGのARMデバッガは、GDBやInsightのリモート接続を受け付けることもできます。ただし、TCP/IP上でGDBプロトコルを受け渡しするので、レスポンスの低下は避けられません。

ARM7用のネイティブなデバッガと、GDB/Insightを使い分けることで、デバッグの方法が広がります。

C言語に入る前のスタートアップコードなどは、昔から少しずつ付け足し付け足し使ってきた秘伝のスープのようなコードを使っています。全く高度なものではありません。cpsrとspを設定してmainにジャンプするだけです。

ARMの電源波形を解析して遊ぶ

DWMのARM基板の電源波形を観察して解析して遊んでいます。
この基板はあくまで評価ボードですから、電源にノイズが乗るなら、それを使った楽しみ方をしたいですね。

まず、BL命令で無限ループさせた場合の波形を調べてみました。(BL命令というのは、ARMアセンブラの分岐命令です)

LOOP:
    bl loop

大きなノイズのピークが２つと、小さなピークが２つ見えます。 この４つのピークが周期的に繰り返されています。 ピークが出る周期は約5.27MHzの逆数で、これはデフォルトのCPUのクロック周波数と一致します。 ピークとピークの間に小さなピークもあります。裏クロックでしょうか。

この波形から、BL命令を無限に繰り返すと１周期に４サイクル要しているのではないかと推測されます。
一方、ARM7のテクニカルリファレンスマニュアルによれば、BL命令のサイクル数は「2S+N」と書かれています。Sはシーケンシャルサイクル、Nはノンシーケンシャルサイクルだそうです。大きなノイズはシーケンシャルサイクルのアクセスを、小さなノイズはノンシーケンシャルサイクルのアクセスを表しているのでしょうか。とりあえず、つぎにいきましょう。

次に、BL命令の前に、NOP（実際には、MOV R0,R0）を入れた場合の波形です。

LOOP:
    nop
    bl loop

NOP命令はデータ処理命令ですから、１Sサイクルで実行できるはずです。波形を見ると、大きなノイズが１個増えました。また、ループの周期は５になりました。

こんな調子で、ADD(足し算)命令程度なら追跡できそうなのですが、STR命令やMLA(積和)命令などは、さすがに分からなくなりました。

ARMは1クロックで1つの命令を実行できるわけではなく、ちょっと複雑な命令だとすぐに複数クロックを必要としてしまうことを痛感しました。電源の波形から命令の実行状態を追跡するにはARM7のバスサイクル、特にノンシーケンシャルサイクルについて勉強しなければいけなさそうです。

サイドチャネル解析ができないかなと思って始めた電源波形の解析ですが、予想以上に難航しています。0x55555555と0xAAAAAAAAを足し算させた場合と、0x55555555と0x55555555を足し算させた場合などでは、若干の差はあるような気がするのですが、有意な差があるとは言い切れませんでした。

パスコンはどこに入れればよいか

DWM付録のARM基板を安定して動作させるためには、ディジタル系3.3V電源にパスコンを入れればよいということが、昨日の実験でわかってきました。
本当は0.47uFがいいのでしょうがあいにく手元になかったので、0.1uFを使うことにします。

さて、パスコンはどこに入れるのがベストでしょうか。

---

まずは、パスコンなしの波形を見てみます。

CPUの動作クロックにあわせて、VCCに大きなノイズが乗っています。LEDチカチカは10秒ほどで止まってしまいます。

---

次は、R4とSW1の間にパスコンを入れた場合です。なお、R4にはディジタル系の3.3Vがきています。

問題のLVDD端子よりも奥の方にパスコンがあるので、ノイズの改善効果は期待できるでしょう。

LEDチカチカがすぐに停止するということはなくなりました。
若干、ノイズが減っているのがわかります。

---

次は、基板の裏側にパスコンをつけた場合です。
LVDDからかなり近い位置になります。LVDD-パスコン-GNDの総配線長はおよそ15mmくらいでしょうか。

なお、この付録基板は、スルーホールの穴に薄いレジストがかかっているので、そのままでは半田が乗りません。付録基板のスルーホールに半田付けするにはレジストを削る必要があります。私は、ドリルの歯を手で持ってくるくると軽くまわして、レジストを削りました。

波形的には、だいぶん改善されてきました。VCCのノイズは、パスコンなしの場合の60%くらいの大きさになりました。LEDチカチカは正常に動いています。

---

最後は、ADuC7026の26番 & 27番端子に直接0.1μFのパスコンをつけた場合です。GNDは、直近のスルーホールから取ります。

ノイズは観測できないほど小さくなりました。

まだ若干のノイズは残っていますが、CPUの動作クロックと明確な相関はなさそうでした。

---

まとめ

パスコンをLVDD端子(27番ピン)の近くに配置すると、ノイズが抑制される傾向が見えてきました。デバイスの固体差にもよるのでしょうが、LVDD端子上のノイズ、すなわち3.3V VCCの電圧変動が大きいと、命令フェッチに失敗して止まってしまう、という現象が出るのだと思われます。

もし動作が不安定という方は、難しくない適当な場所にパスコンを入れてみてください。
これで思う存分、LEDチカチカできます。

DWMのARM基板にパスコンを入れる

このレポートは私がたまたま購入した付録基板で確認したものです。本レポートの結果をご利用される方は各自の責任の範囲内で行ってください。本レポートは内容の詳細な検討も行っておりませんし、デバイスのベンダーや、出版元に確認したわけでもありません。内容の正確さは保証しません。万が一のことが起きても、自己責任でお願いします。以上の点をご了承の上、お読みください。

まず結論だけ言うと、LVDDの端子(27番)が3.3Vにつながっていることが直接の原因ではなく、パスコンの不足によりLVDD端子の電圧に大きなノイズが乗ったため、私が手にした基板では不安定になっていたようです。

---

DWM付録のARM基板を眺めてみると、ディジタル用3.3Vの電源ラインがつぎのように配線されていることに気が付きました。

3.3Vのディジタル電源には、パスコンらしきものがC11とC7しかないのです。

---

まず、基板をデフォルトの状態（誤動作する）で、LVDD端子の波形を測定してみました。
オシロはACモードで使います。

VCCに約5.2MHzの周期的な繰り返しのノイズ波形が見られます。そのピーク・トゥ・ピークは300mV近くに達します。

追記　5.2MHzというのは、ADuC7026のデフォルトの動作周波数です。電源投入直後は44MHzの原発振を8分周したクロックで動作しています。POWCONレジスタを変更すると動作周波数が変わり、このノイズ波形の周波数も変わります。

---

次の波形は、CN1のコネクタの部分に0.1uFのコンデンサを入れた状態で測定したものです。

これで約１時間、正常に動作するのを確認しました。
（１時間で止まったというわけではなく、１時間以上の動作確認は行っていないという意味です。）

追記一晩中動かしたところ、朝起きたら止まっていました。

オシロの波形で見るとあまり変わっていないような気がしますが、ノイズは若干減ったような気がします。
短時間なら何とか誤動作はしないようです。

---

次の波形は、27番ピンの近くに0.1uFのコンデンサを入れた状態で測定したものです。


電源のノイズ波形はかなり抑制されました。
正常に動いているようです。

---

ということで、動作が不安定になってしまった原因は、LVDDの端子(27番)が3.3Vにつながっていることが直接の原因ではなく、パスコンの不足によりLVDD端子の電圧に大きなノイズが乗ったことではないかと考えられます。

ネットで検索すると、改良しなくてもちゃんと動いている人もいるようです。

正直な話、パスコンの有無がこんなに波形や動作に効いてくるとは思いませんでした。
もし、動作が不安定ということでお悩みの方は、とりあえず、
①　そのまま基板で動く
②　CN1か、その近くにパスコン(0.1uF)を入れたら動く←一晩中動かしたら止まってた
③　26番 & 27番ピンにパスコン(0.1uF)を入れたら動く←一晩中動かしても動作する
④　LVDDを浮かせてパスコン(0.47uF)を入れたら動く←一晩中動かしても動作する
という感じで検討してみてください。

DWMのARM基板を研究中

昨日、DWM付録のARM基板で、LEDチカチカをやってみたところ、起動してから１０秒くらいでプリフェッチアボート例外で止まってしまうという現象に遭遇しました。昨日はCPUの27番ピン(LVDD:コア電源 2.6V)を浮かせるという処置をすることで、LEDチカチカが安定して動作するようになりました。

LEDチカチカが途中で動かなくなる原因は、このLVDD端子が原因ではないかと推測されるのですが、電圧だけの問題とも思えません。なぜなら、昨日の改良をした状態でLVDDを3.3Vに無理やりつないだ場合、正常に動作した（数十秒で停止することはなかった）のです。

原因を調べるために、今日、試しにこの27番ピンを元に戻してみました。つまり、基板をデフォルトの状態に戻しました。するとやはりプリフェッチアボート例外で止まってしまいます。

ここで、下の図のように27番ピンと26番ピンから、ディジタルGNDに向けて0.1μFのバイパスコンデンサを入れてみたところ、LEDチカチカは1時間以上動きつづけました。(今のところ動作異常は起きていない)

26番ピンと27番ピンを半田でショートさせ（もともと基板上で接続されている）、そこからGNDへコンデンサを通すというものです。

この改良を行ったところ、LVDDが無理やり3.3Vに接続されているにもかかわらず、LEDチカチカは動きつづけました。

デフォルトの基板でLEDチカチカが止まってしまう原因は、おそらく、LVDDにパスコンが入っていないことではないかと思います。ディジタル系3.3Vの最寄のパスコンは、ADM3202の隣にあります(C7)。27番ピンのLVDD位置からはちょっと遠いような気がします。

と、書いているうちに、なんとなく解決方法が掴めてきました。
すごく簡単な解決方法がありそうです。
今思いついた改良を施して、しばらくLEDチカチカをヒートランテストしてみます。続きはまた明日。

DWM付録のARM基板でLEDチカチカ

今日は、午後から新宿で打ち合わせでした。
歌舞伎町は怖いと聴いていたので、人にぶつからないようにビクビクしながら歩きます。ひえぇ

------------

さて、戻ってきてから、購入したDWM付録のARM基板を動かしてみました。
JTAGのコネクタをつけてXILINXのParallelIVケーブルをつなぎます。

MITOUJTAGを起動してみると、見事にARM7を認識成功。MITOUJTAG内蔵のARM7デバッガも動きました。

とりあえず、LEDチカチカのプログラムを作成して、SRAMが配置されているアドレス0x10000にダウンロードしてみると、LEDが点滅。
成功・・・かと思いきや、数十秒でチカチカが止まってしまいます。電源に電解コンデンサを入れたりしても改善せず。

チカチカが止まると、アドレスカウンタは変なアドレスを指して、プログラムが存在していないところを実行しています。

調べたところ、どうやらLEDチカチカの途中でアドレス0x0000000Cへジャンプしてしまっているようです。
（0x0000000cにジャンプしているというのは、0x0000000Cにハードウェアトラップを設定すると引っかかるのに、0x00000008にトラップを設定しても引っかからないということから判断しました。）

ARMの解説本を読んでみると、0x0000000Cにジャンプというのは、ARMのコアがプリフェッチ・アボートした場合です。
プリフェッチ・アボートというのは何かというと、命令のフェッチに失敗するような場合に発生する例外です。これは普通にプログラムを実行している場合には遭遇しない例外です。何か、ハードウェアの問題が起きている可能性があるような致命的な例外です。

不意に聞いた噂によれば、この基板ではADuC7206のコア電源（LVDD）という端子(内蔵のLDOで作られた2.6Vの)が、3.3Vの電源につながってしまっているそうです。

そこで、下の写真のように27番ピン(LVDD)を浮かせ、浮かせたピンの下にカットしたポリイミドのテープを滑り込ませて絶縁します。そして、手持ちにあった1uFと0.01uFのコンデンサでGNDにつないだところ、プリフェッチアボートは起こらなくなりました。
LEDチカチカは１時間経っても正常に動作するようになりました。

この加工は結構大変でした。まず、半田吸い取り線を使って、ICの27番ピン付近の半田をできるだけ吸い取ります。ICのピンにはほとんど半田が残っていないような状態にします。吸い取ったら、細いピンセットを使って、無理やり基板からピンを剥がします。ちょっと力加減を間違うと隣のピンを曲げてしまったり、折ったりします。何度か危ない目に遭いました。こうしてピンを浮かせたら、何らかの方法で固定しないと、簡単に折れてしまいそうです。私はテープで固定しましたが、ホットメルトでもいいかもしれません。
27番の周辺のピンには半田を流して、吸い取られた半田を補充します。

DWMの第3章によれば、本当はLVDDには0.47uFのコンデンサをつけるのだそうですが、手元になかったので、適当な容量のコンデンサをつなぎました。

ただし、LVDDだけが原因ではないかもしれません。なぜなら、LVDDにこのような処置した直後にもプロフェッチ・アボートは完全には収まりませんでした。しばらく使っているうちに、プリフェッチアボートしなくなりました。
しかしながら、ためしにこの27番端子をVCC(3.3V)にショートさせたりすると、再びプリフェッチ・アボートしてしまいました。

LVDDに何か強烈なことが起きると、プロフェッチアボートしてしまうのかもしれません。
ただ、正直なところ、この端子が原因かははっきりとはわかりません。より詳しい検証をするには、浮かせた27番ピンをもう一度戻したり（それは嫌だ！）、もう一冊DWMを買ってきて試すということになりそうです。