KPIT GNU Tools (21) GNUSH v1202 SH7450 をシミュレート (5)2012年08月07日 19時20分12秒

General illegal instruction
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)

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)

KPIT GNU Tools (21) GNUSH v1202 SH7450 をシミュレート (3)2012年08月04日 11時27分58秒

SH7450 Address Error
シミュレータで Address Error になってしまう件、ドキュメントを読んでみると次の条件で起こると書いてある。
1.RAMCR.RMD="0"のとき、ユーザモードで内蔵メモリ領域へアクセス
2.ユーザモードで領域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 をシミュレート (2)2012年08月03日 23時41分48秒

SH7450 Sections
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)

KPIT GNU Tools (21) GNUSH v1202 SH7450 をシミュレート (1)2012年08月01日 22時13分38秒

SH-4A Simulator
追加した 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)

KPIT GNU Tools (20) GNUSH v1202 Windows Tool Chain (ELF) に SH7450 SH7455 を追加する2012年07月29日 22時01分08秒

sh7450/sh7455
Kpit GNUSH v1202 Windows Tool Chain (ELF) に SH7450 SH7455 を追加してみよう。
まず、メモリーマップを見てみる。
	SH74504			SH74513
ROM	00000000~001FFFFF	00000000~0017FFFF
RAM	18000000~1807FFFF	18000000~1807FFFF
OL	E500E000~E5011FFF	E500E000~E5011FFF
IL	E5200000~E5201FFF	E5200000~E5201FFF

	SH74552			SH74562
ROM	00000000~000FFFFF	00000000~000FFFFF
RAM	18000000~1803FFFF	18000000~1803FFFF
OL	E500E000~E5011FFF	E500E000~E5011FFF
IL	E5200000~E5201FFF	E5200000~E5201FFF
ROM と RAM のサイズが違うので SH7450 と SH7455 の二つにする。ここでは、SH7450 についてのみ述べる。

以下に示すファイルを新規作成又は修正することにする。(ここに示すのは SH7450 の例)
C:\Program Files\Renesas\Hew\System\Pg\KPIT GNUSH-ELF\GNUSH_Info\Support_3\scapp.det
C:\Program Files\Renesas\Hew\System\Pg\KPIT GNUSH-ELF\GNUSH_Info\Support_3\scppapp.det
C:\Program Files\Renesas\Hew\System\Pg\KPIT GNUSH-ELF\GNUSH_Info\Support_3\SH-4A\SH7450.PGD
C:\Program Files\Renesas\Hew\System\Pg\KPIT GNUSH-ELF\GNUSH_Info\Generate\env\SH7450.s
C:\Program Files\Renesas\Hew\System\Pg\KPIT GNUSH-ELF\GNUSH_Info\Generate\hwsetup\7450.c
C:\Program Files\Renesas\Hew\System\Pg\KPIT GNUSH-ELF\GNUSH_Info\Generate\IntPRG\SH7450.c
C:\Program Files\Renesas\Hew\System\Pg\KPIT GNUSH-ELF\GNUSH_Info\Generate\iodefine\7450.h
C:\Program Files\Renesas\Hew\System\Pg\KPIT GNUSH-ELF\GNUSH_Info\Generate\vect\SH7450.inc
C:\Program Files\Renesas\Hew\System\Pg\KPIT GNUSH-ELF\GNUSH_Info\Generate\VECTTBL\SH7450.c
C:\Program Files\Renesas\Hew\System\Pg\KPIT GNUSH-ELF\GNUSH_Info\Generate\vhandler\sh7450.s
C:\Program Files\Renesas\Hew\System\Pg\KPIT GNUSH-ELF\Hardware\SH-4A\SH7450.dat

さあ、はじめてみよう。
● scapp.det scppapp.det に SH7450 を追加
C:\Program Files\Renesas\Hew\System\Pg\KPIT GNUSH-ELF\GNUSH_Info\Support_3\scapp.det
C:\Program Files\Renesas\Hew\System\Pg\KPIT GNUSH-ELF\GNUSH_Info\Support_3\scppapp.det

 



●SH7450.PGD を追加
C:\Program Files\Renesas\Hew\System\Pg\KPIT GNUSH-ELF\GNUSH_Info\Support_3\SH-4A\SH7450.PGD

 



●env\SH7450.s を追加
C:\Program Files\Renesas\Hew\System\Pg\KPIT GNUSH-ELF\GNUSH_Info\Generate\env\SH7450.s

 



