!stm32もう少し


https://github.com/rogerclarkmelbourne/Arduino_STM32/wiki/Installation
ここに従ってWindows上のArduino環境を整えてみた。

Serialモードだと書き込みができることを確認。
そしてplatformioとは違って、書き込み後に実行もできている(一度だけ)ソフトウェアリセット的なものを送っているのだろう。

blinkのスケッチはピン番号33となっていてこれはボード上だと PC_14のことらしい、ボード上にLEDがあるのはPC_13なので惜しい・・・


次にusbbootloaderを試してみる。
おおこれは簡単だ。導入は面倒だけど、これを入れるとgenericなボードが一気にArduinoっぽくなるな。。

手でResetを押す部分は何か対応できそうDTR送ってるとかコンソールには出ていたし。


!!別のブートローダー
https://github.com/jonatanolofsson/maple-bootloader/tree/mini-boot
これをつかう

PB8が強制DFU切り替えっぽい

PB8がHIGHで、USBを抜き差しするとDFU待ち受けになる
PB8をLOWでRESETを押すとプログラムが走る。

プログラムが走る前に2秒ほどDFUを待ち受けている気がするがうまくコミュニケーションできない。
またPB8をHIGHにして、RESETを押すだけではDFU待ち受けにならないように見える

http://stm32f4.web.fc2.com/STM32F1/momiji_momi2.html
もみじボードも同じ仕様だった

!!もみじボードSDカード検証
したいけれどもRAMで動くバイナリの作成ができなそう・・

恐る恐るmaple-ideをダウンロードしてみる http://docs.leaflabs.com/docs.leaflabs.com/index.html

どうやらArduinoでusbbootloaderを使うために入れたドライバがそのまま使える模様

ということで必要なバイナリは作ることができた。

maple miniではBOARD_LED_PINはgenericボードのPB1と同じらしい

!!! SDブートできた!!
これは感動する SRAMブートができた。

!!デバッグがしたい
文字を出したい。
キャラクタ液晶のSPIかI2Cで3.3V動くものがほしい
手元にないかな・・

http://aitendo.info/?p=121

これが簡単そう

なぜか電源が5Vじゃないと動かないっぽいけど信号は3.3Vで動いた

!!Mapleのldをパクる
ちょっと読んでみる

>>
$ cat ram.ld
/*
 * Maple Mini (STM32F103CBT6, medium density) linker script for RAM builds.
 */

/*
 * Define memory spaces.
 */
MEMORY
{
  ram (rwx) : ORIGIN = 0x20000C00, LENGTH = 17K
  rom (rx)  : ORIGIN = 0x08005000, LENGTH = 0K
}

/*
 * Use medium density device vector table
 */
GROUP(libcs3_stm32_med_density.a)

REGION_ALIAS("REGION_TEXT", ram);
REGION_ALIAS("REGION_DATA", ram);
REGION_ALIAS("REGION_BSS", ram);
REGION_ALIAS("REGION_RODATA", ram);

/*
 * Define the rest of the sections
 */
INCLUDE common.inc
<<

このファイルSTM32のリポジトリにもあるな・・あれを使えばいいのかな

Arduino/hardware/Arduino_STM32/STM32F1/variants/maple_mini/ld

これと同じっぽい

!boards.txtを見てみよう
!!Flash

こっちがstm32duinoのほう。こっちにRAM用のビルドオプションを追加したい
bootloader_versionが2つあるが上のほうがオリジナルのMapleMiniのものらしい。
>>
##############################################################
mapleMini.name=Maple Mini

mapleMini.build.board=MAPLE_MINI
mapleMini.vid.0=0x1EAF
mapleMini.pid.0=0x0004
mapleMini.build.core=maple
mapleMini.build.cpu_flags=-DMCU_STM32F103CB -DSERIAL_USB
mapleMini.build.variant=maple_mini
mapleMini.upload.usbID=1EAF:0003

mapleMini.upload.tool=maple_upload
mapleMini.upload.protocol=maple_dfu
mapleMini.upload.use_1200bps_touch=false
mapleMini.upload.file_type=bin
mapleMini.upload.auto_reset=true

