SH/H8 用フラッシュライタ (24) H8ライター Ver 0.39b12016年06月18日 12時45分13秒

H8W Ver 0.39b1
H8ライターのバージョンが上がっていた。
「書き込み制御ファイルに RX62G_F96M_P384.INF) を追加」
ということなので試してみたくなった。
時間のある時にテストしてみよう。


参照: H8ライター + H8工作 + PIC工作

KPIT GNU Tools and Support がなくなった2016年06月11日 14時12分05秒

GNU Tools | by CyberThor Studios, Ltd.
今日久しぶりに KPIT GNU Tools and Support のサイトを訪問してみるとなくなっている。
いつ gcc-renesas になったんだ?
KPIT の User 名と Password でログインしようとしたがログインできない。
新しく登録しなければならないようだ。
もう...
めんどくさい。


参照:GNU Tools | by CyberThor Studios, Ltd.

STM32 OptionBytes2015年04月04日 22時21分19秒

Option bytes とは?
ライトプロテクト又はリードアウトプロテクト又は 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 を調べてみた。
さすがにこれは間違った値は使ってない。

STM のスタートアップ (2)2015年03月21日 20時13分38秒

前回の続きになるが、もうひとつ気になっていることがある。
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

CQ-FRK-NXP-ARM (12) Cで書くスタートアップ (3)2015年03月19日 22時20分43秒

スタートアップ、リンカースクリプト、その他とそろった所で実際にコンパイルしてみよう。
リストの 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

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 する必要が無いのでその部分を削除したかったがその方法が分からない。
というわけで、以下の通り。
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
今回からデバイスファイルの一部がパックして供給されている。
そのパックされた部分の 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