相変わらずDSPがブートしない

TRX-305のDSP部に関しては、その後ヘッダファイルの解析などを行いましたが、進展らしきものはありません。

（いきなりTOPPERS/JSPは難しいか？）

と思い、ベアメタルのテスト・プログラムを書きましたが、結果は同じです。つまり、ICEからロードすると元気にシリアル・ポートに文字を出力しますが、SH2からロードするとだんまりです。プログラムはこんな感じ。どこで躓けっちゅうねん。

#include <cdefBF533.h>

int main(void)
{
    //    reset value of PLL multiplier is 10;
    //    The divider for sytem clock is 5;
    //     Clock in = 16.25Mhz
    //    PLL Clock = 162.5Mhz
    //     Sclk = 32.5MHz
    //    32_500_000 Hz / 16 / 57600bps = 35.26 => 35 ( < 1% error )

    *pUART_GCTL = 1;    // Enable UART clocking.

    *pUART_LCR =
        1 << 7;        // 1 : divisor access mode.

    *pUART_DLH = 0;        // Set divisor to 35
    *pUART_DLL = 35;
   
    *pUART_LCR =
        0 << 7 |    // 0 : None devisor access
        0 << 6 |     // 0 : no enforce TX Set Break
        0 << 3 |    // 0 : none Parity
        0 << 2 |    // 0 : 1 stop bit
        3 << 0 ;    // 3 : 8bit word

    while (1)
        if ( *pUART_LSR & ( 1 << 6 ) )    // if TH register is empty
            *pUART_THR = ‘A’;
    return 0;

}

これだけシンプルだと、流石の私も「悪いのはプログラムではなくてROM化プロセスのどこかだろう」と断言できます。では、どこなんでしょうね。

GCCもAnalog DevicesのDSP開発ツールVisualDSP++も、リンカの出力形式はELFです。そのため、かつてはGCCが生成した実行ファイルをシミュレータで動かすなどと言う荒技も使いました。どちらのツールチェーンにも、ELFをDSPのブート・バイナリに変換するツールが含まれています。VisualDSP++の場合はelfloader.exe、GCCの場合はbfin-elf-ldrです。

bfin-elf-ldrがおかしいのではないか？と思い、先週時間を見てLDRの内部を覗いていました。LDRは極めて簡略化したELFのような構造を持っていて、10byteのヘッダとそのヘッダによって修飾されるデータブロックを一つの単位として、これが繰り返し現れます。最後のヘッダはデータを持たず、その代わりに「おしまい」フラグを持っています。また、最初のヘッダはブロックの配置アドレスと長さの他に、SPIスレーブ・ブート用のHWAITの端子番号などを含みます。

bfin-elf-ldrが吐いたLDRファイルについては、少なくとも最初のヘッダの情報（SPI Slave bootのHWAITピン指定も含む）および、最後のヘッダ情報は合っています。また、エンディアンも間違っていません。

これが金曜日までの進展です。週末は出社や雨戸の修理などで時間を取れませんでしたが、まだやれることはあるので調査を進めます。

ツールチェーンを変更するときは、いつもこんな感じですね。特にマイナーな組み込みプロセッサだと、OSSで言われる「十分な数の目」原理が効きませんので、一つ一つのツールが正しいか常に疑ってかかる必要があります。そして、検証は大変な手間です。