mapleMini.menu.bootloader_version.original = Original (17k RAM,108k Flash)
mapleMini.menu.bootloader_version.original.build.vect=VECT_TAB_ADDR=0x8005000
mapleMini.menu.bootloader_version.original.build.ldscript=ld/flash.ld
mapleMini.menu.bootloader_version.original.upload.ram.maximum_size=17408
mapleMini.menu.bootloader_version.original.upload.flash.maximum_size=110592
mapleMini.menu.bootloader_version.original.upload.maximum_size=110592
mapleMini.menu.bootloader_version.original.upload.altID=1

mapleMini.menu.bootloader_version.bootloader20 = Bootloader 2.0 (20k RAM,120k Flash)
mapleMini.menu.bootloader_version.bootloader20.build.vect=VECT_TAB_ADDR=0x8002000
mapleMini.menu.bootloader_version.bootloader20.build.ldscript=ld/bootloader_20.ld
mapleMini.menu.bootloader_version.bootloader20.upload.ram.maximum_size=20480
mapleMini.menu.bootloader_version.bootloader20.upload.flash.maximum_size=122880
mapleMini.menu.bootloader_version.bootloader20.upload.maximum_size=122880
mapleMini.menu.bootloader_version.bootloader20.upload.altID=2
<<

こっちがMapleIDEのほう 内容はおそらく上のFlashとおなじはず 
>>
##############################################################
maple_mini.name=LeafLabs Maple Mini Rev 2 to Flash

maple_mini.upload.file_type=bin
maple_mini.upload.maximum_size=108000
maple_mini.upload.ram.maximum_size=17000
maple_mini.upload.flash.maximum_size=108000
# FIXME
maple_mini.upload.usbID=1EAF:0003
maple_mini.upload.altID=1
maple_mini.upload.uploader=dfu-util
maple_mini.upload.auto_reset=true

maple_mini.build.board=maple_mini
maple_mini.build.mcu=STM32F103CB
maple_mini.build.family=cortex-m3
maple_mini.build.f_cpu=72000000L
maple_mini.build.core=maple
maple_mini.build.submdl=stm32f103
maple_mini.build.vect=VECT_TAB_FLASH
maple_mini.build.linker=maple_mini/flash.ld
maple_mini.build.using=armcompiler
maple_mini.build.density=STM32_MEDIUM_DENSITY
maple_mini.build.error_led_port=GPIOB
maple_mini.build.error_led_pin=1

<<

注釈をつけてみる
>>
##############################################################
maple_mini.name=LeafLabs Maple Mini Rev 2 to Flash

maple_mini.upload.file_type=bin # 同じ
maple_mini.upload.maximum_size=108000 # メニューのほうにある110592
maple_mini.upload.ram.maximum_size=17000 # メニューのほうにある17408
maple_mini.upload.flash.maximum_size=108000 # メニューのほうにある 110592
# FIXME
maple_mini.upload.usbID=1EAF:0003 # 同じ
maple_mini.upload.altID=1 # メニューのほうにある 同じ
maple_mini.upload.uploader=dfu-util # 独自っぽい
maple_mini.upload.auto_reset=true # 同じ

maple_mini.build.board=maple_mini # 名前だから違ってもいいのかな? MAPLE_MINI
maple_mini.build.mcu=STM32F103CB # ない
maple_mini.build.family=cortex-m3 # ない
maple_mini.build.f_cpu=72000000L # ない
maple_mini.build.core=maple # おなじ
maple_mini.build.submdl=stm32f103 # ない
maple_mini.build.vect=VECT_TAB_FLASH # VECT_TAB_ADDR=0x8005000
maple_mini.build.linker=maple_mini/flash.ld # ldscriptというのと同じなのでは? ld/flash.ld
maple_mini.build.using=armcompiler # ない
maple_mini.build.density=STM32_MEDIUM_DENSITY # ない
maple_mini.build.error_led_port=GPIOB # ない
maple_mini.build.error_led_pin=1 # ない
<<

!!SRAM
これはMapleのほうにしかない

>>
############################
maple_miniRAM.name=LeafLabs Maple Mini Rev 2 to RAM

maple_miniRAM.upload.file_type=bin
maple_miniRAM.upload.maximum_size=17000
maple_miniRAM.upload.ram.maximum_size=17000
maple_miniRAM.upload.flash.maximum_size=108000
maple_miniRAM.upload.usbID=1EAF:0003
maple_miniRAM.upload.altID=0
maple_miniRAM.upload.uploader=dfu-util
maple_miniRAM.upload.auto_reset=true

