STM32H743 の USB が使えずの対策

CubeMX (4.25.0) で生成した STM32H743 の USB Audio, CDC の test code を自分流にアレンジして composite device として動作する様にしている. しかし, いつからか power on reset 後 USB が接続できず, PC が enum できない状態になってしまった. ただ, 一度 BOOT0 端子を high にして reset 解除を行なうと rom boot が動作する事になるが, 一旦, この rom boot を動作させた後, reset (power on reset でない) すると接続できていたので, この方法でずっと開発を行なっていた.
ただそろそろ,  power on reset 後に USB が認識できる様にしようと調べてみたが, 結論としては CubeMX で生成された code から power management の code を削除してしまったのが原因だったと思われる.

必要な code は以下の通り

HAL_PWREx_EnableUSBVoltageDetector();
内容は
PWR->CR3 |= PWR_CR3_USB33DEN;
を呼んでいるだけであるが, USB 用の 3.3V regulator を動作させるかどうかの電圧 detector の電源を on/off するもので,  USB を使用する前に on する必要がある. Reference manual には 5V を入力できてそれを 3.3V にする事ができるし, 3.3V を入力する事もできると書いているが,  Nucleo H743ZI の回路は 3.3V を接続されていて regulator を動作させる必要はない. しかし, この regulator を動作させるかさせないかの detect が動作させていない為, regulator の動作が不定になり, USB の動作ができなかったという事だと推察される.

現状 USB を initialize する時の Init(), Register(), Start() の後に code を入れたが, 使用前という事は Start()の前の気がしないではないが, cpu clock で数十数百程度の事なので, たぶんそれは細かすぎる事でなんでしょう.

以下 STM32H743ZI  reference manual DoclD029587 Rev3 から抜粋

追記 (201808050)
上記で rom boot からの reset でUSB が使えて件は, PWR->CR3 が power on reset 以外初期化をしない為に rom boot で USB33DEN を有効にしていてそれを reset 端子による reset 後も引き継いていた為でした (CR2 も同様).

以下 STM32H743ZI  reference manual DoclD029587 Rev3 (section 6 PWR)から抜粋

12TB RAID5 mount 出来ず, でも復活

 先日いきなり, Ubuntu 14.04 に接続している 12TBの RAID5 の disk が access できなくなった.
df してもそれほど問題がある様に思えない. ただ ls しても file がない. dmesg を見ると error っぽい log がある. HDDが動かなくなってはイヤなので fstab で mount 項目を comment out, RAID disk の電源はそのままに, PCだけ reboot した.
 
まず手動で mount すると syslog に以下のwarning が

Jun  7 07:03:46 waters kernel: [90179.663177] sd 9:0:0:0: [sdb] Attached SCSI disk
Jun  7 07:03:47 waters kernel: [90180.352750] EXT4-fs (sdb): ext4_check_descriptors: Checksum for group 3644 failed (10343!=7979)
Jun  7 07:03:47 waters kernel: [90180.352758] EXT4-fs (sdb): group descriptors corrupted!
 
ググってみると, superblock がおかしくなっているという事, mkfs 時に super block の backup が作られているので, 使用する superblock を backup の方を使うことで mount できる.

復活までの操作は
1.  mke2fs -n /dev/sdx   で該当 file system の情報を得る
2.  e2fsck.ext4 -b superblock -B blocksize /dev/sdx   で fsck する
3.  e2fsck.ext4 /dev/sdx  で念の為、通常の superblock で fsck


# mke2fs -n /dev/sdb
mke2fs 1.42.9 (4-Feb-2014)
/dev/sdb is entire device, not just one partition!
Proceed anyway? (y,n) y
Filesystem label=
OS type: Linux
Block size=4096 (log=2)                                               ### fsck で指定する block size
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
366276608 inodes, 2930212864 blocks
146510643 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=4294967296
89423 block groups
32768 blocks per group, 32768 fragments per group
4096 inodes per group
Superblock backups stored on blocks:                           ### 以下がsuperblock の list 今回は 32768 を使用
    32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,

    4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
   102400000, 214990848, 512000000, 550731776, 644972544, 1934917632,
   2560000000




