CQ-LM3S3748 (8) CMSIS (2) ― 2012年11月02日 22時47分44秒
さあ、今日こそ ５０MHｚ で動かすぞ！
と勢い込んでみたものの解決策があるわけではない。
それはそうと TI のlm3s_config.h 、system_lm3s.c 、system_lm4s.c には記述間違いがあるので修正する必要がある。
まずはデータシートの確認からだ。と見始めた途端
・System timer (SysTick), providing a simple, 24-bit clear-on-write, decrementing, wrap-on-zero counter with a flexible control mechanism
SysTick counter は２４ビットだったのだ。動かないのではなくて見かけ上、動いて無いように見えただけか？
SYSDIV = 4 に戻して SysTick_Config の値を２４ビット以内に収まるように値を設定する。
コンパイル、実行。
動いた。
いつも簡単な所でつまづいてしまう。原因はデータシートを読まないことだ。
さて、この際だから続けて見ていこう。
ここまで読んで概略は分かったような気分になった。ちょっと気になるのは Internal OSC や Hibernation Module の出力が PLL に入ってないことだ。PLL の動作範囲内にあるので惜しい気がする。 さて、50MHz で動いたので 動きそうな予感のする 66.67 MHz にも挑戦してみよう。SYSDIV = 3 にしてコンパイル、実行。
あっけなく動いた。
System Clock が 66.67MHz までいったので満足だ。今日はここまでにしておこう。
環境：CQ-LM3S3748
+ CMSIS_LM3S-32.zip
+ TI-CMSIS-Devices-8636.exe
+ Keil MDK-ARM V4.53
+ GCC Sourcery CodeBench Lite 2012.03-56
+ KPIT Cummins GNU-Archive Editor v1.1
+ KPIT Cummins GNU-Map Viewer v1.0
と勢い込んでみたものの解決策があるわけではない。
それはそうと TI のlm3s_config.h 、system_lm3s.c 、system_lm4s.c には記述間違いがあるので修正する必要がある。
lm3s_config.h 257行 (Revision 32)
system_lm3s.c 265行 (version V3.00)
system_LM4F.c 265行 (version V3.00)
(CFG_RCC_MOSCDIS << 1)\ 誤
(CFG_RCC_MOSCDIS << 0)\ 正
もちろんこの修正をしたからといって 50MHz で動くわけでは無いだろう。まずはデータシートの確認からだ。と見始めた途端
・System timer (SysTick), providing a simple, 24-bit clear-on-write, decrementing, wrap-on-zero counter with a flexible control mechanism
SysTick counter は２４ビットだったのだ。動かないのではなくて見かけ上、動いて無いように見えただけか？
SYSDIV = 4 に戻して SysTick_Config の値を２４ビット以内に収まるように値を設定する。
コンパイル、実行。
動いた。
いつも簡単な所でつまづいてしまう。原因はデータシートを読まないことだ。
さて、この際だから続けて見ていこう。
・If the main oscillator is required, software must enable the main oscillator following reset and allow the main oscillator to stabilize before changing the clock reference. ・If the PLL is being used, the crystal value must be one of the supported frequencies between 3.579545 MHz through 16.384 MHz. ・Possible System Clock Frequencies Using the SYSDIV Field 0x0 /1 reserved Clock source frequency/2 SYSCTL_SYSDIV_1 0x1 /2 reserved Clock source frequency/2 SYSCTL_SYSDIV_2 0x2 /3 reserved Clock source frequency/3 SYSCTL_SYSDIV_3 0x3 /4 50 MHz Clock source frequency/4 SYSCTL_SYSDIV_4 0x4 /5 40 MHz Clock source frequency/5 SYSCTL_SYSDIV_5 0x5 /6 33.33 MHz Clock source frequency/6 SYSCTL_SYSDIV_6 0x6 /7 28.57 MHz Clock source frequency/7 SYSCTL_SYSDIV_7 0x7 /8 25 MHz Clock source frequency/8 SYSCTL_SYSDIV_8 0x8 /9 22.22 MHz Clock source frequency/9 SYSCTL_SYSDIV_9 0x9 /10 20 MHz Clock source frequency/10 SYSCTL_SYSDIV_10 0xA /11 18.18 MHz Clock source frequency/11 SYSCTL_SYSDIV_11 0xB /12 16.67 MHz Clock source frequency/12 SYSCTL_SYSDIV_12 0xC /13 15.38 MHz Clock source frequency/13 SYSCTL_SYSDIV_13 0xD /14 14.29 MHz Clock source frequency/14 SYSCTL_SYSDIV_14 0xE /15 13.33 MHz Clock source frequency/15 SYSCTL_SYSDIV_15 0xF /16 12.5 MHz (default) Clock source frequency/16 SYSCTL_SYSDIV_16なんとなく SYSCTL_SYSDIV_3 でも動きそうな感じだ。
・Initialization and Configuration 1. Bypass the PLL and system clock divider by setting the BYPASS bit and clearing the USESYS bit in the RCC register. This configures the system to run off a “raw” clock source and allows for the new PLL configuration to be validated before switching the system clock to the PLL. 2. Select the crystal value (XTAL) and oscillator source (OSCSRC), and clear the PWRDN bit in RCC/RCC2. Setting the XTAL field automatically pulls valid PLL configuration data for the appropriate crystal, and clearing the PWRDN bit powers and enables the PLL and its output. 3. Select the desired system divider (SYSDIV) in RCC/RCC2 and set the USESYS bit in RCC. The SYSDIV field determines the system frequency for the microcontroller. 4. Wait for the PLL to lock by polling the PLLLRIS bit in the Raw Interrupt Status (RIS) register. 5. Enable use of the PLL by clearing the BYPASS bit in RCC/RCC2.おそらくこのとおりになっているだろう。
・Actual PLL Frequency XTAL Crystal Frequency (MHz) PLL Frequency (MHz) Error 0x04 3.5795 400.904 0.0023% 0x05 3.6864 398.1312 0.0047% 0x06 4.0 400 - 0x07 4.096 401.408 0.0035% 0x08 4.9152 398.1312 0.0047% 0x09 5.0 400 - 0x0A 5.12 399.36 0.0016% 0x0B 6.0 400 - 0x0C 6.144 399.36 0.0016% 0x0D 7.3728 398.1312 0.0047% 0x0E 8.0 400 0.0047% 0x0F 8.192 398.6773333 0.0033% 0x10 10.0 400 - 0x11 12.0 400 -8MHz なのに誤差が出ることになっている。記述ミスだろうか？
ここまで読んで概略は分かったような気分になった。ちょっと気になるのは Internal OSC や Hibernation Module の出力が PLL に入ってないことだ。PLL の動作範囲内にあるので惜しい気がする。 さて、50MHz で動いたので 動きそうな予感のする 66.67 MHz にも挑戦してみよう。SYSDIV = 3 にしてコンパイル、実行。
あっけなく動いた。
System Clock が 66.67MHz までいったので満足だ。今日はここまでにしておこう。
環境：CQ-LM3S3748
+ CMSIS_LM3S-32.zip
+ TI-CMSIS-Devices-8636.exe
+ Keil MDK-ARM V4.53
+ GCC Sourcery CodeBench Lite 2012.03-56
+ KPIT Cummins GNU-Archive Editor v1.1
+ KPIT Cummins GNU-Map Viewer v1.0
CQ-LM3S3748 (9) USB サンプルを動かしてみる ― 2012年11月04日 17時18分26秒
デバッガが無いのでレジスタなどの値を見たいときに見ることができない。そこで printf の登場だ。
CQ-LM3S3748 の場合簡単に接続できるのは USB なので仮想 COM Port として使いそこへ出力することにする。もちろん最初から作るのは大変なのでサンプルを利用する。
使用するサンプルは SW-EK-LM3S3748-9453.exe の中の boards\ek-lm3s3748\usb_dev_cserial がちょうどよいだろう。
必要なファイル
boards\ek-lm3s3748\usb_dev_cserial
startup_gcc.c
usb_dev_cserial.c
usb_dev_cserial.ld
usb_structs.c
usb_structs.h
ustdlib.c
usblib\gcc-cm3
libusb-cm3.a
driverlib\gcc-cm3
libdriver-cm3.a
CQ-FRK-NXP-ARM (5) printf (6) の ここのものを使う
rprintf.c
rprintf.h
Command line が用意されているので Dump を追加しメモリを見ることができるようにした。もちろんLED は port.f0 を port.g2 に変更しなければならない。あとは今回必要ない LCD への表示も削除した。
コンパイル／書き込み
LED ON/OFF 問題ない
Dump アドレスによってはフリーズする。
System Mode か何かでないとアクセスできない所があったっけ？
まあ、このくらいで勘弁しておいてやろう。
あ、そういえば先日用意した CMSIS は結局使わなかった。はっきりいってライブラリとの相性が悪いので使うのが大変だ。
環境：CQ-LM3S3748
+ TI-CMSIS-Devices-8636.exe
+ Keil MDK-ARM V4.53
+ GCC Sourcery CodeBench Lite 2012.03-56
+ KPIT Cummins GNU-Archive Editor v1.1
+ KPIT Cummins GNU-Map Viewer v1.0
CQ-LM3S3748 の場合簡単に接続できるのは USB なので仮想 COM Port として使いそこへ出力することにする。もちろん最初から作るのは大変なのでサンプルを利用する。
使用するサンプルは SW-EK-LM3S3748-9453.exe の中の boards\ek-lm3s3748\usb_dev_cserial がちょうどよいだろう。
必要なファイル
boards\ek-lm3s3748\usb_dev_cserial
startup_gcc.c
usb_dev_cserial.c
usb_dev_cserial.ld
usb_structs.c
usb_structs.h
ustdlib.c
usblib\gcc-cm3
libusb-cm3.a
driverlib\gcc-cm3
libdriver-cm3.a
CQ-FRK-NXP-ARM (5) printf (6) の ここのものを使う
rprintf.c
rprintf.h
Command line が用意されているので Dump を追加しメモリを見ることができるようにした。もちろんLED は port.f0 を port.g2 に変更しなければならない。あとは今回必要ない LCD への表示も削除した。
コンパイル／書き込み
LED ON/OFF 問題ない
Dump アドレスによってはフリーズする。
System Mode か何かでないとアクセスできない所があったっけ？
まあ、このくらいで勘弁しておいてやろう。
あ、そういえば先日用意した CMSIS は結局使わなかった。はっきりいってライブラリとの相性が悪いので使うのが大変だ。
環境：CQ-LM3S3748
+ TI-CMSIS-Devices-8636.exe
+ Keil MDK-ARM V4.53
+ GCC Sourcery CodeBench Lite 2012.03-56
+ KPIT Cummins GNU-Archive Editor v1.1
+ KPIT Cummins GNU-Map Viewer v1.0
CQ-LM3S3748 (10) Keil µVision4 + GCC に Startup を追加 ― 2012年11月06日 21時59分42秒
Luminary Micro のスタートアップは以前作った startup_LM3Sx.s で済ませる予定だった。しかし、 CQ-LM3S3748 が手に入り、ひんぱんに新規プロジェクトを作ることになったので専用のスタートアップ startup_LM3S3748.s を用意することにする。
と思っていたら TI-CMSIS-Devices-8636.exe の中にそのものがあった。以下のハンドラを削除し（削除しなくてもいいけどね）、名前を startup_LM3S3748.s に変更して DeviceDatabase に登録しよう。
ADC1SS0_Handler
ADC1SS1_Handler
ADC1SS2_Handler
ADC1SS3_Handler
I2S0_Handler
EPI0_Handler
GPIOJ_Handler
さて、簡単に終わってしまったので今度は Raisonance Ride7 用の Startup も作ることにする。これもベースがあるのでそんなに手間ではない。
crt0_LM3S3748.s
あとはスクリプトを若干変更してと言いたい所だが Raisonance の FAQ に DO NOT modify the files in．．．．とあるのでここに出すのはやめておこう。
環境：CQ-LM3S3748
+ TI-CMSIS-Devices-8636.exe
+ Keil MDK-ARM V4.53
+ GCC Sourcery CodeBench Lite 2012.03-56
+ KPIT Cummins GNU-Archive Editor v1.1
+ KPIT Cummins GNU-Map Viewer v1.0
+ Ride7 version 7.30.10.0169
+ RKit-ARM version 1.30.10.0356
と思っていたら TI-CMSIS-Devices-8636.exe の中にそのものがあった。以下のハンドラを削除し（削除しなくてもいいけどね）、名前を startup_LM3S3748.s に変更して DeviceDatabase に登録しよう。
ADC1SS0_Handler
ADC1SS1_Handler
ADC1SS2_Handler
ADC1SS3_Handler
I2S0_Handler
EPI0_Handler
GPIOJ_Handler
さて、簡単に終わってしまったので今度は Raisonance Ride7 用の Startup も作ることにする。これもベースがあるのでそんなに手間ではない。
crt0_LM3S3748.s
あとはスクリプトを若干変更してと言いたい所だが Raisonance の FAQ に DO NOT modify the files in
環境：CQ-LM3S3748
+ TI-CMSIS-Devices-8636.exe
+ Keil MDK-ARM V4.53
+ GCC Sourcery CodeBench Lite 2012.03-56
+ KPIT Cummins GNU-Archive Editor v1.1
+ KPIT Cummins GNU-Map Viewer v1.0
+ Ride7 version 7.30.10.0169
+ RKit-ARM version 1.30.10.0356
CQ-LM3S3748 (11) NVIC_VTABLE ― 2012年11月08日 21時40分22秒
STM32 では USB DFU bootloader を使う時 NVIC_SetVectorTable() で Offset を指定する必要があった。今回の LM3S3748 ではそのような設定をしていないが動いている。そこで先日作成したプログラム（仮想 COM Port に Dump 出力）でレジスタを見てみることにする。
NVIC_VTABLE が 0x00001800 に設定されている。アプリケーションでは記述して無いので USB DFU bootloader が書き換えたのだろう。この方が使いやすいね。
ところで、ここで使った Memory Dump は最初 strtol() で引数を変換していたがどうしてもうまくいかなかった。調べてみると返す値が long 型だったのだ。アドレスは unsigned long 型なので仕方なく atox() を作った。手抜きをしているのでどんな文字でも強制的に変換する。また使うときがあるかもしれないのでメモしておこう。
ついでに dump もメモしておこう。これは rprintf とセットにしてよく使う関数だ。
ここで USBrprintf は rprintf の名前を変えただけ USBputch は以下のとおり。
環境：CQ-LM3S3748
+ Keil MDK-ARM V4.53
+ GCC Sourcery CodeBench Lite 2012.03-56
+ KPIT Cummins GNU-Archive Editor v1.1
+ KPIT Cummins GNU-Map Viewer v1.0
NVIC_VTABLE が 0x00001800 に設定されている。アプリケーションでは記述して無いので USB DFU bootloader が書き換えたのだろう。この方が使いやすいね。
ところで、ここで使った Memory Dump は最初 strtol() で引数を変換していたがどうしてもうまくいかなかった。調べてみると返す値が long 型だったのだ。アドレスは unsigned long 型なので仕方なく atox() を作った。手抜きをしているのでどんな文字でも強制的に変換する。また使うときがあるかもしれないのでメモしておこう。
unsigned long atox(char *str)
{
unsigned long ret = 0;
while(*str){
ret = ret << 4;
ret |= 0xf & ((*str >= 'A') ? (*str++ - '7') : *str++);
}
return ret;
}
ついでに dump もメモしておこう。これは rprintf とセットにしてよく使う関数だ。
void dump(unsigned long adr,unsigned int size)
{
unsigned char *ad, data[16];
int i, j, k;
k = size / 16 + ((size % 16) ? 1 : 0);
USBrprintf("\r\n");
for(j = 0, ad = (unsigned char*)adr; j < k; j++){
USBrprintf("%08X", (unsigned long)ad);
for(i = 0; i < 16; i++, ad++)
USBrprintf(" %02X", data[i] = *ad);
USBputch(' ');
for(i = 0; i < 16; i++)
(data[i] >= 0x20 && data[i] < 0x80) ? USBputch(data[i]) : USBputch('.');
USBrprintf("\r\n");
}
}
ここで USBrprintf は rprintf の名前を変えただけ USBputch は以下のとおり。
int USBputch(int c)
{
while(USBBufferSpaceAvailable(&g_psTxBuffer[1]) < 2);
USBBufferWrite(&g_psTxBuffer[1], (const unsigned char *)&c, 1);
return c;
}
環境：CQ-LM3S3748
+ Keil MDK-ARM V4.53
+ GCC Sourcery CodeBench Lite 2012.03-56
+ KPIT Cummins GNU-Archive Editor v1.1
+ KPIT Cummins GNU-Map Viewer v1.0
パスワード付きファイルの解析 ― 2012年11月10日 12時16分13秒
パスワード付きファイルの解析に最近 Advanced Archive Password Recovery をよく使っていた。操作性がよいのでつい使ってしまう。しかし、ｃRARｋ とどちらが早いのか気になったので試してみた。
password は zz で英小文字二桁。両ソフト共解析は英小文字のみの設定にする。
やっぱり cRARk が早いんだ。
しかし、一度も解析に成功したことが無い（テストは除いて）。なぜなら、時間がかかるので結果が出る前にあきらめてしまうのだ。今迄で一番がんばったのが８時間ぐらいだろうか？それでも５文字か６文字ぐらいだったと思う。
「それじゃ持ってる意味無いだろう」と言われそうだが、それは私の勝手だ。
password は zz で英小文字二桁。両ソフト共解析は英小文字のみの設定にする。
archpr.exe 17.316秒 (Advanced Archive Password Recovery) crark.exe 15.65秒 (cRARk)ああ！
やっぱり cRARk が早いんだ。
しかし、一度も解析に成功したことが無い（テストは除いて）。なぜなら、時間がかかるので結果が出る前にあきらめてしまうのだ。今迄で一番がんばったのが８時間ぐらいだろうか？それでも５文字か６文字ぐらいだったと思う。
「それじゃ持ってる意味無いだろう」と言われそうだが、それは私の勝手だ。
CQ-LM3S3748 (12) USB printf (1) ― 2012年11月12日 22時42分10秒
先日の rprintf はうまくいったので今度は newlib の printf を使ってみる。syscall.c は CQ-FRK-NXP-ARM
printf の時使ったものにする。（オリジナルは WinARMの中のlpc213x_lpc214x_examples_20061205.zip）
コンパイル・・・・・特に問題はない。
ラン
まず、LED をトグル・・・問題ない。
Dump ・・・・あれ！おかしい。
１６進表示とキャラクター表示の位置が逆だ。
Stack_Size と Heap_Size を 0x3000 にしてみる・・・変化なし
rprintf の時からこの部分は変更してないのに．．．
解決策が思い浮かばない。
今日のところはこの辺で勘弁しておいてやろう。
そういえば Sourcery CodeBench Lite が 2012.09-63 になっていた。
環境：CQ-LM3S3748
+ Keil MDK-ARM V4.53
+ GCC Sourcery CodeBench Lite 2012.03-56
+ KPIT Cummins GNU-Archive Editor v1.1
+ KPIT Cummins GNU-Map Viewer v1.0
コンパイル・・・・・特に問題はない。
ラン
まず、LED をトグル・・・問題ない。
Dump ・・・・あれ！おかしい。
１６進表示とキャラクター表示の位置が逆だ。
Stack_Size と Heap_Size を 0x3000 にしてみる・・・変化なし
rprintf の時からこの部分は変更してないのに．．．
解決策が思い浮かばない。
今日のところはこの辺で勘弁しておいてやろう。
そういえば Sourcery CodeBench Lite が 2012.09-63 になっていた。
環境：CQ-LM3S3748
+ Keil MDK-ARM V4.53
+ GCC Sourcery CodeBench Lite 2012.03-56
+ KPIT Cummins GNU-Archive Editor v1.1
+ KPIT Cummins GNU-Map Viewer v1.0
CQ-LM3S3748 (13) USB printf (2) ― 2012年11月13日 21時12分18秒
「printf がおかしい」の続き。
今までに無い経験だった。もしや、と思ってUSBputc() をやめて全て printf を使ってみた。
正常に表示できる。
ためしに setvbuf(stdout, NULL, _IOFBF, 0); を指定すると（上右図）あらあら悲惨な結果だ。
この結果から _IOLBF がデフォルトということになる。
以前聞いた事があるのは「 Buffered I/O と Unbuffered I/O を混在させてはいけない。」ということだった。不具合に遭遇したことがなかったので今まで意識することはなかったがこれからは気をつけよう。
では具体的にどうすればよいのだろう？
①全て高水準関数（Buffered I/O）を使う。
② setvbuf で _IONBF を設定する。
①は意識しないとなかなか難しい。②は非効率的ということになる。
今回は①の方法で解決することにする。（USBputc() を putchar() に変更）
何とか解決はしたがもっと他にいい方法は無いのだろうか？
環境：CQ-LM3S3748
+ Keil MDK-ARM V4.53
+ GCC Sourcery CodeBench Lite 2012.03-56
+ KPIT Cummins GNU-Archive Editor v1.1
+ KPIT Cummins GNU-Map Viewer v1.0
今までに無い経験だった。もしや、と思ってUSBputc() をやめて全て printf を使ってみた。
正常に表示できる。
ためしに setvbuf(stdout, NULL, _IOFBF, 0); を指定すると（上右図）あらあら悲惨な結果だ。
この結果から _IOLBF がデフォルトということになる。
以前聞いた事があるのは「 Buffered I/O と Unbuffered I/O を混在させてはいけない。」ということだった。不具合に遭遇したことがなかったので今まで意識することはなかったがこれからは気をつけよう。
では具体的にどうすればよいのだろう？
①全て高水準関数（Buffered I/O）を使う。
② setvbuf で _IONBF を設定する。
①は意識しないとなかなか難しい。②は非効率的ということになる。
今回は①の方法で解決することにする。（USBputc() を putchar() に変更）
何とか解決はしたがもっと他にいい方法は無いのだろうか？
環境：CQ-LM3S3748
+ Keil MDK-ARM V4.53
+ GCC Sourcery CodeBench Lite 2012.03-56
+ KPIT Cummins GNU-Archive Editor v1.1
+ KPIT Cummins GNU-Map Viewer v1.0
CQ-LM3S3748 (14) CMSIS (3) ― 2012年11月17日 08時41分34秒
さて、core_cm3.c (version: V1.10) がコンパイルエラーになった件。
コンパイラのバージョンを Sourcery gcc 4.5.1 に変えるとうまくいった。その後の調査で No Optimization でコンパイルしても問題ないことがわかった。
ならば最新の arm-2012.09-63-arm-none-eabi.exe (gcc-4.7.2) では修正されているかもしれないと思い試してみた。
Error: registers may not be the same -- `strexb r0,r0,[r1]'
Error: registers may not be the same -- `strexh r0,r0,[r1]'
やはりだめだ。こんな時は Google さんに聞くに限る。と聞いてみると、バグらしい。しかも、昨年夏にはわかっていたようだ。解決策も書いてある。
知らなかったのは私だけか？
そして、この際なので新しいコンパイラ GCC Sourcery CodeBench Lite 2012.09-63 にした。
環境：CQ-LM3S3748
+ Keil MDK-ARM V4.53
+ GCC Sourcery CodeBench Lite 2012.09-63
+ KPIT Cummins GNU-Archive Editor v1.1
+ KPIT Cummins GNU-Map Viewer v1.0
コンパイラのバージョンを Sourcery gcc 4.5.1 に変えるとうまくいった。その後の調査で No Optimization でコンパイルしても問題ないことがわかった。
ならば最新の arm-2012.09-63-arm-none-eabi.exe (gcc-4.7.2) では修正されているかもしれないと思い試してみた。
Error: registers may not be the same -- `strexb r0,r0,[r1]'
Error: registers may not be the same -- `strexh r0,r0,[r1]'
やはりだめだ。こんな時は Google さんに聞くに限る。と聞いてみると、バグらしい。しかも、昨年夏にはわかっていたようだ。解決策も書いてある。
知らなかったのは私だけか？
そして、この際なので新しいコンパイラ GCC Sourcery CodeBench Lite 2012.09-63 にした。
環境：CQ-LM3S3748
+ Keil MDK-ARM V4.53
+ GCC Sourcery CodeBench Lite 2012.09-63
+ KPIT Cummins GNU-Archive Editor v1.1
+ KPIT Cummins GNU-Map Viewer v1.0
CQ-LM3S3748 (15) Ride7 Project ― 2012年11月18日 16時27分56秒
先日 Ride7 用に Startup を作成したがまだ動作は確認してなかった。簡単なプログラムで確認してみよう。
新規プロジェクトの作成
①LM3S3748 を選択して新規プロジェクトを作成する。
②Project Properties で Application Options を設定する。
⑥Make all project でコンパイル。
リンカースクリプトも予定通りできている。 Startup のリンクも問題ない。いい感じだ。
⑦LM Flash Programmer でプログラム。
LED が点滅している。問題ないようだ。
しかし、この環境で気に入らないのは外部 tool を Windows のメニューから起動しなくてはならないことだ。うまい方法は無いものだろうか？
おっと、忘れる所だった。以下の二つも所定のディレクトリに必要だ。
C:\Program Files\Raisonance\Ride\lib\ARM\crt0_LM3S3748.o
C:\Program Files\Raisonance\Ride\lib\ARM\include\lm3s3748.h
Startup は crt0_LM3Sx.o として兼用にしたほうがよかったかもしれない。
LM3S3748_Ride7.zip
環境：CQ-LM3S3748
+ Ride7 version 7.30.10.0169
+ RKit-ARM version 1.30.10.0356
+ GCC Sourcery CodeBench Lite 2012.09-63
新規プロジェクトの作成
①LM3S3748 を選択して新規プロジェクトを作成する。
②Project Properties で Application Options を設定する。
Directories Output Directory $(ApplicationDir)\out Listing Directory $(ApplicationDir)\out③Project Properties で Advanced ARM Options を設定する。
Debug environment Debug tool Simulator SIM-ARM Start Mode Reset address④Project Properties で LD Linker を設定する。
General Output file format binary Scripts Starter Kit limited No More More options -Wl,--section-start -Xlinker .isr_vector=0x00001800⑤blinky.c を Add Item で追加する。（blinky.c）
⑥Make all project でコンパイル。
リンカースクリプトも予定通りできている。 Startup のリンクも問題ない。いい感じだ。
⑦LM Flash Programmer でプログラム。
LED が点滅している。問題ないようだ。
しかし、この環境で気に入らないのは外部 tool を Windows のメニューから起動しなくてはならないことだ。うまい方法は無いものだろうか？
おっと、忘れる所だった。以下の二つも所定のディレクトリに必要だ。
C:\Program Files\Raisonance\Ride\lib\ARM\crt0_LM3S3748.o
C:\Program Files\Raisonance\Ride\lib\ARM\include\lm3s3748.h
Startup は crt0_LM3Sx.o として兼用にしたほうがよかったかもしれない。
LM3S3748_Ride7.zip
環境：CQ-LM3S3748
+ Ride7 version 7.30.10.0169
+ RKit-ARM version 1.30.10.0356
+ GCC Sourcery CodeBench Lite 2012.09-63
FRK-FM3 (6) FLASH USB DIRECT Programmer ― 2012年11月20日 22時08分09秒
書き込み速度が遅くて使う気になれない FRK-FM3 を片付ける前にもう一度動かしてみようと、以前作ったプロジェクトをコンパイル。
どうして次から次へと問題が出てくるのだ。
今までこんな所でエラーになったことは無い。コンパイラの解釈が変わったのか？
toolchain を Sourcery gcc 4.5.1 に戻すと問題ない。そういえば先日 gcc-4.6.3 を gcc-4.7.2 に変更したばかりだった。
-Wl がなければ問題ないが µVision4 では built-in なので削除できない。
何かいい方法は無いかといろいろやっていて、Map file を作成する事がこのエラーから逃れられる唯一の方法であることがわかった。これからは µVision4 を使う限り Map file の作成が必須だ。
さて、何をしようとしていたんだっけ？ コンパイルができたので FRK-FM3 を接続し書き込もうとすると
USB デバイスが認識されません
おいおい、これもか？
RESET を実行してもだめ。
USB ケーブルを抜き差ししてもだめ。
FUJITSU USB DIRECT Programmer を新規インストールしても認識しないのでドライバのインストールすらできない。
数えるほどしか使ってないのに壊れたのか？
片付けるために USB コネクタを外そうとすると「ピコン！」あの懐かしい音がした。
どうやらコネクタの接触不良のようだ。何回か抜き差ししているうちに安定してきた。
USB DIRECT Programmer で書き込んでみる 67.02秒 (1112bytes) 以前と変わらぬ遅さだ。
専用のライターソフトを作れば問題ないだろうが私にそんな力は無い。
また、富士通も力を入れてないので使い勝手のいいライターを期待するのは無理だろう。
そこで、現在の環境のまま書き込みのスピードアップを図ることにする。
何とかして短いプログラムは短時間で書き込みたい。それではとデバイスの設定を MB9BF616S/T にしてみると 39.86秒。
おお！！これか？
さらに MB9BF311L/M/N にすると 18.16秒。
これ以下は無いので自分で作成してみた。
C:\Program Files\Fujitsu\FUJITSU USB DIRECT Programmer\chipdef.ini
書き込みはすぐ終わるがイレースに時間がかかる。これ以上の短縮は難しそうだ。m_flash.9a314 の変更ができればまだ短縮はできるかも知れないが MB9BF311L/M/N までにしておこう。
ちなみにフラッシュのサイズは以下のようになっているので書き込むサイズに応じてデバイスを選択しよう。（手間のかかるライターだ。）
これでやっと我慢できるレベルになった。
なんてったってテストだから短いプログラムばかりだ。６０秒以上待たされたのではやる気も失せる。
環境：FRK-FM3 (MB9BF618T)
+ FUJITSU USB DIRECT Programmer V01L07
+ Keil MDK-ARM V4.53
+ GCC Sourcery CodeBench Lite 2012.09-63
+ KPIT Cummins GNU-Archive Editor v1.1
+ KPIT Cummins GNU-Map Viewer v1.0
Build target 'arm-none-eabi-gcc-4_6' linking... arm-none-eabi-gcc: error: unrecognized command line option '-Wl' Target not createdエラーだ。
どうして次から次へと問題が出てくるのだ。
今までこんな所でエラーになったことは無い。コンパイラの解釈が変わったのか？
toolchain を Sourcery gcc 4.5.1 に戻すと問題ない。そういえば先日 gcc-4.6.3 を gcc-4.7.2 に変更したばかりだった。
-Wl がなければ問題ないが µVision4 では built-in なので削除できない。
何かいい方法は無いかといろいろやっていて、Map file を作成する事がこのエラーから逃れられる唯一の方法であることがわかった。これからは µVision4 を使う限り Map file の作成が必須だ。
さて、何をしようとしていたんだっけ？ コンパイルができたので FRK-FM3 を接続し書き込もうとすると
USB デバイスが認識されません
おいおい、これもか？
RESET を実行してもだめ。
USB ケーブルを抜き差ししてもだめ。
FUJITSU USB DIRECT Programmer を新規インストールしても認識しないのでドライバのインストールすらできない。
数えるほどしか使ってないのに壊れたのか？
片付けるために USB コネクタを外そうとすると「ピコン！」あの懐かしい音がした。
どうやらコネクタの接触不良のようだ。何回か抜き差ししているうちに安定してきた。
USB DIRECT Programmer で書き込んでみる 67.02秒 (1112bytes) 以前と変わらぬ遅さだ。
専用のライターソフトを作れば問題ないだろうが私にそんな力は無い。
また、富士通も力を入れてないので使い勝手のいいライターを期待するのは無理だろう。
そこで、現在の環境のまま書き込みのスピードアップを図ることにする。
何とかして短いプログラムは短時間で書き込みたい。それではとデバイスの設定を MB9BF616S/T にしてみると 39.86秒。
おお！！これか？
さらに MB9BF311L/M/N にすると 18.16秒。
これ以下は無いので自分で作成してみた。
C:\Program Files\Fujitsu\FUJITSU USB DIRECT Programmer\chipdef.ini
[MB9BF618S/T_16k] DownloadFile=m_flash.9a314 LoadAddress=0x20000000 StartAddress=0x000000,0x100000 EndAddress=0x003FFF,0x100001 FlashSize=0x004000,0x000002 Clock=4MHz,48MHz Baud=9600,9600 Baud2=115200,115200１６ｋの設定だ。14.53秒
書き込みはすぐ終わるがイレースに時間がかかる。これ以上の短縮は難しそうだ。m_flash.9a314 の変更ができればまだ短縮はできるかも知れないが MB9BF311L/M/N までにしておこう。
ちなみにフラッシュのサイズは以下のようになっているので書き込むサイズに応じてデバイスを選択しよう。（手間のかかるライターだ。）
Part Number Flash Size MB9AF311L/M/N 64k (0x10000) MB9AF312L/M/N 128k (0x20000) MB9AF314L/M/N 256k (0x40000) MB9AF315M/N 384k (0x60000) MB9BF616S/T 512k (0x80000) MB9BF617S/T 768k (0xC0000) MB9BF618S/T 1M (0x100000)
これでやっと我慢できるレベルになった。
なんてったってテストだから短いプログラムばかりだ。６０秒以上待たされたのではやる気も失せる。
環境：FRK-FM3 (MB9BF618T)
+ FUJITSU USB DIRECT Programmer V01L07
+ Keil MDK-ARM V4.53
+ GCC Sourcery CodeBench Lite 2012.09-63
+ KPIT Cummins GNU-Archive Editor v1.1
+ KPIT Cummins GNU-Map Viewer v1.0
最近のコメント