maple_miniRAM.build.board=maple_mini
maple_miniRAM.build.mcu=STM32F103CB
maple_miniRAM.build.family=cortex-m3
maple_miniRAM.build.f_cpu=72000000L
maple_miniRAM.build.core=maple
maple_miniRAM.build.submdl=stm32f103
maple_miniRAM.build.vect=VECT_TAB_RAM
maple_miniRAM.build.linker=maple_mini/ram.ld
maple_miniRAM.build.using=armcompiler
maple_miniRAM.build.density=STM32_MEDIUM_DENSITY
maple_miniRAM.build.error_led_port=GPIOB
maple_miniRAM.build.error_led_pin=1

<<

注釈をつけてみる
>>
############################
maple_miniRAM.name=LeafLabs Maple Mini Rev 2 to RAM

maple_miniRAM.upload.file_type=bin # Flashと同じ
maple_miniRAM.upload.maximum_size=17000 # SRAMの大きさにしてあるようだ Flashの時はFlashの大きさ108000とかになっている
maple_miniRAM.upload.ram.maximum_size=17000 # Flashと同じ
maple_miniRAM.upload.flash.maximum_size=108000 # Flashと同じ
maple_miniRAM.upload.usbID=1EAF:0003 # Flashと同じ
maple_miniRAM.upload.altID=0 # Flashの時は1 アップロードモードの識別子なのは知っているが何かの制御に使ってるのか?
maple_miniRAM.upload.uploader=dfu-util # 独自っぽい
maple_miniRAM.upload.auto_reset=true # Flashとおなじ

maple_miniRAM.build.board=maple_mini # Flashとおなじ
maple_miniRAM.build.mcu=STM32F103CB # Flashとおなじ
maple_miniRAM.build.family=cortex-m3 # Flashとおなじ
maple_miniRAM.build.f_cpu=72000000L # Flashとおなじ
maple_miniRAM.build.core=maple # Flashとおなじ
maple_miniRAM.build.submdl=stm32f103 # Flashとおなじ
maple_miniRAM.build.vect=VECT_TAB_RAM # Flashのときは VECT_TAB_FLASHだった これは気になる そしてこれは何の制御に使ってるのか?
maple_miniRAM.build.linker=maple_mini/ram.ld # Flashのときは maple_mini/flash.ld だった これもきになる
maple_miniRAM.build.using=armcompiler # Flashとおなじ
maple_miniRAM.build.density=STM32_MEDIUM_DENSITY # Flashとおなじ
maple_miniRAM.build.error_led_port=GPIOB # Flashとおなじ
maple_miniRAM.build.error_led_pin=1 # Flashとおなじ

<<

一見するとlinkerの部分だけ合わせておけばよさそう。


! ArduinoIDE+stm32duinoでSRAMに乗せられるbinファイルを作る。

これができればもみじボードのSDブート用のバイナリが作れる。
今はMapleIDEでしか作れないが、ライブラリの整備状況などはArduinoIDE+stm32duinoのほうが進んでいるので、そっちを使いたい。あとMapleIDEはもう開発が死んでいるので使いたくない。

とりあえずそれっぽいboards.txtを追記

とりあえずコンパイルはできた。
どうもこれをそのまま転送したらMapleIDEと同様に動いているように見える。
resetボタンを押してもSRAMはフラッシュされないようだ

電源を落とすとFlashのほうのプログラムが動く この挙動はおもしろいな

さて、バイナリをSDカードに移してみる。



Flashには単にLEDが200msで点滅するだけのプログラムを入れる。
SDカードにはLCDにHelloWorldと表示するAUTOEXEC.BINを入れる。

とりあえず電源をOFF/ONすると 200msのLEDの点滅が確認できる。

SDカードのdetectの信号をオンにしつつ電源をOFF/ONする。

何回かおかしなことになったが・・・

LCDに何か表示されてる!!
でもなんか違う?


いい感じではあるのだが・・

で、これはSRAMにロードするだけだから、再びSDカードのdetect信号をOFF/ONすると 200msのLEDの点滅に戻る。

もっかいやってみる
うまくいかないな。。

SDカードに入れずにIDEからSRAMモードで書き込むと、、、 やはりおかしい つまりBINファイルが腐ってるということか。


ram.ldが参照しているcommon.incがかなり違っている・・
これをMapleIDEが持っているものと差し替えると・・・

そんな簡単にはうまくいかない・・・


定数テーブルがずれてるのかな