# fsck.ext4 -b 32768 -B 4096 /dev/sdb
e2fsck 1.42.9 (4-Feb-2014)
Superblock needs_recovery flag is clear, but ジャーナル has data.
Recovery flag not set in backup superblock, so running ジャーナル anyway.
/dev/sdb: recovering journal
Pass 1: Checking iノードs, blocks, and sizes
Iノード 721821000 is in use, but has dtime set.  修正<y>? yes             ### ひたすら "Enter" を押す
Iノード 721821000 has imagic flag set.  クリア<y>? yes
Iノード 721821000 has a extra size (30009) which is invalid 修正<y>? yes
Iノード 721821001 is in use, but has dtime set.  修正<y>? yes
Iノード 721821001 has a extra size (61060) which is invalid 修正<y>? yes
Iノード 721821001 has 圧縮ion flag set on ファイルシステム without 圧縮ion support.  クリア<y>? yes
Iノード 721821001 has a bad extended attribute block 2459851454.  クリア<y>? yes
Iノード 721821001, i_size is 4609247913415050120, should be 0.  修正<y>? yes
Iノード 721821001, i_blocks is 34852892082033, should be 0.  修正<y>? yes
Iノード 721821002 is in use, but has dtime set.  修正<y>? yes
Iノード 721821002 has imagic flag set.  クリア<y>? yes
Iノード 721821002 has a extra size (41406) which is invalid 修正<y>? yes
legal block #3 (3411828393) in iノード 721821004.  CLEARED.
Block #4 (2834099418) causes symlink to be too big.  CLEARED.
Block #5 (223285474) causes symlink to be too big.  CLEARED.
Block #6 (151183681) causes symlink to be too big.  CLEARED.
Illegal block #7 (3028417134) in iノード 721821004.  CLEARED.
Block #8 (286251651) causes symlink to be too big.  CLEARED.
Block #9 (2027505565) causes symlink to be too big.  CLEARED.
Block #10 (1513751525) causes symlink to be too big.  CLEARED.
Illegal block #11 (3043589953) in iノード 721821004.  CLEARED.
Too many illegal blocks in iノード 721821004.Clear inode<y>? yes
Iノード 721821000 has a bad extended attribute block 1787912555.  クリア<y>? yes
Iノード 721821000 has INDEX_FL flag set but is not a ディレクトリ.Clear HTree index<y>? yes
Iノード 721821000, i_size is 5904482037710001798, should be 0.  修正<y>? yes
Iノード 721821000, i_blocks is 1997111956269, should be 0.  修正<y>? yes
Iノード 721821003 has INDEX_FL flag set but is not a ディレクトリ.Clear HTree index<y>? yes
Iノード 721821003, i_size is 7593185805256298082, should be 0.  修正<y>? yes
Iノード 721821003, i_blocks is 113575096955107, should be 0.  修正<y>? yes

Restarting e2fsck from the beginning...
Pass 1: Checking iノードs, blocks, and sizes

Running additional passes to resolve blocks claimed by more than one iノード...
Pass 1B: Rescanning for multiply-claimed blocks

：
：
Free blocks count wrong for グループ #9749 (32768, counted=1272).
Free blocks count wrong for グループ #9750 (32768, counted=1272).  
### ひたすら "Enter" 押すがかなり時間がかかるので 停止
 
# fsck.ext4 -y -b 32768 -B 4096 /dev/sdb         ### all yes を指定

# fsck.ext4 -y  /dev/sdb                                  ### 念の為, 通常の superblock を使用して fsck

# mount /dev/sdb /mnt                                  ### mount できた


RAID5 は壊れ出すと修復不可能だが, 今回は super blockがおかしくなっただけなので,なんとかなった.
しかし, いつ HDD が壊れてもしょうがない. 他の server に使用している同型の RAID5 は 2回 HDD を交換している. やはり backup がひつ必要だ. 幸い HDD が 6TBなどは 2,3万円で購入できる. RAID0 もでいいから 12TB の backup を用意しておいた方がよいだろう.