●hwsetup\7450.c を追加
C:\Program Files\Renesas\Hew\System\Pg\KPIT GNUSH-ELF\GNUSH_Info\Generate\hwsetup\7450.c

 



●IntPRG\SH7450.c を追加
C:\Program Files\Renesas\Hew\System\Pg\KPIT GNUSH-ELF\GNUSH_Info\Generate\IntPRG\SH7450.c

 



●iodefine\7450.h を追加
C:\Program Files\Renesas\Hew\System\Pg\KPIT GNUSH-ELF\GNUSH_Info\Generate\iodefine\7450.h

 



●vect\SH7450.inc を追加
C:\Program Files\Renesas\Hew\System\Pg\KPIT GNUSH-ELF\GNUSH_Info\Generate\vect\SH7450.inc

 



●VECTTBL\SH7450.c を追加
C:\Program Files\Renesas\Hew\System\Pg\KPIT GNUSH-ELF\GNUSH_Info\Generate\VECTTBL\SH7450.c

 



●vhandler\sh7450.s を追加
C:\Program Files\Renesas\Hew\System\Pg\KPIT GNUSH-ELF\GNUSH_Info\Generate\vhandler\sh7450.s

 



●Hardware\SH-4A\SH7450.dat を追加
C:\Program Files\Renesas\Hew\System\Pg\KPIT GNUSH-ELF\Hardware\SH-4A\SH7450.dat

 



うまくできているのだろうか?
プロジェクトを作ってコンパイルしてみる。
問題はなさそうだが最終は現物が手に入ってから確認することにしよう。

環境:High-performance Embedded Workshop Version 4.09.00.007
    KPIT GNUSH v12.02 Windows Tool Chain (ELF)

KPIT GNU Tools (19) GNUSH v1202 Windows Tool Chain (ELF) と avast (2)2012年07月22日 20時33分06秒

自動サンドボックスを無効にする
某bbsに「自動サンドボックスを無効にするとよい」と書いてあったので試してみる。
追加の保護
自動サンドボックス 設定
[自動サンドボックスを有効にする]のチェックを外す


おお!
あの煩わしい画面が出てこない。

とは言ってもOFFにしてしまうと少々不安だ。
というわけで、「自動サンドボックスから除外されるファイル」というのを設定してみた。
コンパイルリンク・ライブラリ作成は問題ないようだ。しかし、新規プロジェクトを作った場合、一番最初に sh-elf-g++.exe と cc1plus.exe はプロジェクト中のファイルの数だけ出現する。ほかの実行ファイルとプロセスの起動方法が異なるのかもしれない。
そして、[実行を続ける]を押した回数だけ「自動サンドボックスから除外されるファイル」の数が増えていく。つまり、実行を続けるをクリックすると自動的に「自動サンドボックスから除外されるファイル」に登録されて次回から検査対象外になる仕組みなのだろう。
しかし、この機能がうまく働いてないようだ。

というわけで根本的な解決には至っていない。

KPIT GNU Tools (19) GNUSH v1202 Windows Tool Chain (ELF) と avast (1)2012年07月19日 22時30分20秒

avast
困ったことになった。
GNUSH v1202 Windows Tool Chain (ELF) をインストールしたものの HEW からコンパイルするたびに セキュリティソフト avast が動いてしまう。

このファイルをマルウェアであると識別するのに十分な証拠は得られませんでした。

のポップアップが何十回と出てきて「実行を続ける」を押し続けなければならない。

Ride7 や µVision では起こらないので HEW 特有の何かがあるのだろう。
今のところ対処方法不明。

フリーの ARM 開発環境 (4)2012年07月08日 22時16分34秒

MDK-ARM V4.53
今まで µVision3 を使い続けてきたがこのあたりで µVision4 に乗りかえることにする。
知らない間にgccに関する不具合も多少改善されており、使い勝手も次第によくなってきたからだ。それに、必要な部分のみ µVision3 にコピーするのもいい加減面倒になってきた。コンパイラを Ride7 と共有するにもちょうどいい機会だ。

インストールするのは MDK-ARM V4.53 最新版だ。GCCコンパイラは次のどちらにするか迷っている。
Sourcery G++ Lite 2011.03-42
Sourcery CodeBench Lite 2012.03-56
どちらにしてもインストールするディレクトリは
C:\Program Files\Raisonance\Ride\arm-gcc
インストールする前にバックアップを取って中身を削除しておこう。
今回は Sourcery CodeBench Lite 2012.03-56 にしてみる。