ram.ldをそのまま利用 -> 一応動くけど挙動がおかしい、特に定数が変
ram.ldを利用かつcommon.incにMapleIDEのものを利用 -> まったくうごかない


!!配置確認
うごいてないやつ

>>
Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         00002998  20000c00  20000c00  00000c00  2**4
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .rodata       00000390  20003598  20003598  00003598  2**3
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  2 .ARM.exidx    00000008  20003928  20003928  00003928  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  3 .data         000007d0  20003930  20003930  00003930  2**3
                  CONTENTS, ALLOC, LOAD, DATA
  4 .bss          00000340  20004100  20004100  00004100  2**2
                  ALLOC
<<

うごいてるやつ
>>
Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         00002888  20000c00  20000c00  00000c00  2**4
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .rodata       000003c4  20003488  20003488  00003488  2**3
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  2 .ARM.exidx    00000008  2000384c  2000384c  0000384c  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  3 .text.align   00000004  20003854  20003854  00003854  2**0
                  ALLOC, CODE
  4 .data         000005b8  20003858  20003858  00003858  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  5 .bss          000001a0  20003e10  20003e10  00003e10  2**2
                  ALLOC
<<

dataの前にtext.alignがあるのはちょっと違うかも


動くけどちょっと変な奴
>>
Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         000029d0  20000c00  20000c00  00000c00  2**4
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .ARM.exidx    00000008  200035d0  200035d0  000035d0  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  2 .data         000007d8  200035d8  200035d8  000035d8  2**3
                  CONTENTS, ALLOC, LOAD, DATA
  3 .rodata       00000394  20003db0  20003db0  00003db0  2**3
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  4 .bss          00000344  20004144  20004144  00004144  2**2
                  ALLOC
<<

そもそも読めない

!!容量なのでは?
小さいスケッチならSRAMから起動するように見える。

ということで小さいスケッチをつかってみる

FlashにはLCDにflash testと表示するプログラムを入れる。
SDカードにはやたらLEDを光らせるプログラムを入れる

とりあえず電源をOFF/ONすると LCDにflash testと表示することが確認できる。

SDカードのdetectの信号をオンにしつつ電源をOFF/ONする。

LEDがやたらちかちかした!

SDカードから読み込めていることが確認できる。

!!容量について
16kということらしい

flash64k ram20k ということなので、このram20kのところがこれなのだろう。
(ちなみにatmega328だと flash32k ram 2k とかだったはず)

たかだかLCDにHello Worldと表示するだけで、この容量を超えているとは思えないのだが・・・

とりあえず、ArduinoIDEでもldファイルを書き換えればもみじボードのファームウェアで読み込めるバイナリが吐き出せることが分かった。

SDカードからのブートはリセットボタンでも起動することもわかった。


!SD->Flash
やりたい
もみじボードのファームウェアを改造して、SDカード上にあるbinファイルをflashに焼きこむようにしたい。

ソースコードを読んでみよう。

!!正しく書き込めなかったが、何が書かれたか見てみたい
stm32flashにflashの中身をダンプする機能があった

正しく書き込めていない場合のものをみたが、ピンとこない
正しく動いているものをとりあえず見てみよう


お、0x00005000 にプログラムが書いてある!これだ

正しく書き込めていないときはここにデータがない

Eraseの単位がページ単位なのを忘れていて、せっかく書いたものを消してしまっていたようだ

http://denshikousakusenka.jimdo.com/%E5%85%B1%E9%80%9A%E3%83%A9%E3%82%A4%E3%83%96%E3%83%A9%E3%83%AA/internal-rom/stm32/

ここをみると消さないと書けないようだ。
0x400ごとに1ページがあるらしい

かけた!
ただしずれてる・・

もしかしたらFlashのアドレスとプログラムから見えているアドレスがそれだけずれているのでは?ということで書き始めの位置をずらしてみる。

何回かやってもランダムに書く位置が移動しているようだ。。
いろいろやっているうちにグローバル変数の初期値がランダムになっていることが分かった。
明示的に初期化に書いてあるのに・・

ということで処理の初めに初期化代入を書くようにしたら動いた。


!!不明点の調査
!!!先頭ベクタの謎
プログラムの先頭には
2000-5000が書き込まれているが、これは何か?