RIGOL DSA832E-TE の購入 --発注から到着まで 1ヶ月かかった--

最近アマチュア無線局を開局したが, 当初無線機を作成するという目的であったが, 自作無線機でいきなりの開局は大変だと思うので, 先の投稿の通り市販の無線機で開局した. ぼちぼちと自作無線機, 特に送信側の骨格が出来つつあり, 出力の電波の質を気にしないといけないくらいに来た. そこでスペアナの購入を考えた. 色々 web site を漁ってみると, RIGOL もスペアナを出しており, しかも低価格である. とりあえず検討した spec は 3.2GHz, tracking generator 付きだ.
RIGOL では DSA832-TE があり日本では 70 万円ほどで, 海外 site  約 $4500 ほどで流石にちょっと高かったので, 廉価版の DSA832E-TG がありそれであれば, 日本円で36万円程度, 海外で $2600 だった. とりあえず廉価版の DSA832E-TG が entry model  として検討するには良いかと考えた.


次はどこで購入するかだが, TEquimpment は site もまともで, 住所から google map で確認しても会社の建物と思われるものも存在していた.


ここで購入をしようと考えたが, 本体価格などは site に書いているし, 付加価値税的なものは米国外での購入の場合は, 納税の必要はない事はない事は分っているが, 送料がどうなるか分らない. 送料無料的な文字があるが流石に米国内だけと思うので, 早速 mail をして聞いてみると FedEx/UPS で $300 程かかる. 本体 $2600 とで約 $2900 程になる. ちょっと高いなと思いつつ, ないと無線機の製作も先に進まない, また TEquipment が見積書を作成し, 該当 site への登録も行なわれ外堀はちょっとずつ埋まってきた. なにはともあれ送料 $300 は高いと思いつつ購入を決めた, 次は支払いをどうするかの検討が必要であった.


クレジットカードでの支払いも良いが, 約 2% の手数料が発生する. 現状, 日本国内, 米国内にドルがあり, そのまま支払いができないかと考えた. 日本では, wire transfer すなわち送金をする場合 最安で 2000 円程度かかる, 海外では $30 ほどかかる. また海外口座の場合は ACH が使えそうだったがまだ使用した事がないので登録に時間がかかりそうだった. よくよく調べてみると外貨がそのまま使える debit card が使えそうだった. 各行 debit card を発行しているが, Sony bank と 住信Sbi bank  の口座は開設済で, debit card の利用登録も簡単そうだった. どちらにするか悩んだが, どちらも使用手数料の返金があるが, sony bank は現金, 住信は point で返金になるので, sony bank の Wallet の登録をする事にした.


支払い方法も確定した事だし, 発注をする事にした. 発注時に, 送料の選択が可能で FedEx/UPS だけでなく USPS なども可能で "Priority Mail Express International" であれば同じくらいの delibery 時間で $200 程度であれば, こちらを選ばないはずがない. 締めて $2800 で発注を行なった.


あとは, 到着を待つだけだ.


待つだけで来るはずなのだが, なかなか来ない, delibery history を確認しとうと思うが, tracking number がない. そんなはずはないと, 発注結果の mail を見ると,  USPS の tracking number があった. 早速 USPS の site で tracking number を入れてみるとちゃんと履歴が出るではないか...


見ると, 結構長旅をしている様に見えた


4/6   発送
4/10 PORTLAND出発
4/11 SFO 到着
4/12 SFO 出発
4/13 PU DONG (china) 到着


確認は 17 日に行なったので, 結構浦東に止っているなぁ, 流石 cost down の為に china air とか使って, 安くしているんだなぁ, 安さの為には浦東から日本に送るのに空を待っているんだと思っていても全く動きがない. 流石におかしいと思い, 日本郵便, TEquipment に mail した, USPS は米国内の customer  support があるが international のものはなく, 問合せ form に米国内の住所が必要で, とりあえず TEquipment の住所を入れても ng だった. 日本郵便は発送伝票をもって窓口に来てくれのそうすれば捜索手続をするとの事 (そんなものがあったのかと初めて知った) ただし, US の発送なので, 私が作成していないので伝票はない. TEquipment に聞いてもないとの事... なにはともあれ, "TEquipment に PU DONG で止ってそうなので, USPS に言って頂戴" と mail したが, 次の日の朝 delivery history の update があり, なっなっなんと SFO に戻っていた. 結局 SFO にもどるんかい! と思ってしまった.


