KPIT GNU Tools (21) GNUSH v1202 SH7450 をシミュレート (1) ― 2012年08月01日 22時13分38秒
追加した SH7450 をシミュレータにかけてみよう。
現在のところそれぐらいしかできない。
さっそくプロジェクトを作ってコンパイル。
問題ない。
ダウンロードしてリセット・ステップイン。
0xA000 0000 の ResetHandler からプログラムが始まる。
ステップを進めていって _start へジャンプするべき所でおかしなところへ飛んでいく。
KPIT の様式に従ってプロジェクトのソースを作成しただけなのだが？
しかたがないので exp_handler.s を読み進めていくと _RESET_Vectors_temp は本来ベクターテーブルアドレスを指定しなければならないのに _start アドレスを指定しているのでおかしなことになっているのがわかる。
_start を _Exp_Vectors に修正してコンパイル・ダウンロード・実行。
あらあら、今度は RAM を参照しに行く。ベクターが初期化の終わっていない RAM に配置されているのだ。
vector_table.c を修正して ROM に配置されるようにする。
修正前 const void *Exp_Vectors[] = {
修正後 void *const Exp_Vectors[] = {
再度コンパイル・ダウンロードしてリセット・ステップイン。
今度は _start にジャンプして問題なさそうだ。
さらにステップを進めていくと
mov.b r2,@r0
で 0x00000100 に飛んで Address Error になってしまう。
r0 が E5200000 で r2 が 00000000 なので RAM を 00 で埋めるだけなのだが？
原因不明。
うまくいかないもんだ。
環境：High-performance Embedded Workshop Version 4.09.00.007
KPIT GNUSH v12.02 Windows Tool Chain (ELF)
現在のところそれぐらいしかできない。
さっそくプロジェクトを作ってコンパイル。
問題ない。
ダウンロードしてリセット・ステップイン。
0xA000 0000 の ResetHandler からプログラムが始まる。
ステップを進めていって _start へジャンプするべき所でおかしなところへ飛んでいく。
KPIT の様式に従ってプロジェクトのソースを作成しただけなのだが？
しかたがないので exp_handler.s を読み進めていくと _RESET_Vectors_temp は本来ベクターテーブルアドレスを指定しなければならないのに _start アドレスを指定しているのでおかしなことになっているのがわかる。
_start を _Exp_Vectors に修正してコンパイル・ダウンロード・実行。
あらあら、今度は RAM を参照しに行く。ベクターが初期化の終わっていない RAM に配置されているのだ。
vector_table.c を修正して ROM に配置されるようにする。
修正前 const void *Exp_Vectors[] = {
修正後 void *const Exp_Vectors[] = {
再度コンパイル・ダウンロードしてリセット・ステップイン。
今度は _start にジャンプして問題なさそうだ。
さらにステップを進めていくと
mov.b r2,@r0
で 0x00000100 に飛んで Address Error になってしまう。
r0 が E5200000 で r2 が 00000000 なので RAM を 00 で埋めるだけなのだが？
原因不明。
うまくいかないもんだ。
環境：High-performance Embedded Workshop Version 4.09.00.007
KPIT GNUSH v12.02 Windows Tool Chain (ELF)
KPIT GNU Tools (21) GNUSH v1202 SH7450 をシミュレート (2) ― 2012年08月03日 23時41分48秒
SH7450 のプロジェクトをシミュレータで動かす件、どうも納得がいかないが現物で確認できないのでしかたがない。
さて、次に試すのは RAM だ。
①.data と .bss の Section を OLRAM から ILRAM に変えてみる。
結果： Address Error になる
②.data と .bss の Section を OLRAM から SHwyRAM に変更してみる。
結果：正常に動く
③.stack を ILRAM から OLRAM に変えてみる。
結果：変化なし
④.stack を ILRAM から SHwyRAM に変えてみる。
結果：変化なし
理由は分からないが .data と .bss の Section は SHwyRAM でなければいけないらしい。.stack は問題なさそうなのでそのままにしておく。
というわけでセクションデータの変更だ
しかし、SuperH RISC engine Standard Toolchain (V.9.4.1.0) ではどこの RAM に配置しても問題ないので KPIT の環境はどこかに不具合を抱えているのだろう。KPIT ではなくて私の作った環境か？
まだ確認していないが、もうひとつ気になることがある。
INTHandler TLBmissHandler や IRQHandler の動きだ。
環境：High-performance Embedded Workshop Version 4.09.00.007
KPIT GNUSH v12.02 Windows Tool Chain (ELF)
さて、次に試すのは RAM だ。
①.data と .bss の Section を OLRAM から ILRAM に変えてみる。
結果： Address Error になる
②.data と .bss の Section を OLRAM から SHwyRAM に変更してみる。
結果：正常に動く
③.stack を ILRAM から OLRAM に変えてみる。
結果：変化なし
④.stack を ILRAM から SHwyRAM に変えてみる。
結果：変化なし
理由は分からないが .data と .bss の Section は SHwyRAM でなければいけないらしい。.stack は問題なさそうなのでそのままにしておく。
というわけでセクションデータの変更だ
しかし、SuperH RISC engine Standard Toolchain (V.9.4.1.0) ではどこの RAM に配置しても問題ないので KPIT の環境はどこかに不具合を抱えているのだろう。KPIT ではなくて私の作った環境か？
まだ確認していないが、もうひとつ気になることがある。
INTHandler TLBmissHandler や IRQHandler の動きだ。
環境：High-performance Embedded Workshop Version 4.09.00.007
KPIT GNUSH v12.02 Windows Tool Chain (ELF)
KPIT GNU Tools (21) GNUSH v1202 SH7450 をシミュレート (3) ― 2012年08月04日 11時27分58秒
シミュレータで Address Error になってしまう件、ドキュメントを読んでみると次の条件で起こると書いてある。
１．RAMCR.RMD＝"0"のとき、ユーザモードで内蔵メモリ領域へアクセス
２．ユーザモードで領域H'FC00 0000～H'FFFF FFFFにアクセス
ということは RAMCR を設定しなければならないがアクセスするとアドレスエラーになる。
困ったと思ってさらに探していると SuperH RISC engineファミリ用シミュレータデバッガのドキュメントに
「内蔵メモリ制御レジスタ (RAMCR) の設定を変更することなく、拡張機能付きSH-4A用シミュレータデバッガで、URAM領域へアクセスできるようになりました。なおこのため、RAMCRの設定変更によってURAM領域へのアクセス可否を切り替えることはできなくなりました。」
と書いてある。つまり何もしなくてよいということだ。
すぐに試してみた。
やっぱりだめだ Address Error になる。
いろいろ試していて分かったことはリセット後メモリウインドウから手動でFF000074へ00000200を書き込むと Address Error は出なくなる。 これで一件落着と言いたいところだが本番ではどうするのだ？
さらに調査．．．
①ユーザモードではメモリ割り付けレジスタはアドレス変換によるアクセスで参照できます。
おお アドレス変換か。
②P4 領域は、ストアキューと内蔵メモリ領域を除いてTLB を用いたアドレス変換ができません。
え！できないの？
③TLBを用いて物理アドレス空間のエリア7 をアクセスする場合のみ、エリア7 のH'1C00 0000～H'1FFF FFFFまでの領域が予約領域ではなくなり、仮想アドレス空間のP4 領域に含まれる制御レジスタ領域と等価になります。
ああ！やっぱりできるの？
④P4 領域アドレスは、仮想アドレス空間のP4 領域を用いた場合のものです。P4 領域アドレスの32 ビットアドレスで上位3 ビットを"0"にしたものがエリア7 アドレスとなります。エリア7 アドレスは、TLB を用いて物理アドレス空間のエリア7 からアクセスするものです。
で、どうすればいいの？
疲れた。sh4a ってむずかしい。今日はここまでにしておこう。
環境：High-performance Embedded Workshop Version 4.09.00.007
KPIT GNUSH v12.02 Windows Tool Chain (ELF)
１．RAMCR.RMD＝"0"のとき、ユーザモードで内蔵メモリ領域へアクセス
２．ユーザモードで領域H'FC00 0000～H'FFFF FFFFにアクセス
ということは RAMCR を設定しなければならないがアクセスするとアドレスエラーになる。
困ったと思ってさらに探していると SuperH RISC engineファミリ用シミュレータデバッガのドキュメントに
「内蔵メモリ制御レジスタ (RAMCR) の設定を変更することなく、拡張機能付きSH-4A用シミュレータデバッガで、URAM領域へアクセスできるようになりました。なおこのため、RAMCRの設定変更によってURAM領域へのアクセス可否を切り替えることはできなくなりました。」
と書いてある。つまり何もしなくてよいということだ。
すぐに試してみた。
やっぱりだめだ Address Error になる。
いろいろ試していて分かったことはリセット後メモリウインドウから手動でFF000074へ00000200を書き込むと Address Error は出なくなる。 これで一件落着と言いたいところだが本番ではどうするのだ？
さらに調査．．．
①ユーザモードではメモリ割り付けレジスタはアドレス変換によるアクセスで参照できます。
おお アドレス変換か。
②P4 領域は、ストアキューと内蔵メモリ領域を除いてTLB を用いたアドレス変換ができません。
え！できないの？
③TLBを用いて物理アドレス空間のエリア7 をアクセスする場合のみ、エリア7 のH'1C00 0000～H'1FFF FFFFまでの領域が予約領域ではなくなり、仮想アドレス空間のP4 領域に含まれる制御レジスタ領域と等価になります。
ああ！やっぱりできるの？
④P4 領域アドレスは、仮想アドレス空間のP4 領域を用いた場合のものです。P4 領域アドレスの32 ビットアドレスで上位3 ビットを"0"にしたものがエリア7 アドレスとなります。エリア7 アドレスは、TLB を用いて物理アドレス空間のエリア7 からアクセスするものです。
で、どうすればいいの？
疲れた。sh4a ってむずかしい。今日はここまでにしておこう。
環境：High-performance Embedded Workshop Version 4.09.00.007
KPIT GNUSH v12.02 Windows Tool Chain (ELF)
KPIT GNU Tools (21) GNUSH v1202 SH7450 をシミュレート (4) ― 2012年08月05日 14時36分01秒
メモリ割り付けレジスタへのアクセスは TLB を使うということが分かった。さらに読み進むと
①MMUCRの設定に従ってUTLB、ITLBを制御してアドレス変換を行います。
②TLBエントリの登録、削除、読み出し。UTLBエントリの登録にはLDTLB命令を用いる方法と、メモリ割り付けUTLBに直接書き込む方法があります。
③UTLB のアドレスアレイはP4 領域のH'F600 0000～H'F60F FFFF に割り付けられています。
④UTLB のデータアレイはP4 領域のH'F700 0000～H'F70F FFFF に割り付けられています。
まず、メモリ割り付けUTLBに直接書き込む方法を試してみよう。
だめだ。H'F600 0000 にアクセスしたとたん Address Error になる。
さて、困った。
今度は特権モードについて調べてみる。
①。特権モードではP0 領域からP4 領域の4G バイトの空間をアクセスすることが可能です。
②ユーザモードと特権モードは、ステータスレジスタの処理モードビット（MD）で切り替えます。
何だ一番簡単なのは特権モードを使うことだったのか。というわけで今度は特権モードで試す。
reset_program.asm のどこに追加しようかと眺めていると、なんと _start の直後ユーザーモードにするコードが書いてある。アクセスできなくて当たり前だ。
これを main をコールする直前の位置に移動する。
そして、コンパイル・ダウンロード・実行。
メモリ割り付けレジスタにアクセスできる。
内蔵メモリ（OL/IL）にアクセスできる。
やっと関数 main までたどり着いた。
しかし、ユーザモードからアクセスする場合はどうするの？
という疑問が残る。
環境：High-performance Embedded Workshop Version 4.09.00.007
KPIT GNUSH v12.02 Windows Tool Chain (ELF)
①MMUCRの設定に従ってUTLB、ITLBを制御してアドレス変換を行います。
②TLBエントリの登録、削除、読み出し。UTLBエントリの登録にはLDTLB命令を用いる方法と、メモリ割り付けUTLBに直接書き込む方法があります。
③UTLB のアドレスアレイはP4 領域のH'F600 0000～H'F60F FFFF に割り付けられています。
④UTLB のデータアレイはP4 領域のH'F700 0000～H'F70F FFFF に割り付けられています。
まず、メモリ割り付けUTLBに直接書き込む方法を試してみよう。
だめだ。H'F600 0000 にアクセスしたとたん Address Error になる。
さて、困った。
今度は特権モードについて調べてみる。
①。特権モードではP0 領域からP4 領域の4G バイトの空間をアクセスすることが可能です。
②ユーザモードと特権モードは、ステータスレジスタの処理モードビット（MD）で切り替えます。
何だ一番簡単なのは特権モードを使うことだったのか。というわけで今度は特権モードで試す。
reset_program.asm のどこに追加しようかと眺めていると、なんと _start の直後ユーザーモードにするコードが書いてある。アクセスできなくて当たり前だ。
これを main をコールする直前の位置に移動する。
そして、コンパイル・ダウンロード・実行。
メモリ割り付けレジスタにアクセスできる。
内蔵メモリ（OL/IL）にアクセスできる。
やっと関数 main までたどり着いた。
しかし、ユーザモードからアクセスする場合はどうするの？
という疑問が残る。
環境：High-performance Embedded Workshop Version 4.09.00.007
KPIT GNUSH v12.02 Windows Tool Chain (ELF)
KPIT GNU Tools (21) GNUSH v1202 SH7450 をシミュレート (5) ― 2012年08月07日 19時20分12秒
main までたどり着いたところで今一度 reset_program.asm の内容を確認する。
①R15 にスタックアドレスを設定
②内蔵メモリアクセスモードを設定
③データ領域の初期化
④HardwareSetup 関数を呼び出し
⑤浮動小数点ユニットの初期化
⑥ステータスレジスタの設定
⑦main 関数を呼び出し
今までのところこれで問題ない。しかし、気になっていた INTHandler の設定がどこにもない。VBR を設定しなければならないはずだ。VBR をデフォルトのまま使うなら INTHandler のセクションを 0x100 にしなければならない。そうでなければ VBR に対して
INTHandler は 0x100 のオフセット
TLBmissHandler は 0x400 のオフセット
IRQHandler は 0x600 のオフセット
となる。①と②の間にベクタベースレジスタの設定を挿入する事にする。
●RESETPRG\SH4A.asm 変更（reset_program.asm のもとになるファイルに上記の内容を反映）
C:\Program Files\Renesas\Hew\System\Pg\KPIT GNUSH-ELF\GNUSH_Info\Generate\RESETPRG\SH4A.asm
上記変更を行うと今度は vhandler\sh7450.s の具合が悪くなってくる。というわけで先日のソースを一部変更。
●vhandler\sh7450.s 変更
C:\Program Files\Renesas\Hew\System\Pg\KPIT GNUSH-ELF\GNUSH_Info\Generate\VECTTBL\SH7450.c
ここらで割り込みの確認だ。 main 関数から set_cr() を実行して一般不当命令の例外処理をやらせてみる。
画面では分かりにくいかもしれないが割り込みが発生し _INTHandlerPRG を実行している。また、ベクター 180 の interrupt function も実行される。
これで一通りのことはできたと思う。後は現物が入ってからだ。
環境：High-performance Embedded Workshop Version 4.09.00.007
KPIT GNUSH v12.02 Windows Tool Chain (ELF)
①R15 にスタックアドレスを設定
②内蔵メモリアクセスモードを設定
③データ領域の初期化
④HardwareSetup 関数を呼び出し
⑤浮動小数点ユニットの初期化
⑥ステータスレジスタの設定
⑦main 関数を呼び出し
今までのところこれで問題ない。しかし、気になっていた INTHandler の設定がどこにもない。VBR を設定しなければならないはずだ。VBR をデフォルトのまま使うなら INTHandler のセクションを 0x100 にしなければならない。そうでなければ VBR に対して
INTHandler は 0x100 のオフセット
TLBmissHandler は 0x400 のオフセット
IRQHandler は 0x600 のオフセット
となる。①と②の間にベクタベースレジスタの設定を挿入する事にする。
●RESETPRG\SH4A.asm 変更（reset_program.asm のもとになるファイルに上記の内容を反映）
C:\Program Files\Renesas\Hew\System\Pg\KPIT GNUSH-ELF\GNUSH_Info\Generate\RESETPRG\SH4A.asm
上記変更を行うと今度は vhandler\sh7450.s の具合が悪くなってくる。というわけで先日のソースを一部変更。
●vhandler\sh7450.s 変更
C:\Program Files\Renesas\Hew\System\Pg\KPIT GNUSH-ELF\GNUSH_Info\Generate\VECTTBL\SH7450.c
ここらで割り込みの確認だ。 main 関数から set_cr() を実行して一般不当命令の例外処理をやらせてみる。
画面では分かりにくいかもしれないが割り込みが発生し _INTHandlerPRG を実行している。また、ベクター 180 の interrupt function も実行される。
これで一通りのことはできたと思う。後は現物が入ってからだ。
環境：High-performance Embedded Workshop Version 4.09.00.007
KPIT GNUSH v12.02 Windows Tool Chain (ELF)
KPIT GNU Tools (22) GNU Windows Tool Chain ― 2012年08月11日 08時11分26秒
統廃合が進む Renesas の CPU。
主な現行品種は
RX V850 SH RL78 といったところだろうか。
ここでさらに統合が進み V850 と SH が RH850 になるような気がする。
さて、そこで気になるのが KPIT GNU Tools 。最近更新が遅れがちなのに、CPU の種類が増えればなおさらだ。
ところで、デバイスを追加しようと新しい CPU の資料を調べていて「かふぇルネ」を知った。
この際メモしておこう。
かふぇルネ
Renesas Rulz
主な現行品種は
RX V850 SH RL78 といったところだろうか。
ここでさらに統合が進み V850 と SH が RH850 になるような気がする。
さて、そこで気になるのが KPIT GNU Tools 。最近更新が遅れがちなのに、CPU の種類が増えればなおさらだ。
ところで、デバイスを追加しようと新しい CPU の資料を調べていて「かふぇルネ」を知った。
この際メモしておこう。
かふぇルネ
Renesas Rulz
フリーの ARM 開発環境 (5) µVision4 ― 2012年08月18日 11時52分37秒
µVision4 を使い始めた。
最近追加した MB9BF618 でプロジェクトを作成する。
スタートアップを追加するかどうかの問い合わせがあるので、もちろん”はい”。
出来上がったプロジェクトに main を追加してコンパイル。
あれ？
エラーだ。
startup_mb9bf61x.s を開いてみる。
私が作成した gcc 用のスタートアップではない。
どうやら µVision4 では C:\Keil\ARM\GNU\Startup\Fujitsu\MB9BF610\ に確保しておいてもコピーしてくれないらしい。
こういうところは µVision3 が使いやすい。デバイスデータファイルを作り直す必要があるようだ。
環境：Keil MDK-ARM V4.53
GCC Sourcery CodeBench Lite 2012.03-56
参照：
ADDING CUSTOM PARTS TO THE DEVICE DATABASE
Device Database Parameters （デバイスデータベースのパラメータ）
Customize or Add Devices （カスタムデバイスと新規デバイス）
Flash Download Configuration （フラッシュメニューの設定）
Key Sequence for Tool Parameters （ツールパラメータ用キーシーケンス）
最近追加した MB9BF618 でプロジェクトを作成する。
スタートアップを追加するかどうかの問い合わせがあるので、もちろん”はい”。
出来上がったプロジェクトに main を追加してコンパイル。
あれ？
エラーだ。
startup_mb9bf61x.s を開いてみる。
私が作成した gcc 用のスタートアップではない。
どうやら µVision4 では C:\Keil\ARM\GNU\Startup\Fujitsu\MB9BF610\ に確保しておいてもコピーしてくれないらしい。
こういうところは µVision3 が使いやすい。デバイスデータファイルを作り直す必要があるようだ。
環境：Keil MDK-ARM V4.53
GCC Sourcery CodeBench Lite 2012.03-56
参照：
ADDING CUSTOM PARTS TO THE DEVICE DATABASE
Device Database Parameters （デバイスデータベースのパラメータ）
Customize or Add Devices （カスタムデバイスと新規デバイス）
Flash Download Configuration （フラッシュメニューの設定）
Key Sequence for Tool Parameters （ツールパラメータ用キーシーケンス）
Keil µVision4 + GCC (1) Device Database ― 2012年08月21日 20時53分41秒
µVision4 はｇｃｃのスタートアップを読み込んでくれないので Device Database に GCC 用デバイスを追加することにする。
メニュー / File の Device Database を選択すると右上図の画面が出てくる。
画面では既に、LPC1114、LPC2388、MB9BF618T を登録済みだ。
さて、デバイスは MB9BF618T で説明しよう。
①Vendor を Fujitsu Semiconductors 、Device は MB9BF618T を選択する。（すでに登録済みなので必要な部分のみ変更する）
②Vendor を Add Device GCC に変更する。（何でもよい。 Fujitsu Semiconductors の中に Device 名だけ変えて登録してもよい。）
③Family は ARM
④Device 名は MB9BF618T
⑤Description も変更なし
⑥Options は以下の通り変更
⑧一度 µVision4 を終了して再度立ち上げ Device Database を確認し登録できていなければ①から⑦を繰り返す。（何回かやっているとそのうち登録できる。）
⑨startup_mb9bf61x.s を C:\keil\ARM\GNU\Startup\Fujitsu\MB9BF610 にコピーする。（startup_mb9bf61x.s は以前作成した物。µVision3 では①～⑧までは必要なかった。）
これで新規プロジェクトを作成すると GCC 用の Startup が読み込まれる。苦労した割りに、たいして報われない結果だ。
環境：Keil MDK-ARM V4.53
＋ GCC Sourcery CodeBench Lite 2012.03-56
メニュー / File の Device Database を選択すると右上図の画面が出てくる。
画面では既に、LPC1114、LPC2388、MB9BF618T を登録済みだ。
さて、デバイスは MB9BF618T で説明しよう。
①Vendor を Fujitsu Semiconductors 、Device は MB9BF618T を選択する。（すでに登録済みなので必要な部分のみ変更する）
②Vendor を Add Device GCC に変更する。（何でもよい。 Fujitsu Semiconductors の中に Device 名だけ変えて登録してもよい。）
③Family は ARM
④Device 名は MB9BF618T
⑤Description も変更なし
⑥Options は以下の通り変更
BOOK0=DATASHTS\FUJITSU\MB9BF610\MB9BF616S-DS706-00014-0v01-E.pdf("Data Sheet")
CPU=IRAM(0x20000000-0x2000FFFF) IRAM2(0x1FFF0000-0x1FFFFFFF) IROM(0x00000000-0x000FFFFF) CLOCK(4000000) CPUTYPE("Cortex-M3")
FLASH="C:\Program Files\Fujitsu\FUJITSU USB DIRECT Programmer\flash.exe"()
FLDLL=UL2CM3(-O207 -S0 -C0 -FO7 -FD20000000 -FC800 -FN1 -FF0MB9BFx08_1024 -FS00 -FL0100000)
MON=SARMCM3.DLL("-MPU") TCM.DLL("-pCM3")
REGFILE=mb9b610t.h("Fujitsu\MB9BF610")
SFILE="GNU\Startup\Fujitsu\MB9BF610\startup_mb9bf61x.s" ("Fujitsu MB9BF610 Startup Code")
SIM=SARMCM3.DLL("-MPU") DCM.DLL("-pCM3")
SVD=SFD\Fujitsu\MB9BF610\MB9BF618T.SFR
⑦Vendor を選択して Add ボタンをクリックする。新規作成した Device を選択して Update をクリックする。⑧一度 µVision4 を終了して再度立ち上げ Device Database を確認し登録できていなければ①から⑦を繰り返す。（何回かやっているとそのうち登録できる。）
⑨startup_mb9bf61x.s を C:\keil\ARM\GNU\Startup\Fujitsu\MB9BF610 にコピーする。（startup_mb9bf61x.s は以前作成した物。µVision3 では①～⑧までは必要なかった。）
これで新規プロジェクトを作成すると GCC 用の Startup が読み込まれる。苦労した割りに、たいして報われない結果だ。
環境：Keil MDK-ARM V4.53
＋ GCC Sourcery CodeBench Lite 2012.03-56
Keil µVision4 + GCC (2) LM3Sx Startup ― 2012年08月25日 15時17分19秒
欲を出して Luminary Micro も使えるようにする。
まずは startup だ。以下のディレクトリとファイル名でコピーする。
C:\Keil\ARM\GNU\Startup\Luminary\startup_LM3Sx.s
次は、リンカースクリプト。
C:\Keil\ARM\GNU\Startup\Luminary\Linker.ld
最後は Device Database へ登録だ。
SFILE="GNU\Startup\Luminary\startup_LM3Sx.s" ("Luminary Startup Code")
Luminary Micro の場合はリンカースクリプトとスタートアップをそのつど修正しながら使うことにする。従ってデバイスごとのファイルは用意しない。
環境：Keil MDK-ARM V4.53
＋ GCC Sourcery CodeBench Lite 2012.03-56
まずは startup だ。以下のディレクトリとファイル名でコピーする。
C:\Keil\ARM\GNU\Startup\Luminary\startup_LM3Sx.s
次は、リンカースクリプト。
C:\Keil\ARM\GNU\Startup\Luminary\Linker.ld
最後は Device Database へ登録だ。
SFILE="GNU\Startup\Luminary\startup_LM3Sx.s" ("Luminary Startup Code")
Luminary Micro の場合はリンカースクリプトとスタートアップをそのつど修正しながら使うことにする。従ってデバイスごとのファイルは用意しない。
環境：Keil MDK-ARM V4.53
＋ GCC Sourcery CodeBench Lite 2012.03-56
Raisonance Ride7 & ARM Tools (16) LPC1114FN28/102 の追加 ― 2012年08月28日 01時35分22秒
以前 LPC1114-301 を登録して使えるようにしたが、今回は LPC1114-102 を追加する。
忘れていたが割り込みを使うと動かないのも解決する必要がある。
まず、LPC1114-102 の登録からだ。
●LPC1114-102.reg
レジストリデータ、書き終えたら実行する。
もちろんレジストリエディタを使って直接入力してもよい。 ●LPC1114-102.sim
Simulator data、必要な項目のみ記述する。 ●HFARM.XML に LPC1114-102 を追加
SubFamily "LPC11x" に LPC1114-102 を追加登録する。 これで、LPC1114-102 が使えるようになったはずだ。
さて、次は割り込みで動かなかった件。
シミュレータで追跡してみると６行目を２回実行すると HardFault_Handler につかまってしまう。
５行目の ldr を ldrb にすると問題ない。
ldr のままだと６行目の strb を str にしなければならない。
どうやらワード境界の問題だったようだ。
つまり、データがなければループしないのでうまくここを通過していたわけだ。
というわけで crt0_LPC11x.s を修正。
●crt0_LPC11x.s
crt0_LPC17x.s をベースにして作成してある。
ほとんど Vectors Table を書き換えるだけだ。
これで問題なく使えるようになった。調べてみると 2011年06月06日から動かないまま放置していた。まあ、Keil µVision3 + GCC で使っている startup は問題なく動いていたので不自由はしなかったわけだ。
環境：Ride7 version 7.30.10.0169
+ RKit-ARM version 1.30.10.0356
+ GCC Sourcery CodeBench Lite 2012.03-56
忘れていたが割り込みを使うと動かないのも解決する必要がある。
まず、LPC1114-102 の登録からだ。
●LPC1114-102.reg
レジストリデータ、書き終えたら実行する。
もちろんレジストリエディタを使って直接入力してもよい。 ●LPC1114-102.sim
Simulator data、必要な項目のみ記述する。 ●HFARM.XML に LPC1114-102 を追加
SubFamily "LPC11x" に LPC1114-102 を追加登録する。 これで、LPC1114-102 が使えるようになったはずだ。
さて、次は割り込みで動かなかった件。
シミュレータで追跡してみると６行目を２回実行すると HardFault_Handler につかまってしまう。
01: movs r1, #0 02: b LoopCopyDataInit 03: CopyDataInit: 04: ldr r3, =_sidata 05: ldr r3, [r3, r1] 06: strb r3, [r0, r1] 07: adds r1, r1, #1 08: LoopCopyDataInit: 09: ldr r0, =_sdata 10: ldr r3, =_edata 11: adds r2, r0, r1 12: cmp r2, r3 13: bcc CopyDataInit 14: ldr r2, =_sbss 15: b LoopFillZerobssロード、ストアの使い方がまずいのだろうか？
５行目の ldr を ldrb にすると問題ない。
ldr のままだと６行目の strb を str にしなければならない。
どうやらワード境界の問題だったようだ。
つまり、データがなければループしないのでうまくここを通過していたわけだ。
というわけで crt0_LPC11x.s を修正。
●crt0_LPC11x.s
crt0_LPC17x.s をベースにして作成してある。
ほとんど Vectors Table を書き換えるだけだ。
これで問題なく使えるようになった。調べてみると 2011年06月06日から動かないまま放置していた。まあ、Keil µVision3 + GCC で使っている startup は問題なく動いていたので不自由はしなかったわけだ。
環境：Ride7 version 7.30.10.0169
+ RKit-ARM version 1.30.10.0356
+ GCC Sourcery CodeBench Lite 2012.03-56
最近のコメント