ブート問題その後

TRX-305への切り込みは、停滞したままです。長めの冬休み前半戦（掃除とか修理とか買い出しとか掃除とか…）がようやく終わり、TRX-305と腰を据えて向き合う時間がようやくとれました。が、成果と言えば、これまで細切れの時間でやってきたことの追認です。

相変わらずプログラムはICEでダウンロードすると動作し、SH2からブートしても沈黙しています。

LDR→SH2ソース変換は正しい

これ、結構手間暇かかったのですが、前提条件としてここがダメだとどうしようもないので再確認をしていました。

TRX-305のDSPオブジェクトは、実際にはLDRファイル(HEX形式)でしか与えられていません（CD-ROMに入っている）。このLDRファイルと、Windows上のLDR→SH2変換アプリケーションがTRX-305のCD-ROMで供給されています。

が、実はこのアプリケーションはWindows 8では動作しません。仕方がないのでこれと同じ動作をするUnix Shell Scriptを作りました。流石にテキストレベルで同じものを生成すると骨が折れるので、次のような二つの操作の結果が同じであることを確認してよしとしています。

TRX-305オリジナルのDSP.SRC (SH2ソース) → SH2 ビルド → オブジェクト
TRX-305オリジナルのLDRファイル → バイナリ化 → 手製の変換スクリプトでDSP.SRCに変換 → SH2ビルド → オブジェクト

バイナリ化を行っているのは、bfin-elf-ldrの出力がバイナリだからです（一応Hexも出せる）。

多分めんどくさくて上の変換の流れを追う気にはならないと思いますが、ともかくこれを手作業で行い、両オブジェクトがbit by bitで同じであることを確認しました。これで変換スクリプトは正しく動いていると言えます。まぁ、私の手作業が間違っている可能性もなくはないですが。

bfin-elf-ldrが正しく動いているか確認するすべがない

結論から言えば、このツールはパラメタが間違っていてもエラーを吐きません。spislaveと言うパラメタと-g 1 を与えると、LDRファイルのDXEブロックヘッダのHWAITピンを示すフラグが正しく立ちますので、まぁ正しくファイルを生成している気はするのです。しかし、であればなぜブートしないのでしょう。

UARTから文字を連続出力するプログラムを作り、動作をICEを使って確認しています。ターゲットでは正常に動きます。しかし、これをSH2にバインドする動作しないんですよね。SH2にバインドした状態で再起動してICEで除くと、プログラムはでたらめです。つまり、ブートしていません。

TRX-305は基板の集積度が高いのでオシロのプローブを当てにくいのですが、これはSPIを眺めてみるしかなさそうです。

一方、比較のために私が作ったELFファイルをVisualDSP++のelfloader.exeで変換しようとすると、

C:\foo>"c:\Program Files\Analog Devices\VisualDSP 5.0\elfloader.exe" dsp.dxe -pr
oc ADSP-BF533 -b spislave -pflag 1 -si-revision 0.5 -width 8 -noinitcode
[Warning ld0079]: Ignore programmable flag (-pFlag) which is not for the boot mo
de, or the processor, or the silicon revision number you selected.
[Information ld0080]: -pFlag is for SPI slave of ADSP-BF531/2/3 silicon revision
0.3 or above, or for SPI slave and UART of ADSP-BF534/6/7, or SPI slave of ADSP
-BF538/9.

C:\foo>

「-pFlagはシリコン・リビジョン0.3以降のBF533のSPI Slaveで利用できます」って、私それを指定していますけど。

なぜelfloaderとの比較をしたいかというと、私は公開されているLDRファイルの情報が十分だと信じていないのです。まだ何か文章に記されていないノウハウのようなものがあって、それがTRX-305のオリジナルのLDRファイル(VisualDSP++で開発されている)と、私のテストプログラム(GNU Tool Chain )の挙動の違いではないかと睨んでいるのです。

より一層の検討を要する

と、いうわけでこの問題はまだ暗闇を脱していません。

「自分がやっていることに間違いが無いことを確認するまで、不具合の問い合わせをしたくない」という気質のために無駄にあがいているのはいつもの通りですが、明日からは横紙破りを交えたあがき方をしてみるつもりです。