4/19 TEquipment に mail
4/19 SFO に到着
4/21 日本の税関に到着


TEquipment から, "分った, 調べてやる" の mail が来たが, 日本の税関に届いたと mail, "よかった" と mail が来たが, まだ到着していないので, あまり良かった感がない. とは言え, TEquipment に文句を言ってもしょうがない. 文句は空港の荷さばき職人に言いたい...


そこからまだ長い...


後日日本郵便から通関の代理手続きの委任状が来た. 自分でやってみても面白いと思うが, 税関外郵出張所に自分で通関手続をするのだが, 場所的にちょっと行きにくい, まぁ ちょっと前から日本郵便が手数料として 6600 円が必要という事だがそれを受ける事にした. 結局 6600 円が必要なのであれば, FedEx/UPS にすれば良いかと思てしまった. 委任状を 23 日に発送したが, やはりここでも長い時間かかる.


5/1   日本郵便 国際郵便局に Tel, mail にて個人使用証明書を送ってもらい返送
           (浦東に止ってすごく delay したと泣き事も言いつつ)
5/3   不在通知が届いていた (税付国際郵便 税金：13,300円, 通関料: 200円)
5/4   受取

電話から数日で発送され, もっと早く電話すればよかったとちょっと後悔. 正味 1ヶ月かかって受けとりました. とにかく時間がかかりました...
長旅なので, 動作するか気になりますので, 電源を入れ TG と input を接続し, 波形を見ましたが, 問題は無さそうです. といっても直結しただけなので, ほぼとっと下落しているくらいで, もちろん正規化すると完全直線になり, 動作 checkとしてはあまり意味があるかよくわかりません.


掛った金額
DSA832E-TG:    278,665円  ($2,599.00 USDJPY: 107.22円 @20180405 MUFG TTM)
送料:                       21,291円  ($198.58, USPS Pri Mail Exp $100の保険付き)
関税:                                 0円  (税率 0%)
消費税:                     10521円 (税率: 本体価格の 60% の 6.3% )
地方消費税:              2,833円  (税率: 消費税額の 17/63 )
通関料:                         200円
通関代行手数料:      6,600円  0円 (課税対象額が 20万円越えなかった為)

合計:                     320,056円  313,456円
(関税, 消費税, 地方消費税は 100円単位切り捨てっぽく 13,300円になっている. 合計の計算は 13,300円によるもの)

うーん, 日本で購入の場合で 36 万円から計算上 4万円安いが, 紛失, 破損の risk を考えると, 本当に安いといえるのか難しいとろ.  また, 実際は手持ちのドルの平均 rate が 109 円程度なので, もうちょっと高くなる (為替差損状態). 今年の確定申告時にはなにか為替差益があるものと相殺したいところだ.

次回海外で 20万円以上の購入がある場合, FedEx/UPS を検討したいと思う. 日本郵便の 6,600円の通関代行手数料を知らなかったので, $100 けちったけど, 保険もそれなりにあるらしく FedEx/UPS に $300 払っても良いかと思える値差かと思える. ただ別途通関手数料はかかりますが, それほど高くない感じです (siteをちょっと見ただけなので, 書けるだけの知識と調べる気力がありません).

追記 -- 201805080 --
日本郵便に支払うはずの通関代行手数料は, 課税対象額 (本体価額の 60%) が 20万円越えなかった為, いらないとの事. 必要であれば, 消費税, 通関料含めてその旨を郵送するとの事を電話で確認できました. 本体価額が日本円換算で約34万円を越えれば, 6600円かかるので FedEx/UPSにするかの葛藤が有効ですが, 33万下回れば, USPSの方が純粋に $100 けちれます.