スタックポインタの初期ベクタ と記載してある(http://stm32f4.web.fc2.com/STM32F1/momiji_momi2.html )

RAM自体は2000 0000から始まっているが、その間には何があるのか?


それはSDカードに書き込むバイナリのobjdumpを見てみるとわかるはず

.textはそのままフラッシュに書かれている。これはブートローダーのある0800-0000 -> 0800 5000を避けて配置してある
.dataはフラッシュ上に初期値があり、変数としての実態は2000 0c00に配置してあるようだ
.rodataはなんだかわからないけどflashにある
.bssは2000 13d8なのでSRAMに配置してある

そのうえで2000-5000がスタックポインタの初期ベクタであると。
ヒープはどこからとるのかな

STM32_SRAM_ENDにこの値がある。
名前的にはSRAMの末尾を表しているようだ。これを参照しているソースコードがないのが気になる・・

ヒープはnmしてみると HeapStartみたいな名前がついていた。
これは.data, .bssセクションのうしろだった。

つまりSRAMはグローバル変数の領域、ヒープ領域、スタック領域としてしっかり確保されているようだ。

つまり今の指定方法で問題なさそう。

>>
Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         000029d0  08005000  08005000  00005000  2**4
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .ARM.exidx    00000008  080079d0  080079d0  000079d0  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  2 .data         000007d8  20000c00  080079d8  00008c00  2**3
                  CONTENTS, ALLOC, LOAD, DATA
  3 .rodata       00000394  080081b0  080081b0  000101b0  2**3
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  4 .bss          00000340  200013d8  200013d8  000113d8  2**2
                  ALLOC
  5 .debug_aranges 00000e38  00000000  00000000  00010548  2**3
                  CONTENTS, READONLY, DEBUGGING
  6 .debug_info   0001b8fb  00000000  00000000  00011380  2**0
                  CONTENTS, READONLY, DEBUGGING
  7 .debug_abbrev 0000544a  00000000  00000000  0002cc7b  2**0
                  CONTENTS, READONLY, DEBUGGING
  8 .debug_line   00008871  00000000  00000000  000320c5  2**0
                  CONTENTS, READONLY, DEBUGGING
  9 .debug_frame  00002118  00000000  00000000  0003a938  2**2
                  CONTENTS, READONLY, DEBUGGING
 10 .debug_str    00006a69  00000000  00000000  0003ca50  2**0
                  CONTENTS, READONLY, DEBUGGING
 11 .debug_loc    000076de  00000000  00000000  000434b9  2**0
                  CONTENTS, READONLY, DEBUGGING
 12 .ARM.attributes 00000029  00000000  00000000  0004ab97  2**0
                  CONTENTS, READONLY
 13 .debug_ranges 00001628  00000000  00000000  0004abc0  2**0
                  CONTENTS, READONLY, DEBUGGING
 14 .comment      00000070  00000000  00000000  0004c1e8  2**0
                  CONTENTS, READONLY
<<


!!!0800-0000 -> 0800-5000の隙間には何があるのか?

>>
$ arm-none-eabi-readelf -S  build/maple_boot.elf
There are 32 section headers, starting at offset 0x3025c:

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .isr_vector       PROGBITS        08000000 010000 0000f0 00   A  0   0  1
  [ 2] .flashtext        PROGBITS        080000f0 0201d8 000000 00   W  0   0  1
  [ 3] .text             PROGBITS        080000f0 0100f0 0038ec 00  AX  0   0  4
  [ 4] .data             PROGBITS        20000000 020000 0001d8 00  WA  0   0  4
  [ 5] .bss              NOBITS          200001d8 0201d8 000484 00  WA  0   0  4
  [ 6] .bss.bDeviceState NOBITS          2000065c 0201d8 000004 00  WA  0   0  4
  [ 7] .bss.bIntPackSOF  NOBITS          20000660 0201d8 000001 00  WA  0   0  1
  [ 8] .bss.blockCnt     NOBITS          20000661 0201d8 000001 00  WA  0   0  1
  [ 9] .bss.userFlash    NOBITS          20000662 0201d8 000001 00  WA  0   0  1
  [10] .bss.dfuBusy      NOBITS          20000663 0201d8 000001 00  WA  0   0  1
  [11] .bss.userFirmware NOBITS          20000664 0201d8 000004 00  WA  0   0  4
  [12] .bss.thisBlockLen NOBITS          20000668 0201d8 000002 00  WA  0   0  2
  [13] .bss.Data_Mul_Max NOBITS          2000066a 0201d8 000001 00  WA  0   0  1
  [14] .bss.FatFs        NOBITS          2000066c 0201d8 000004 00  WA  0   0  4
  [15] .bss.Timer1       NOBITS          20000670 0201d8 000004 00  WA  0   0  4
  [16] .bss.Timer2       NOBITS          20000674 0201d8 000004 00  WA  0   0  4
  [17] .bss.CardType     NOBITS          20000678 0201d8 000001 00  WA  0   0  1
  [18] ._usrstack        NOBITS          20000679 0201d8 000103 00  WA  0   0  1
  [19] .comment          PROGBITS        00000000 0201d8 000038 01  MS  0   0  1
  [20] .ARM.attributes   ARM_ATTRIBUTES  00000000 020210 00002f 00      0   0  1
  [21] .debug_aranges    PROGBITS        00000000 02023f 000658 00      0   0  1
  [22] .debug_info       PROGBITS        00000000 020897 004f53 00      0   0  1
  [23] .debug_abbrev     PROGBITS        00000000 0257ea 0013ab 00      0   0  1
  [24] .debug_line       PROGBITS        00000000 026b95 001aed 00      0   0  1
  [25] .debug_frame      PROGBITS        00000000 028684 001940 00      0   0  4
  [26] .debug_str        PROGBITS        00000000 029fc4 001a44 01  MS  0   0  1
  [27] .debug_loc        PROGBITS        00000000 02ba08 000f16 00      0   0  1
  [28] .debug_ranges     PROGBITS        00000000 02c91e 000660 00      0   0  1
  [29] .shstrtab         STRTAB          00000000 0300cb 00018e 00      0   0  1
  [30] .symtab           SYMTAB          00000000 02cf80 002270 10     31 319  4
  [31] .strtab           STRTAB          00000000 02f1f0 000edb 00      0   0  1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings)
  I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown)
  O (extra OS processing required) o (OS specific
<<


0800 0000 -> 0800 39dc(= 0000f0 + 0038ec)

同じ情報だけどobjdumpもみてみる

>>
VMAは リンカがアドレスを解決する際に利用するアドレス
LMAは プログラムやデータが実際に配置されるアドレス

変数のアドレス(VMA)はRAMにありますが、実際の初期値はROMに置かないと消えてしまうため、配置アドレス(LMA)は変数アドレス(VMA)と一致しません
<<

http://www.ertl.jp/~takayuki/readings/info/no02.html


なるほど。
".data"セクションはフラッシュに配置するけど、データはROMにもあるということか
".data"セクションはグローバル変数などが入っているらしい。なるほどなるほど。
".text"セクションはプログラムそのものが入るみたいだ


フラッシュについては、ここに書かれているものを残しておく必要がある。
今回の例だと0800-0000 -> 0800-39dcを保護しておく必要があるということか。

つまり、もう少しケチれそう

実際stm32duinoでは8002000がブートローダーの領域となっている。

>>
$ arm-none-eabi-objdump -h  build/maple_boot.elf

build/maple_boot.elf:     file format elf32-littlearm

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .isr_vector   000000f0  08000000  08000000  00010000  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  1 .flashtext    00000000  080000f0  080000f0  000201d8  2**0
                  CONTENTS
  2 .text         000038ec  080000f0  080000f0  000100f0  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  3 .data         000001d8  20000000  080039dc  00020000  2**2  ここがVMAとLMAが異なっている部分。グローバル変数がここに?
                  CONTENTS, ALLOC, LOAD, DATA
  4 .bss          00000484  200001d8  08003bb4  000201d8  2**2
                  ALLOC
  5 .bss.bDeviceState 00000004  2000065c  08004038  000201d8  2**2
                  ALLOC
  6 .bss.bIntPackSOF 00000001  20000660  0800403c  000201d8  2**0
                  ALLOC
  7 .bss.blockCnt 00000001  20000661  0800403d  000201d8  2**0
                  ALLOC
  8 .bss.userFlash 00000001  20000662  0800403e  000201d8  2**0
                  ALLOC
  9 .bss.dfuBusy  00000001  20000663  0800403f  000201d8  2**0
                  ALLOC
 10 .bss.userFirmwareLen 00000004  20000664  08004040  000201d8  2**2
                  ALLOC
 11 .bss.thisBlockLen 00000002  20000668  08004044  000201d8  2**1
                  ALLOC
 12 .bss.Data_Mul_MaxPacketSize 00000001  2000066a  08004046  000201d8  2**0
                  ALLOC
 13 .bss.FatFs    00000004  2000066c  08004048  000201d8  2**2
                  ALLOC
 14 .bss.Timer1   00000004  20000670  0800404c  000201d8  2**2
                  ALLOC
 15 .bss.Timer2   00000004  20000674  08004050  000201d8  2**2
                  ALLOC
 16 .bss.CardType 00000001  20000678  08004054  000201d8  2**0
                  ALLOC
 17 ._usrstack    00000103  20000679  08004055  000201d8  2**0
                  ALLOC
 18 .comment      00000038  00000000  00000000  000201d8  2**0
                  CONTENTS, READONLY
 19 .ARM.attributes 0000002f  00000000  00000000  00020210  2**0
                  CONTENTS, READONLY
 20 .debug_aranges 00000658  00000000  00000000  0002023f  2**0
                  CONTENTS, READONLY, DEBUGGING
 21 .debug_info   00004f53  00000000  00000000  00020897  2**0
                  CONTENTS, READONLY, DEBUGGING
 22 .debug_abbrev 000013ab  00000000  00000000  000257ea  2**0
                  CONTENTS, READONLY, DEBUGGING
 23 .debug_line   00001aed  00000000  00000000  00026b95  2**0
                  CONTENTS, READONLY, DEBUGGING
 24 .debug_frame  00001940  00000000  00000000  00028684  2**2
                  CONTENTS, READONLY, DEBUGGING
 25 .debug_str    00001a44  00000000  00000000  00029fc4  2**0
                  CONTENTS, READONLY, DEBUGGING
 26 .debug_loc    00000f16  00000000  00000000  0002ba08  2**0
                  CONTENTS, READONLY, DEBUGGING
 27 .debug_ranges 00000660  00000000  00000000  0002c91e  2**0
                  CONTENTS, READONLY, DEBUGGING<<
<<

!RAMに書く機能を削った話

https://github.com/rogerclarkmelbourne/Arduino_STM32/wiki/Bootloader
読んでおこう


There were a number of issues with using upload to RAM, and although its ID has been retained so that uploads to ram don't crash the IDE etc, it no longer does anything, and just returns and error to the uploader.

RAMにuploadする昨日は問題がある。しかし、このIDはIDEをクラッシュさせないためなどのために残してある。それは何もしないし、uploaderがエラーになるだけである。

Upload to RAM on Maple Mini and Maple boards was always almost completely useless, as the Maple mini only has 20k RAM, and most usable sketches take at least 20k.

MapleMiniとMapleのRAMにアップロードすることは完全に無意味だ。MapleMiniは20KのRAMしか持っておらず、意味のあるスケッチというのは20kを超えるものです。

However the main reason this has been disabled, is that there were issues with the bootloader being able to determine after a warm boot, whether it should run code in RAM or Flash.

しかしながら、この機能を無効化した理由はウォームブート時にブートローダーがRAMかFlashのどちらを実行すべきか決定するという問題があるからです。


The original code, relied on looking in the RAM for markers that suggested that the data at that location was a program, however this wasn't that reliable.

元のコードはRAMを見てそれがプログラムかどうかをということを見ることに頼っていますが、これは信頼できる情報ではありません。


Although it would be possible to use the backup registers (non volatile after soft boot) to store data about program start location, it was felt that as the RAM was so limited, it wasn't worth the hassle of rebuilding the RAM upload option to use backup ram as a flag) - and the sketch code could still overwrite the backup registers and break this option.

しかし、バックアップレジスタにプログラムをスタートする場所を退避するという方法をを使うことで実現可能になりますが、RAMはとても限られていると感じますし、その方法をとるための面倒なことをする価値はないです。そしてスケッチコードがバックアップレジスタを上書きしてしまうという可能性がまだ残ります。


!!なるほど
確かに今の方法ではRAMに特殊なデータが入った状態でリセットするとそのデータが意図せず実行されてしまう可能性があるということを理解できた。

!!RAMにあるコードとは?
3kをケチるのはまぁありかなとその場合はldファイルをstm32duinoのブートローダーの設定を使えばよい

あの3Kに何が入るかよくわかっていない。
普通に上書きしてしまっても良いような気もする。


!stm32をゲーム機にしたい
- SDカードの読み書き(どのくらいの容量を食うのかが知りたい)
- 液晶の操作(ucglibがstm32では動かないので、手で頑張る必要がある まぁSPIだし頑張ればいいかな)



5643382
wiki
1477835448