SH/H8 用フラッシュライタ (24) H8ライター Ver 0.39b1 ― 2016年06月18日 12時45分13秒
H8ライターのバージョンが上がっていた。
「書き込み制御ファイルに RX62G_F96M_P384.INF) を追加」
ということなので試してみたくなった。
時間のある時にテストしてみよう。
参照: H8ライター + H8工作 + PIC工作
「書き込み制御ファイルに RX62G_F96M_P384.INF) を追加」
ということなので試してみたくなった。
時間のある時にテストしてみよう。
参照: H8ライター + H8工作 + PIC工作
KPIT GNU Tools and Support がなくなった ― 2016年06月11日 14時12分05秒
今日久しぶりに KPIT GNU Tools and Support のサイトを訪問してみるとなくなっている。
いつ gcc-renesas になったんだ?
KPIT の User 名と Password でログインしようとしたがログインできない。
新しく登録しなければならないようだ。
もう...
めんどくさい。
参照:GNU Tools | by CyberThor Studios, Ltd.
いつ gcc-renesas になったんだ?
KPIT の User 名と Password でログインしようとしたがログインできない。
新しく登録しなければならないようだ。
もう...
めんどくさい。
参照:GNU Tools | by CyberThor Studios, Ltd.
STM32 OptionBytes ― 2015年04月04日 22時21分19秒
Option bytes とは?
ライトプロテクト又はリードアウトプロテクト又は RAMBoot の禁止が設定できるものらしい。
NXP の CRP と似た機能だろう。
サンプルは私の環境だと Ride7 と MDK-ARM の中にある。
書き込むバイト数は 12バイトから64バイトまである。(ほかのパターンもあるのかもしれない)
MPUによって書き込む場所もサイズも異なるので調べるのも大変だ。
手元にあるサンプルからデフォルトの値を書き出してみると以下のようになる。
というわけでこの機能も私には必要ないものだった。
ライトプロテクト又はリードアウトプロテクト又は RAMBoot の禁止が設定できるものらしい。
NXP の CRP と似た機能だろう。
サンプルは私の環境だと Ride7 と MDK-ARM の中にある。
C:\Program Files\Raisonance\Ride\lib\ARM\STM32xxx_OptionBytes.c C:\Keil\ARM\Boards\Keil\MCBSTM32\Blinky\STM32F10xOPT.s C:\Keil\ARM\Boards\Keil\MCBSTM32F200\Blinky\STM32F2xx_OPT.s C:\Keil\ARM\Boards\ST\STM32L152-EVAL\Blinky\STM32L1xx_MD_OPT.sそのほか Web 上を探してもほとんど見当たらない。
書き込むバイト数は 12バイトから64バイトまである。(ほかのパターンもあるのかもしれない)
MPUによって書き込む場所もサイズも異なるので調べるのも大変だ。
手元にあるサンプルからデフォルトの値を書き出してみると以下のようになる。
STM32F0 AA55FF00 FF00FF00 FF00FF00 STM32F1 A55AFF00 FF00FF00 FF00FF00 FF00FF00 STM32F2 FFAA0055 FFAA0055 FF3F00C0 FF3F00C0 STM32F3 AA55FF00 FF00FF00 FF00FF00 FF00FF00 STM32F41 FFAA0055 FFAA0055 FF3F00C0 FF3F00C0 STM32F43 EFAA1055 EFAA1055 FF3F00C0 FF3F00C0 STM32L0 AA0055FF 70808F7F 0000FFFF 0000FFFF STM32L1MD AA0055FF 780087FF 0000FFFF 0000FFFF STM32L1MD+ AA0055FF 780087FF 0000FFFF 0000FFFF 0000FFFF 0000FFFF 0000FFFF 0000FFFF STM32L1HD AA0055FF 780087FF 0000FFFF 0000FFFF 0000FFFF 0000FFFF 0000FFFF 0000FFFF AA005500 78008700 0000FFFF 0000FFFF 0000FFFF 0000FFFF 0000FFFF 0000FFFF STM32W1 A55AFF00 FF00FF00 FF00FF00 FF00FF00実際にこの機能を使う時は ST-LINK や DfuSe を使うのだろう。
というわけでこの機能も私には必要ないものだった。
LPC800 Watchdog Oscillator その後 ― 2015年03月28日 12時06分04秒
以前 LPC800 の Watchdog oscillator を使った場合 uart がうまく動かないのは system_LPC8xx.c に原因があるからだと書いた。
それがようやく修正された。
修正されたものは MDK-ARM 5.xx で使われる Software Packs の中の Keil.LPC800_DFP.1.1.0.pack に含まれている。
日付は2014年8月21日になっているからわりと最近だ。
ただ、間違っていたのは WDT Oscillator Setting の FREQSEL だけじゃなく System Oscillator Control のFREQRANGEにも誤りがあったのだ。( Configuration Wizard を使わない場合関係ない。)
今見ていてはじめて気がついた。
しかし、lpc11xx と lpc13xx は、まだ未修正なので使う場合は注意が必要だ。(LPC112x だけ修正済み)
やはり、メーカ純正でないとだめなんだろうと思い Lpcopen を調べてみた。
さすがにこれは間違った値は使ってない。
しかし、lpc11xx と lpc13xx は、まだ未修正なので使う場合は注意が必要だ。(LPC112x だけ修正済み)
やはり、メーカ純正でないとだめなんだろうと思い Lpcopen を調べてみた。
さすがにこれは間違った値は使ってない。
STM のスタートアップ (2) ― 2015年03月21日 20時13分38秒
前回の続きになるが、もうひとつ気になっていることがある。
startup_stm32f042x6.s と startup_stm32f070x6.s に挿入してある以下の部分。
暇なときに調べてみよう。
こういう気になることが次から次へ出てくるのだからしょうがない。
参照:
STMicroelectronics
startup_stm32f042x6.s と startup_stm32f070x6.s に挿入してある以下の部分。
/*Check if boot space corresponds to test memory*/ LDR R0,=0x00000004 LDR R1, [R0] LSRS R1, R1, #24 LDR R2,=0x1F CMP R1, R2 BNE ApplicationStart /*SYSCFG clock enable*/ LDR R0,=0x40021018 LDR R1,=0x00000001 STR R1, [R0] /*Set CFGR1 register with flash memory remap at address 0*/ LDR R0,=0x40010000 LDR R1,=0x00000000 STR R1, [R0] ApplicationStart:これはいったい何なんだ?しかも、042x6 と 070x6 だけ。
暇なときに調べてみよう。
こういう気になることが次から次へ出てくるのだからしょうがない。
参照:
STMicroelectronics
STM のスタートアップ (1) ― 2015年03月20日 22時40分31秒
Cで書くスタートアップのためにいろいろなメーカのスタートアップを探したが中でも STM が気になった。
以前から STM のスタートアップはどれを使ったらよいのか分からないので一々データシートを見るか
MDK-ARM を起動して CPU 型番からスタートアップ名を探していた。
これね
startup_stm32f10x_cl.s
startup_stm32f10x_hd.s
startup_stm32f10x_hd_vl.s
startup_stm32f10x_ld.s
startup_stm32f10x_ld_vl.s
startup_stm32f10x_md.s
startup_stm32f10x_md_vl.s
startup_stm32f10x_xl.s
何とかならないかと思っていたところ、スタートアップの名前が新しくなっていた。
startup_stm32f100xb.s
startup_stm32f100xe.s
startup_stm32f101x6.s
startup_stm32f101xb.s
startup_stm32f101xe.s
startup_stm32f101xg.s
startup_stm32f102x6.s
startup_stm32f102xb.s
startup_stm32f103x6.s
startup_stm32f103xb.s
startup_stm32f103xe.s
startup_stm32f103xg.s
startup_stm32f105xc.s
startup_stm32f107xc.s
種類が増えたが一応名前からスタートアップを選択できる。これは歓迎すべきことだろう。
さて、話はスタートアップのファイル名ではなくてその中身だ。ベクターテーブルを見ていくと
最後に BootRAM が追加されている。確か以前はなかったはずだ。(以前と言ってもずいぶん前だ)
スタートアップにより挿入される位置が異なっている。
0x1CC 0x1E0 0x108 といった具合だ。
また、コードも2種類ある。
0xF108F85F 0xF1E0F85F
調べてみると
F85F F108 ldr.w pc, [pc, #-264]
F85F F1E0 ldr.w pc, [pc, #-480]
ということで所定の位置に挿入されているなら Reset_Handler に飛んでいく機能であるらしい。
そうだとすると startup_stm32f100xb.s と startup_stm32f100xe.s はそれぞれ
0x1CC に 0xF108F85F
0x1E0 に 0xF108F85F
が挿入されるようになるのでこの機能が働かないことになる。
というわけで、もしこの機能を使うなら
startup_stm32f100xb.s の 0x1CC は 0xF1CCF85F
startup_stm32f100xe.s の 0x1E0 は 0xF1E0F85F
でないといけないのではないだろうか?という話なのだった。
私の場合このどうでもいいようなことが気になってしょうがないのだ。
それはそうと、こう種類が増えると IDE のプロジェクトジェネレータをどうしようかということになってくる。
MDK-ARM ならデバイスファイルの CPU 一つ一つにファイル名を書いていくことになる。
Ride7 はどうしよう...
そういえば STM の GCC サンプルはいつの間にか Ride7 から TrueSTUDIO に変わってしまった。
もちろんプロジェクトファイルだけの問題なので
使えないと言うわけじゃないんだけど。
追記:
stm32f4Cube integration with Ride 7 によると Ride7 には Keil *.uvproj project を読み込んで
コンバートする機能があるらしい。そういうスクリプトがあるならぜひ試してみたい。
参照:
STMicroelectronics
AN0063-How to use STM32Cube library with Ride.pdf
以前から STM のスタートアップはどれを使ったらよいのか分からないので一々データシートを見るか
MDK-ARM を起動して CPU 型番からスタートアップ名を探していた。
これね
startup_stm32f10x_cl.s
startup_stm32f10x_hd.s
startup_stm32f10x_hd_vl.s
startup_stm32f10x_ld.s
startup_stm32f10x_ld_vl.s
startup_stm32f10x_md.s
startup_stm32f10x_md_vl.s
startup_stm32f10x_xl.s
何とかならないかと思っていたところ、スタートアップの名前が新しくなっていた。
startup_stm32f100xb.s
startup_stm32f100xe.s
startup_stm32f101x6.s
startup_stm32f101xb.s
startup_stm32f101xe.s
startup_stm32f101xg.s
startup_stm32f102x6.s
startup_stm32f102xb.s
startup_stm32f103x6.s
startup_stm32f103xb.s
startup_stm32f103xe.s
startup_stm32f103xg.s
startup_stm32f105xc.s
startup_stm32f107xc.s
種類が増えたが一応名前からスタートアップを選択できる。これは歓迎すべきことだろう。
さて、話はスタートアップのファイル名ではなくてその中身だ。ベクターテーブルを見ていくと
最後に BootRAM が追加されている。確か以前はなかったはずだ。(以前と言ってもずいぶん前だ)
スタートアップにより挿入される位置が異なっている。
0x1CC 0x1E0 0x108 といった具合だ。
また、コードも2種類ある。
0xF108F85F 0xF1E0F85F
調べてみると
F85F F108 ldr.w pc, [pc, #-264]
F85F F1E0 ldr.w pc, [pc, #-480]
ということで所定の位置に挿入されているなら Reset_Handler に飛んでいく機能であるらしい。
そうだとすると startup_stm32f100xb.s と startup_stm32f100xe.s はそれぞれ
0x1CC に 0xF108F85F
0x1E0 に 0xF108F85F
が挿入されるようになるのでこの機能が働かないことになる。
というわけで、もしこの機能を使うなら
startup_stm32f100xb.s の 0x1CC は 0xF1CCF85F
startup_stm32f100xe.s の 0x1E0 は 0xF1E0F85F
でないといけないのではないだろうか?という話なのだった。
私の場合このどうでもいいようなことが気になってしょうがないのだ。
それはそうと、こう種類が増えると IDE のプロジェクトジェネレータをどうしようかということになってくる。
MDK-ARM ならデバイスファイルの CPU 一つ一つにファイル名を書いていくことになる。
Ride7 はどうしよう...
そういえば STM の GCC サンプルはいつの間にか Ride7 から TrueSTUDIO に変わってしまった。
もちろんプロジェクトファイルだけの問題なので
使えないと言うわけじゃないんだけど。
追記:
stm32f4Cube integration with Ride 7 によると Ride7 には Keil *.uvproj project を読み込んで
コンバートする機能があるらしい。そういうスクリプトがあるならぜひ試してみたい。
参照:
STMicroelectronics
AN0063-How to use STM32Cube library with Ride.pdf
CQ-FRK-NXP-ARM (12) Cで書くスタートアップ (3) ― 2015年03月19日 22時20分43秒
スタートアップ、リンカースクリプト、その他とそろった所で実際にコンパイルしてみよう。
リストの 0020 行が取り除くことができなかった return だ。実害は無いのでよしとしよう。
0040 から 01fc まで空いているのは CRP を入れたためこのようになっている。
以下にそのリストを示す。
まあ予定通りうまく行ったという所だろうか。
ジャンプテーブルの部分は以下のような方法(某誌で採用されていた)もある。
リストの 0020 行が取り除くことができなかった return だ。実害は無いのでよしとしよう。
0040 から 01fc まで空いているのは CRP を入れたためこのようになっている。
以下にそのリストを示す。
まあ予定通りうまく行ったという所だろうか。
ジャンプテーブルの部分は以下のような方法(某誌で採用されていた)もある。
void (* const g_pfnVectors[])(void)= { 0xE59FF018, // ldr PC, [PC,#0x0018] 0xE59FF018, // ldr PC, [PC,#0x0018] 0xE59FF018, // ldr PC, [PC,#0x0018] 0xE59FF018, // ldr PC, [PC,#0x0018] 0xE59FF018, // ldr PC, [PC,#0x0018] 0xE1A00000, // nop 0xE59FF018, // ldr PC, [PC,#0x0018] 0xE59FF018, // ldr PC, [PC,#0x0018] Reset_Handler, Undef_Handler, SWI_Handler, PAbt_Handler, DAbt_Handler, 0, // Reserved IRQ_Handler, FIQ_Handler, };しかし、最初の8個を変更する場合ハンドアセンブルしなくてはならないのがいまいちなんだよね。
CQ-FRK-NXP-ARM (12) Cで書くスタートアップ (2) ― 2015年03月18日 22時11分34秒
スタートアップができたので次は linker script だ。
これは当然 LPCXpresso LPC8xx のものをそのまま使わせてもらう。 変更点は
ORIGIN(Flash) とLENGTH(Flash)
ORIGIN(Ram)とLENGTH(Ram)
とりあえずこれだけでいいだろう。
そうそう、CRP も一応入れておこう。
あと残りは SystemInit() 、これは mbed の system_LPC23xx.c がそのまま使えるはずだ。
system_LPC23xx.c と system_LPC23xx.h を引っ張ってくるとそのほかに必要なファイルが芋ずる式に出てきた。
上記以外に
core_arm7.h
vector_defns.h
LPC23xx.h
これに main() をくっつければテンプレートプロジェクトの出来上がりだ。
さらに、必要なら LPCXpresso の crp.c crp.h を付け加えて使うこともできる。
それにしても、久しぶりに mbed をのぞいたら対応する CPU が多くなっていて驚いた。
もちろん、あの Renesas RZA1H もサポートされている。
参照:
LPCXpresso
mbed
これは当然 LPCXpresso LPC8xx のものをそのまま使わせてもらう。 変更点は
ORIGIN(Flash) とLENGTH(Flash)
ORIGIN(Ram)とLENGTH(Ram)
とりあえずこれだけでいいだろう。
そうそう、CRP も一応入れておこう。
あと残りは SystemInit() 、これは mbed の system_LPC23xx.c がそのまま使えるはずだ。
system_LPC23xx.c と system_LPC23xx.h を引っ張ってくるとそのほかに必要なファイルが芋ずる式に出てきた。
上記以外に
core_arm7.h
vector_defns.h
LPC23xx.h
これに main() をくっつければテンプレートプロジェクトの出来上がりだ。
さらに、必要なら LPCXpresso の crp.c crp.h を付け加えて使うこともできる。
それにしても、久しぶりに mbed をのぞいたら対応する CPU が多くなっていて驚いた。
もちろん、あの Renesas RZA1H もサポートされている。
参照:
LPCXpresso
mbed
CQ-FRK-NXP-ARM (12) Cで書くスタートアップ (1) ― 2015年03月17日 19時21分02秒
昨年、某誌で「アセンブリ言語は極力使わない!ベクタ・テーブル&スタートアップ・ルーチンはCで書く」
という記事があった。これはおもしろいと、とびついたが期待とは違ってアセンブリが普通に使ってあり
タイトルとは異なっていた。(いや、異なっていたわけではないが...)
そこで、私もやってみようと言うわけだ。やるからには某誌のような手抜きではなくフルサポートをしたい。
Cortex-M シリーズは既にアセンブラを使わないスタートアップが普及しているので ARM7 でやってみる。
ARM7 と言えば、私の手持ちでは CQ-FRK-NXP-ARM (LPC2388) しかないのでこれで進める。
とはいっても何かベースとなるものが必要だ。LPCXpresso の cr_startup_lpc8xx.c と Ride7 の crt0_lpc23x.s を参考にする。
さて、最初の問題はジャンプテーブルだ。安直に関数を作りその中にインラインアセンブラで書いてみた。
Cortex-M シリーズだとアドレスなので配列の中に埋め込んでいけばよい。
ところが、ARM7 はここにインストラクションジャンプテーブルが入るので Cortex-M と同じ方法は取れないのだ。
また、この関数は return する必要が無いのでその部分を削除したかったがその方法が分からない。
というわけで、以下の通り。
次は、Reset_Handler だ。この部分の問題はスタックの設定をしなければならないこと。
Cでは直接レジスタを触ることができないはずだからこの部分もインラインアセンブラで書く。(今の所アセンブラだらけだ)
最後は、データエリアの初期化とクロックの設定。
これは cr_startup_lpc8xx.c のソースがそのまま使えるのではないかと思う。
そしてクロックの設定は SystemInit() を呼び出すことにする。
こうしてできたのが以下のソースだ。思ったより短時間でできたがやはりベクタ・テーブルや
Reset_Handler はCで書くのが難しい。タイトルと内容が異なると言われても仕方が無いかな。
今日の所はこの辺で勘弁しておいてやろう!。
残っているのは、リンカースクリプトと SystemInit() 。
Cで書いて移植性をよくするというのが目的だと思うが中身はインラインアセンブラごりごりで
移植性も何も無い感じになってしまった。やはりスタートアップは MPU に依存する部分が多いので
アセンブラで書いても問題ないような気がしてきた。その方が分かりやすいかな?
追記:
__attribute__((noreturn)) ではなく __attribute__ ((naked)) を使えばいいのだった。
これですっきりしたね。上記のソースも修正した。
参照:
LPCXpresso
RAISONANCE Ride7
という記事があった。これはおもしろいと、とびついたが期待とは違ってアセンブリが普通に使ってあり
タイトルとは異なっていた。(いや、異なっていたわけではないが...)
そこで、私もやってみようと言うわけだ。やるからには某誌のような手抜きではなくフルサポートをしたい。
Cortex-M シリーズは既にアセンブラを使わないスタートアップが普及しているので ARM7 でやってみる。
ARM7 と言えば、私の手持ちでは CQ-FRK-NXP-ARM (LPC2388) しかないのでこれで進める。
とはいっても何かベースとなるものが必要だ。LPCXpresso の cr_startup_lpc8xx.c と Ride7 の crt0_lpc23x.s を参考にする。
さて、最初の問題はジャンプテーブルだ。安直に関数を作りその中にインラインアセンブラで書いてみた。
Cortex-M シリーズだとアドレスなので配列の中に埋め込んでいけばよい。
ところが、ARM7 はここにインストラクションジャンプテーブルが入るので Cortex-M と同じ方法は取れないのだ。
また、この関数は return する必要が無いのでその部分を削除したかったがその方法が分からない。
というわけで、以下の通り。
void ResetISR(void){ __asm(" ldr PC, =Reset_Handler\n"); __asm(" ldr PC, =Undef_Handler\n"); __asm(" ldr PC, =SWI_Handler\n"); __asm(" ldr PC, =PAbt_Handler\n"); __asm(" ldr PC, =DAbt_Handler\n"); __asm(" nop\n"); __asm(" ldr PC, =IRQ_Handler\n"); __asm(" ldr PC, =FIQ_Handler\n"); }Cで書いたといっても記述内容はアセンブラそのものだ。他の方法を思いつかなかったのでしょうがない。
次は、Reset_Handler だ。この部分の問題はスタックの設定をしなければならないこと。
Cでは直接レジスタを触ることができないはずだからこの部分もインラインアセンブラで書く。(今の所アセンブラだらけだ)
__asm(" MSR CPSR_c, #Mode_ABT|I_Bit|F_Bit\n" " LDR SP, =_ABT_Stack\n"); __asm(" MSR CPSR_c, #Mode_UNDEF|I_Bit|F_Bit\n" " LDR SP, =_UND_Stack\n"); __asm(" MSR CPSR_c, #Mode_SVC|I_Bit|F_Bit\n" " LDR SP, =_SVC_Stack\n"); __asm(" MSR CPSR_c, #Mode_FIQ\n" " LDR SP, =_FIQ_Stack\n"); __asm(" MSR CPSR_c, #Mode_IRQ\n" " LDR SP, =_IRQ_Stack\n"); __asm(" MSR CPSR_c, #Mode_USR\n" " LDR SP, =_USR_Stack\n");Mode_... を define で宣言したかったがうまく行かないのでこの宣言部分もインラインアセンブラ。
最後は、データエリアの初期化とクロックの設定。
これは cr_startup_lpc8xx.c のソースがそのまま使えるのではないかと思う。
そしてクロックの設定は SystemInit() を呼び出すことにする。
こうしてできたのが以下のソースだ。思ったより短時間でできたがやはりベクタ・テーブルや
Reset_Handler はCで書くのが難しい。タイトルと内容が異なると言われても仕方が無いかな。
今日の所はこの辺で勘弁しておいてやろう!。
残っているのは、リンカースクリプトと SystemInit() 。
Cで書いて移植性をよくするというのが目的だと思うが中身はインラインアセンブラごりごりで
移植性も何も無い感じになってしまった。やはりスタートアップは MPU に依存する部分が多いので
アセンブラで書いても問題ないような気がしてきた。その方が分かりやすいかな?
追記:
__attribute__((noreturn)) ではなく __attribute__ ((naked)) を使えばいいのだった。
これですっきりしたね。上記のソースも修正した。
参照:
LPCXpresso
RAISONANCE Ride7
Keil MDK-ARM v5.00 (2) ― 2013年11月30日 10時15分54秒
今回からデバイスファイルの一部がパックして供給されている。
そのパックされた部分の device database が少し変わった。
緑色で表示されていて Update も Remove もできない。
さらに、ディレクトリの指定が $$Device:(device name)$ となったと同時に SFILE の指定がなくなったのだ。
調べてみると
C:\Keil\ARM\Pack\.Web\Keil.(Device Series)_DFP.pdsc
という名前のファイルに登録内容が記述されている。
今後、C:\Keil\UV4\UV4.cdb はなくなるのかもしれない。
今のところ従来のデバイスファイルも使えるのでパーソナルデバイスの追加もできるが、新しいデバイスファイルは追加・修正が難しそうだ。
この際なので Kpit の GNUARM-RZ も登録して使ってみよう。
GNU-Tool-Prefix:arm-rz-eabi-
GNU-Tool-Folder:C:\Program Files\KPIT\GNUARM-RZv13.01-EABI\arm-rz-eabi\arm-rz-eabi\
問題なく使える~♪
参照:
Software Pack Concept
Pack Description (*.PDSC) Format
そのパックされた部分の device database が少し変わった。
緑色で表示されていて Update も Remove もできない。
さらに、ディレクトリの指定が $$Device:(device name)$ となったと同時に SFILE の指定がなくなったのだ。
調べてみると
C:\Keil\ARM\Pack\.Web\Keil.(Device Series)_DFP.pdsc
という名前のファイルに登録内容が記述されている。
今後、C:\Keil\UV4\UV4.cdb はなくなるのかもしれない。
今のところ従来のデバイスファイルも使えるのでパーソナルデバイスの追加もできるが、新しいデバイスファイルは追加・修正が難しそうだ。
この際なので Kpit の GNUARM-RZ も登録して使ってみよう。
GNU-Tool-Prefix:arm-rz-eabi-
GNU-Tool-Folder:C:\Program Files\KPIT\GNUARM-RZv13.01-EABI\arm-rz-eabi\arm-rz-eabi\
問題なく使える~♪
参照:
Software Pack Concept
Pack Description (*.PDSC) Format
最近のコメント