STM32CubeMX で出力される code の start addressを 0x4000 に変更する方法

ArmBootloader でその後起動する firmware の start address は MCU の reset vector に配置するのではなく、ArmBootloader で管理する firmware 領域の top に配置する必要がある.
今回 STM32F767 (実際は STM32H743 を使用したいが, NUCLEO 未到着) と STM32CubeMX が生成する code で, 単に board 上の LED を点滅される (GPIO を high / low させるだけ) code で FreeRTOS を追加すると FreeRTOS 部分で処理が止ってしまう現象があり 0x40000 に移動させるのに苦労してしまったので, 記録しておく.

環境
arm-none-eabi-gcc:   (15:5.4.1+svn241155-1) 5.4.1 20160919
STM32CubeMX:  4.25.0 (STM32F7: 1.11.0)

ちなみに STM32F767 の Flash ROM の Sector の都合により firmware の top address を 0x4000 でなく, 0x40000 となっています (ゼロの数に注意).


最終的な変更部は以下の通り,
### 1.   $(project_top)/STM32F767ZITx_FLASH.ld  内 FLASH 領域の変更
FLASH (rx)      : ORIGIN = 0x8040000, LENGTH = 0x1c000      /* address, size に変更 */

### 2.   $(project_top)/Src/system_stm32f7xx.c の VTOR の変更
  extern uint32_t       g_pfnVectors;      /* defined in startup_stm32f767xx.s */
  SCB->VTOR = &g_pfnVectors;


以上であるが, うまくいかなっかった点は, 2 番目の g_pfnVectors の扱いで, .s 内の assembler の label を C から参照するのに, label = pointer = address の場所という感覚であるので
     extern uint32_t       *g_pfnVectors;
     SCB->VTOR = g_pfnVectors;
したが, これでは ng で, assembler の label は, C はなんらかの value その物という解釈らしいので, uint32_t * でなく, uint32_t と extern し, VTOR の vector top register に格納する時に & するのが良いみたいだ.




STMCubeMX が出力する Makefile の SOURCES にいくつかの source が 2 重に定義されており linker で error になる. 手で削除が必要.
また, それなりに動作する sample code が得られると思ったが, 単に compile が成功する code が得られるだけで, たとえば usb audio でとりあえず stream が STM に流れるものが入手できるわけではなく, 色々 code の追加が必要そう. Kinetis はそれなりに動く code が入手できるのだが, ST はあまりそう気はないのだろうか.   RCC の HSE の周波数設定が間違っていただけでした...

20年ぶりの開局むけて

ちょっと前に 1 マアの資格を取った. モールスの実技がなくなり, 英文の筆記はあるが和文が完全になるなり, これならいけるだろうと言う事で受けた. 試験内容的には, 電卓がいらない試験の為計算問題といっても開平するといっても結果整数になる様なものしかない試験なので, それほど難しいわけでもない. とは言え国家資格試験で値段的に 1 万円に近い試験料なので, 2 回も受けるのはもったいないということで, 通勤時間だけだがそれなりには勉強した.

ところで最近のアマチュア無線ってどうなっているのかと色々な site を見ていると,  JT65 や FT8などという digital 通信がはやっているみただ. ただ, 通信 rate は破格の数 baud とかという遅さ. しかし正に地球の裏側まで行く様な通信方式になっている. なんか面白そうだと思ってしまって, ちょっと試してみたいと思ってしまった. そこでふらふら数も少なくなった無線機屋に行きどんな無線機があるのか見に行き, 話を聞いてみた.
驚いたのが最上位機種は大きな LCD があり, まさに測定器といった風貌で約 20 年前に覚えのある表示器は周波数その他数字だけを出せるものとはちょっと違っていた.
 対応してもらった方は多分 Yassu の研修生といっても見た目の年齢的に課長研修あたりではないかと思う感じで, 全般的に Yaesu 製品の説明を受けた感じになった. もともと購入するのであれば 10 万円程度のものが適当と考えていて FT-991A と IC7300 とが候補にあがっていた.