◎Ride7 はディレクトリを変更してないので ARMUtilities.js の Include PATH の一部を 4.4.1 から 4.6.3 に変更する。
◎C:\Program Files\Raisonance\Ride\lib\ARM\sections_FLASH.ld の end address of idata 計算部分に括弧をつける。(ld の仕様が変わったのだろうか。括弧がないとエラーになる。)
_eidata = _sidata + (_edata - _sdata) ;

◎µVision4 は GNU-Tool-Folder を C:\Program Files\Raisonance\Ride\arm-gcc にするだけでよい。

どちらも現在のところ問題なく動いているようだ。

環境:Raisonance Ride7 version 7.30.10.0169
    Raisonance RKit-ARM version 1.30.10.0356
    Keil MDK-ARM V4.53
    GCC Sourcery CodeBench Lite 2012.03-56

フリーの ARM 開発環境 (3)2012年07月05日 22時53分43秒

時間をもてあましていたので各コンパイラのコード効率を見てみることにした。
使う環境は
IDE		Keil µVision4
Source		ARM DSP_Lib V1.1.0
Optimize	Level3
テストするコンパイラは
arm	Keil MDKARM
	MDK-ARM 4.53

devkitarm	devkitPro 
	devkitARM_r41-win32

G++	Sourcery CodeBench Lite
	arm-2012.03-56-arm-none-eabi

GCC	GNU Tools for ARM Embedded Processors
	gcc-arm-none-eabi-4_6-2012q2-20120614

yagarto		Yet another GNU ARM toolchain
	yagarto-bu-2.22_gcc-4.7.1-c-c++_nl-1.20.0_gdb-7.4.1_eabi_20120616
順調にテストは進んでいったが、yagarto でだけコンパイルできない。
以前使ったときは何の問題もなかった気がする。
今のところ原因不明。
というわけで、結果は
Library Name		ARM		devkitarm	G++		GCC		yagarto
arm_cortexM0l_math	10,611,910	2,259,692	2,056,388	2,034,376	2,237,856
arm_cortexM3l_math	10,911,354	2,737,124	2,622,680	2,603,324	2,715,036
arm_cortexM4l_math	11,080,918	2,696,036	2,634,504	2,595,522	2,674,284
arm_cortexM4lf_math	11,165,886	2,642,920	2,580,528	2,541,592	2,621,156
しかし、ARM はなぜこんなに大きいのだろう?それ以外はすべてGCCなのだが微妙にサイズが異なっている。一番コンパクトに収まっているのは GNU Tools for ARM Embedded Processors 。結果から GCC バージョンの古いほうがサイズが小さい。たいした差ではないので好みで選べばよいだろう。


ここで気がついたことがひとつある。
今まで GNU-Tool-Prefix と GNU-Tool-Folder の設定だけすればよいと思っていたが、実は環境変数 PATH も設定しなければならない。もちろん PATH は GNU-Tool-Folder に \bin を付加したもの。(Sourcery CodeBench Lite 等はインストール時に環境変数 PATH に追加する。)何が動かないかというと arm-none-eabi-ar だ。こんなメッセージが出てきてはじめて気がついた。


'arm-none-eabi-ar' は、内部コマンドまたは外部コマンド、
操作可能なプログラムまたはバッチ ファイルとして認識されていません。


それにしても yagarto が動かないのが悔しい。エラーメッセージは何も出てこないので厄介かもしれない。時間のあるときに調べてみよう。


追記:2012/07/07
何回か Windows のリブートを繰り返しているうちにコンパイルできるようになった。
原因不明。というわけで yagarto のデータも追加した。

追記:2012/07/08
原因がわかった。 yagarto は、環境変数 PATH に bin ディレクトリの指定が必要だった。指定後リブートしなければ有効にならないので混乱していたのだ。ただし、arm-none-eabi-ar は bat ファイルで動くので全ての gcc コンパイラに PATH の指定が必要だ。
というわけで、bin ディレクトリの指定をしておけばどのコンパイラも問題なく動くということだ。
FC2無料カウンターFC2無料カウンターFC2無料カウンターFC2無料カウンターFC2無料カウンターFC2無料カウンターFC2無料カウンター FC2無料カウンターFC2無料カウンター