STM32 OptionBytes ― 2015年04月04日 22時21分19秒
Option bytes とは？
ライトプロテクト又はリードアウトプロテクト又は RAMBoot の禁止が設定できるものらしい。
NXP の CRP と似た機能だろう。
サンプルは私の環境だと Ride7 と MDK-ARM の中にある。
書き込むバイト数は １２バイトから６４バイトまである。（ほかのパターンもあるのかもしれない）
ＭＰＵによって書き込む場所もサイズも異なるので調べるのも大変だ。
手元にあるサンプルからデフォルトの値を書き出してみると以下のようになる。
というわけでこの機能も私には必要ないものだった。
ライトプロテクト又はリードアウトプロテクト又は 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 上を探してもほとんど見当たらない。
書き込むバイト数は １２バイトから６４バイトまである。（ほかのパターンもあるのかもしれない）
ＭＰＵによって書き込む場所もサイズも異なるので調べるのも大変だ。
手元にあるサンプルからデフォルトの値を書き出してみると以下のようになる。
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 を使うのだろう。というわけでこの機能も私には必要ないものだった。
Raisonance Ride7 & ARM Tools (19) ― 2015年04月10日 22時46分04秒
Raisonance の tool がバージョンアップしていた。
RKit-ARM 1.58.15.0093
Ride 7.54.15.0083
release note を見てみると STM32F7 がサポートされているのと GCC が 4.9.3 になっている。
STMicroelectronics の STM32F7 サポートは Raisonance が最初かもしれない。
面白そうなのでこのバージョンもインストールしてみる。
少し中をのぞいてみよう。
今回からサポートされた STM32F7 の startup を見る。
startup_stm32f7xx.s と startup_stm32f4xx.s が同じ内容だ。
後で修正するつもりなのか？それとも同じで正しいのか？
さて、もう一度 release note を見てみる。
コンパイラは
4.9.3 20141119 (release) [ARM/embedded-4_9-branch revision 218278]
ということなのでいつからか分からないが Sourcery g++ から Launchpad に変わったようだ。
そして lib_nano が使える。
nano と言うぐらいだから 小さくなっているのだろう。
これは試してみたい。
参照：
Raisonance
RKit-ARM 1.58.15.0093
Ride 7.54.15.0083
release note を見てみると STM32F7 がサポートされているのと GCC が 4.9.3 になっている。
STMicroelectronics の STM32F7 サポートは Raisonance が最初かもしれない。
面白そうなのでこのバージョンもインストールしてみる。
少し中をのぞいてみよう。
今回からサポートされた STM32F7 の startup を見る。
startup_stm32f7xx.s と startup_stm32f4xx.s が同じ内容だ。
後で修正するつもりなのか？それとも同じで正しいのか？
さて、もう一度 release note を見てみる。
コンパイラは
4.9.3 20141119 (release) [ARM/embedded-4_9-branch revision 218278]
ということなのでいつからか分からないが Sourcery g++ から Launchpad に変わったようだ。
そして lib_nano が使える。
nano と言うぐらいだから 小さくなっているのだろう。
これは試してみたい。
参照：
Raisonance
GNU Tools for ARM Embedded Processors ― 2015年04月12日 12時22分06秒
さあ newlib-nano を使ってみよう。
使うために printf と syscall ぐらい入れておこう。
テストする環境は
さて、この後どうすればよいの？
とりあえず
Raisonance\Ride\arm-gcc\share\doc\gcc-arm-none-eabi\readme.txt を読んでみる。
どうやらリンク時に
--specs=nano.specs
を付ければよいらしい。
やってみる。
hex file で 18,092 bytes だった。
もともとが newlib で 103,846 bytes だったからかなり小さくなった。
この状態では Integer only なので %f を使うためにはコマンドオプション -u _printf_float を追加する。（scanf の場合は -u _scanf_float）
hex file で 61,038 bytes になった。
ちなみに、Optimization を Level2(Size) にすると
18,047 ( --specs=nano.specs)
60,993 ( --specs=nano.specs -u _printf_float)
103,817 ()
サイズは Optimization default とたいして変わらない。
結果：
以前テストした CooCox や LPCXpresso の printf に比べても nano はすこし大きいことが分かる。
しかし、手間を考えると便利かもしれない。
使うために printf と syscall ぐらい入れておこう。
テストする環境は
Keil MDK-ARM V4.53 ARM GCC/embedded 4.9.3 revision 218278 Startup は Atollic の startup_LPC11xx.s Linker script は RAISONANCE Ride7 を使い LPC1114FHN33 で 自動生成したもの syscall と SystemInit はダミー Optimization は default
さて、この後どうすればよいの？
とりあえず
Raisonance\Ride\arm-gcc\share\doc\gcc-arm-none-eabi\readme.txt を読んでみる。
どうやらリンク時に
--specs=nano.specs
を付ければよいらしい。
やってみる。
hex file で 18,092 bytes だった。
もともとが newlib で 103,846 bytes だったからかなり小さくなった。
この状態では Integer only なので %f を使うためにはコマンドオプション -u _printf_float を追加する。（scanf の場合は -u _scanf_float）
hex file で 61,038 bytes になった。
ちなみに、Optimization を Level2(Size) にすると
18,047 ( --specs=nano.specs)
60,993 ( --specs=nano.specs -u _printf_float)
103,817 ()
サイズは Optimization default とたいして変わらない。
結果：
以前テストした CooCox や LPCXpresso の printf に比べても nano はすこし大きいことが分かる。
しかし、手間を考えると便利かもしれない。
Raisonance Ride7 & ARM Tools (20) ― 2015年04月14日 21時09分42秒
RKit-ARM が STM32F7 をサポートしたので私の環境でも動作確認をしてみる。
RKit-ARM_1.58.15.0093 がサポートしているのは以下の MPU 。
STM32F746xE
STM32F746xG
STM32F756xE
STM32F756xG
スクリプトを書き換え HFARM.XML と registry と sim に STM32F746xE を追加する。
スタートアップは startup_stm32f7xx.s の .cpu を cortex-m7 に変更するだけにしておこう。
さっそく New Project で STM32F746xE のプロジェクトを作り、ダミーの main を入れコンパイルしてみる。
問題なくコンパイルが通る。
こういう場合うまく行っているように見えてけっこういろいろ問題があったりするものだ。
まず ApplicationDirectory の中を見ていこう。
リンカースクリプトは
sections_FLASH.ld
STM32F746_512K_192K_DEF.ld
STM32F746_512K_192K_FLASH.ld
STM32F74x_COMMON.ld
ができている。
中身も問題ないようだ。
次に Application0.elf.ld (ApplicationName.elf.ld)を見るとライブラリが
"smallprintf_thumb.a"
"STM32x_io_putchar_thumb.a"
になっている。ここは
"smallprintf_thumb_fpu.a"
"STM32x_io_putchar_thumb_fpu.a"
でなければならないはずだ。
まだスクリプトにおかしな所があるようだ。
GNUtools.js を調べてみると (corename=="Cortex-M4+FPU") はあるのに (corename=="Cortex-M7+FPU") が無い。
(corename=="Cortex-M7+FPU") を追加する。
ところで、ライブラリは Cortex-M4 で作ってあるが Cortex-M7 と共通と見てよいのだろうか？
そうでなければ Cortex-M7 用にライブラリの種類を増やさなければならない。
それ以前に、そもそも io_putchar と small_printf は STM32F7xx で動くのだろうか？
振り返ってみれば Raisonance は何かと抜けていることが多い。
このコアチェックの部分では corename と core をチェックしているが registry には core の項目が無いので有効なのは corename だけだ。
こういったちぐはぐな所がいたるところにある。
だいたい デバイスに関係する物が HFARM.XML 、sim file 、registry と多すぎるのも問題だ。
今回のテストでは Cortex-M7 の設定でコンパイルが通ったと言うことだけでそれ以外の部分は見直しが必要だろう。
いや、ローカルライブラリを使わない設定ならば問題ないのかもしれない。
この際ついでなので STM32L476xC も試してみよう。
同様に関係する部分のスクリプトを書き換え HFARM.XML と registry と sim に STM32L476xC を追加する。
スタートアップは startup_stm32f4xx.s をリネームして startup_stm32l4xx.s にし .cpu を cortex-m4 に変更する。（この際 startup_stm32f4xx.s も cortex-m4 に修正しておこう）
STM32L4x_COMMON.ld を作成して C:\Program Files\Raisonance\Ride\lib\ARM に入れる。
確認のため New Project で STM32L476xC のプロジェクトを作り、ダミーの main を入れコンパイルしてみる。
問題なくコンパイルが通る。
というわけで STM32 の場合 Raisonance が力を入れていることもあってデバイスの追加も比較的簡単だ。
RKit-ARM_1.58.15.0093 がサポートしているのは以下の MPU 。
STM32F746xE
STM32F746xG
STM32F756xE
STM32F756xG
スクリプトを書き換え HFARM.XML と registry と sim に STM32F746xE を追加する。
スタートアップは startup_stm32f7xx.s の .cpu を cortex-m7 に変更するだけにしておこう。
さっそく New Project で STM32F746xE のプロジェクトを作り、ダミーの main を入れコンパイルしてみる。
問題なくコンパイルが通る。
こういう場合うまく行っているように見えてけっこういろいろ問題があったりするものだ。
まず ApplicationDirectory の中を見ていこう。
リンカースクリプトは
sections_FLASH.ld
STM32F746_512K_192K_DEF.ld
STM32F746_512K_192K_FLASH.ld
STM32F74x_COMMON.ld
ができている。
中身も問題ないようだ。
次に Application0.elf.ld (ApplicationName.elf.ld)を見るとライブラリが
"smallprintf_thumb.a"
"STM32x_io_putchar_thumb.a"
になっている。ここは
"smallprintf_thumb_fpu.a"
"STM32x_io_putchar_thumb_fpu.a"
でなければならないはずだ。
まだスクリプトにおかしな所があるようだ。
GNUtools.js を調べてみると (corename=="Cortex-M4+FPU") はあるのに (corename=="Cortex-M7+FPU") が無い。
(corename=="Cortex-M7+FPU") を追加する。
ところで、ライブラリは Cortex-M4 で作ってあるが Cortex-M7 と共通と見てよいのだろうか？
そうでなければ Cortex-M7 用にライブラリの種類を増やさなければならない。
それ以前に、そもそも io_putchar と small_printf は STM32F7xx で動くのだろうか？
振り返ってみれば Raisonance は何かと抜けていることが多い。
このコアチェックの部分では corename と core をチェックしているが registry には core の項目が無いので有効なのは corename だけだ。
こういったちぐはぐな所がいたるところにある。
だいたい デバイスに関係する物が HFARM.XML 、sim file 、registry と多すぎるのも問題だ。
今回のテストでは Cortex-M7 の設定でコンパイルが通ったと言うことだけでそれ以外の部分は見直しが必要だろう。
いや、ローカルライブラリを使わない設定ならば問題ないのかもしれない。
この際ついでなので STM32L476xC も試してみよう。
同様に関係する部分のスクリプトを書き換え HFARM.XML と registry と sim に STM32L476xC を追加する。
スタートアップは startup_stm32f4xx.s をリネームして startup_stm32l4xx.s にし .cpu を cortex-m4 に変更する。（この際 startup_stm32f4xx.s も cortex-m4 に修正しておこう）
STM32L4x_COMMON.ld を作成して C:\Program Files\Raisonance\Ride\lib\ARM に入れる。
確認のため New Project で STM32L476xC のプロジェクトを作り、ダミーの main を入れコンパイルしてみる。
問題なくコンパイルが通る。
というわけで STM32 の場合 Raisonance が力を入れていることもあってデバイスの追加も比較的簡単だ。
最近のコメント