IC7300 は大型 LCD で見ためも良く, 受信側は direct SDR という事で digital 派の私的にはこちらかなと思ったが, 説明を受けていると FT-991A はそれなりの RF 回路があり近接妨害を受けにくいという謳い文句でこちらになかり傾いた. ただ, FT-991A の使用 report 的にはあまり操作が直感的でなく使いにくいというのを見た. しかし, すでに魅力的に cost 的に QSL card の交換とかしたいと思わないので, 音声は出たいと思わない. CW は出てみたい気はするがこちらに必要なくても相手から card の発行を期待されるとちょっと重荷になるので, そういうのもありあまり, 細かな操作性はいいと考えた.

あと, 無線機より問題なのが antenna の設置だった. 7 MHz, 14MHz あがりに出られれば良いかと考えているが, tower や八木などは上げられない. Di-pole か GP がいければと考えていると Windom antenna というのがあり, 7MHz の半波長の 20m 長で 7, 14, 28MHz が出られるという事で, この antenna にしようと考えた. 給電点は 1/6 と 2/6波長に相当する部分にありしかし, この様な antenna は通常店舗販売はされておらず, 通販か自作になる. 通販といっても balun の作成が面倒かどうかで, element の調整はどっちみちしないといけないので、自作する事にした. この antenna の入力 impedance は 272[Ohm] で同軸の 50[Ohm] はと balun が必要になる. 理想的には 1:6 だと思うが, 外界の影響で impedance が下る傾向にあるとの事, また, 1:4 balun が作りやすいので, 多くの site では 1:4 としているところが多い. とりあえず core として T106-6 と直径 0.5 mm のポリウレタン線を購入した. もうちょっと太いならびにそれなりの被覆のある線にしておいた方が良かったと後から思ったが, 何度か作り直しが必要だと思われるので, まずはこれでやってみようと思う.

結構 FT-991A に bias が掛った定性的 pros/cons になっているが、なにはともあれ FT-991A + Windom antenna の構成でいき, 無線機も購入してしまった.

あと面倒というか時間が掛るのが開局申請になる. 最近は電子申請ができるという事なので, とりあえず account 申請し, 郵送で user account と password が送られくる. この郵送の一回は無駄な気がするが, cost意識が薄いのと国民からいらぬ攻撃をなるべくかわす為と無理矢理理解した. ただ 2日程度で来たので, アマチュア無線の低迷も含め電波使用申請する人なんかそれほどいないんだとうと思う. 各種業務, 携帯電話会社, 放送局がそんなにバンバンできていないし, あっても楽天が携帯電話の申請をしたくらいで, そもそもこんな system を使うのではなく別 path があると思う (電波利用申請 lite の lite といっているくらいだし)
なにはともあれ, 紙で提出しなくて良くなったのはかなり楽になる.

FT8 などの digital 通信を考えていたので, 開局時に, FT-991A で通常 (音声, CW) 運用できる周波数帯ならびに電波形式, かつ付加装置で申請を考えたが無線機屋の店員が, 通常申請してから, 変更届けを出した方が保証認定から外れなく楽だという事でその手順にする事にした. すでに digital 通信方式を申請している局が新たな digital 通信方式の追加は無料でかつ申請だけで良いという旨を書いている site は多いが, 開局を含めてどの様にしたら良いかは見付けられなかったので一度に行なった方が良いかと思い, 店員に聞いてみると, 保証認定範囲の開局してから, 変更した方が楽だと言う事だった. ただ, 初めて digital 通信方式を追加する時に保証認定から外れると思うが、 最初から digital 通信方式を追加するとしないとで flow の違いが生じるというのがちょっと理解できなかったが, 時間的な観点で言うと, 兎に角電波形式はどうであれ開局するまでに時間が短かいのは, 保証認定内で申請して開局してしまう方法だというのは理解できた.
すぐ申請 site に access しようと思うが今日 (2018/03/10) 8時までは昨日夜からの maintenance で close になっている

