February 03, 2010

Super Sylphide 進捗状況(28) -- DSPのROMブートでmain()前にPLLを有効に

オートパイロットシステム Super Sylphideですが、ちょっとした佳境を迎えつつあります。そのデバック作業中において遭遇した問題について、今回は記事にしてみようと思います。内容はタイトルのとおり、ブートコードでPLLの設定を完了しなければせならなかったという話です。

Super Sylphideで利用しているDSPはTIのTMS320C6713Bという浮動小数点DSPです。このDSPはROMからブートする場合、以下の2段階の過程を経て行われます。

まず、ROMの先頭1K Bytesが内蔵RAMに自動的にコピーされます。その1KBには、基本的なレジスタの設定、例えば外部に接続されたSDRAMのバス幅やリフレッシュレートなどを書くとともに、プログラムコードやデータを適切な配置となるようコピーするコード、そしてmainに飛ぶコードを埋め込んでおきます。
その1KBのコードが実行されます。つまり基本的なレジスタ設定が完了するとともに、コードやデータが適切なメモリ番地に配置されます。最後にmain()が実行され、晴れてブートプロセスが完了します。

この1KBのブートコードは、なんといってもレジスタ設定やコード配置に関することですから非常に重要です。ということでTIのDSKに付属していたブートコードをベースに、RAMのリフレッシュレートの定数などを少し変更しただけのブートコードをこれまで使ってきました。

しかしながら時たまブートしなくなるという、不安定な症状が発生しました。原因を色々と探ってみたのですが、コードのサイズが少しばかり大きくなると問題が発生するということがわかりました。どうやら外部RAMであるSDRAM上に配置したプログラムコードが時たま予期しないものに書き換わってしまっているようでした。

色々考えてみた結果、タイトルの通りのこと、つまりPLLの初期化をmain()ではなくブートコード上で行うと不安定な状態が解消されることがわかりました。SDRAMのリフレッシュが不足し、データの一部が改変されていたようです。
これまではDSKのサンプルコードに従って、ブートコードが終了しmain()に飛んだ時点でPLLの初期化を行っていたのですが、この状態では本来の速度よりも遅い速度で外部バスが駆動されているので、main()でPLLが設定されるまでリフレッシュのタイミングが予期したものよりも遅くなります。一方、main()が呼ばれる前にブートコードでPLLの初期化を行うと、CPUや外部バスのクロックがコードを配置する以前に本来の速度となり、main()が呼ばれる前のコード配置中においても適切なタイミングでSDRAMのリフレッシュがかかるようになりました。

元にしたDSKのサンプルコードですが、これはこれで正当な方法でブートが行われている、と見ることができることもわかりました。というのも、DSPは高速な演算をさせるために、プログラムコードは外部RAMにおかず、内部RAMにおくというのが有る意味作法となっているからです。内蔵RAMはSRAMでありリフレッシュは必要ないので、PLLによってクロックが変化しようが問題ない、つまりPLLの設定はどこで行っても問題がないということなのでしょう。

最後に現在のブートコード(boot6713.asm)と、PLL初期化がない古いブートコード(boot6713.asm.r3660)を置いておきます。直接参考になるコードがなかった(C672xのブートに関する資料(jaja100.pdf)は参考になった)ので、ニーモニックを調べたりCコンパイラが吐くアセンブラを見ながら、なんとかハンドコーディングできました。

※進捗状況とはちょっと異なりますが、新たな関連文章をリリースしたのでお知らせします。『システム同定による小型無人航空機の飛行特性の取得』。Super Sylphideが計測装置として活躍しています。

※※新システム Tiny Featherを開発しはじめました。

00:07 fenrir が投稿 : 固定リンク | |

| コメント (0) | トラックバック
このエントリーのトラックバックURL: https://fenrir.naruoka.org/mt/mt-tb.cgi/737

February 12, 2010

ローカルに流れるTCPパケットを見る

[Computer] [Embedded System]

ちょっとした事情がありまして、以前記事を書いた『Amontec JTAGkey-Tiny (FT2232) を Xilinx iMPACTから使う』のメンテナンスをしています。これはXIlinxの純正書き込みツールでFT2232を使ったFPGAやPROMへの書き込みを可能にしようというツールなのですが、メンテナンスを行うにあたって表題のローカルを流れるTCPパケットを直接調べたいという要望が発生しました。

持ち出したるはTCPのパケットを監視するフリーウェアNirSoftのSmartSniffなのですが、これが困ったことにNICを通ったパケットしか拾ってくれないようでした。このフリーウェアはパケットをキャプチャしてくれるという単機能なので、非常に使い勝手が良く愛用しているので、できれば今回の目的にも使いたいところです。

ということで方法を考えてみました。方法は2つ考えたのですが、結局のところ他のマシンを経由してNICを強制的に通すというアイデアに変わりはありません。1つはsshでどこか手元にあるサーバに接続する際、ポートフォワーディングを行うという方法(ssh hoge@server -L some_port:local_ip:local_target_port)。もう一つはどこか別のコンピュータでstoneを使ってポートフォワーディングを行う方法(stone local_ip:local_target_port some_port)。どちらともうまくいきました。

どなたか1台のPCで済む良い方法をご存じないでしょうか。仮想PCとか使えばうまくいきそうな気もしていますが、ちょっと面倒くさいです。

23:05 fenrir が投稿 : 固定リンク | |