arm gcc で compile した後 ld で -nostdlib 指定時の undefined references の解決

ARM cpu 系の soft 開発において gcc で compile した場合,  GPL の関係で -nostdlib を指定して標準 library を link しない様にした時に mul や div 系が undefine でエラーになる。その時は以下を compile し link すれば良い

https://github.com/bobbl/libaeabi-cortexm0

今回 ArmBootloader の kinetis 系の bootloader は NXP (旧 Freescale) のものをそのまま利用をする事にした. (以前は binary size を小くする事を考え独自作成を考えたが、互換性など担保するのが大変なのと、すでに存在する物を新たに作成するのはもったいないので変更).  その中で掛け算、割り算が使われている為に起こる. 以前は独自実装の ldiv などを使用していたが折角なので使用させていただくことに. License は何か主流なのを持ってきた物ではないが MIT license に近いのではないかと思われる. とりあえず notice 系をちゃんと残しておけば良く, その他の file への license 感染はない.


また、gcc の optimize option に -Os があるが、これを指定すると
"undefined references to `__gnu_thumb1_case_uqi' " が出る、if -- else if --  方から関数 pointer の配列型にするっぽいが、此れに対しては

https://chromium.googlesource.com/chromiumos/platform/ec/+/v1.9.0/core/cortex-m0

を使用させていただく事にした.  file 中に License 事項が書いてあるが BSD style だと言う事だ.

他にも色々あると思われるが, ググって最初の方に出てきたので, そのまま使用する

Arm 系の bootloader の開発 (ArmBootloader)

マイコンを使用する際、開発した program をどの様に update するかは問題です.
通常 JTAG や SWD などで udpate する場合が多いですが、製品化する場合それらをいつもでも使う事ができるわけではありません.そこで、bootloader を作成し、マイコンの power on reset で bootloader を実行する様にし, 開発した firmware が存在する場合 firmware を実行し、無いもしくは壊れている、または update mode の場合は bootloader に留まり外部からの firmware update 処理を行なえる様にする. もちろん bootloader 自分自身も update が行なえる方が良い.

以前は、チップ購入もしくは実装状態では、blank 状態が多く、書き込み納入してもらうか上記の様に JTAG や SWD などで書き込まなければならず firmware update の機構とは別の方法で update する必要があり煩雑であった. しかし最近はマイコンでチップ内 mask rom に bootloader の入った物が多くなってきた. この bootloader はなんらかの update protocol を持っており、この protocol をそのまま今回作成する bootloader に使用する事で、update 方法の違いによる煩雑さをなくす事ができる.

今回作成する bootloader の仕様は以下の通り

1.  ARM 系の chip を対象
2.  STM, Kinetis, LPC の update を基本とする
3.  update protocol は、mask rom の update protocol と同じにする
         (mask rom bootloader が無い場合は同種チップの update protocol を使用する)
4.  update する側の PC もしくは ホスト cpu の program は単一 program にする
         (上記 2で示すマイコンの protocol をすべて対応する)
5.  伝送路は UART を基本とし、USB, I2C, SPI は必要になった時に適宜サポートする
6.  bootloader その他用途の size は最大32kB とする (0x00007fff まで)
         以下の map が考えられる
         6-1  2kB: 1st bootloader, 28kB: 2nd bootloader, 2kB: configuration data
         6-2  2kB: 1st bootloader, 14kB x 2: 2nd bootloader, 2kB: configuration data
         6-3  2kB: 1st bootloader, 30kB: 2nd bootloader
         まずは 6-1 を想定する
7.  firmwre は 0x00008000 から配置
         firmware は、0x00000000 からではなく 0x00008000 から配置
8.  対象 compiler:  GCC, IAR (KEIL は未定)
         GCC は、gcc 標準の library は使用しない様にする
9.   ライセンスは MIT license


2018/06/28追記
STM系で USB CDC による UART update 方法を追加
USBでの update は, DFU であるが、細かな書き込み制御ができなさそうなのと DFU の実装が面倒だったので USB CDC の stream を UART update の処理部に突っこんだだけ