ねむいさんのぶろぐ

FM3が富士通からスパンションになりましたよ記念

20161123追：
富士通のFM3を喰ったSPANSIONはCypressに喰われました。

富士通のFM3マイコンに関する記事はもう更新しないでクローズにしようと思っていましたが、
国産マイコンだったFM3シリーズが大人の事情でSPANSIONというメモリ中心のチップベンダに
移譲されたので記念に小ネタを更新します。

前回まではFM3マイコンにFatFsやTFT-LCDドライバなりを積だのを紹介してましたが
今回はOpenOCDのFM3フラッシュ書き込みドライバの改良についてです。

いつも参考にさせてもらっているjujurouさんによると小規模のRAM物理量が少ない品種で
書き込みが出来ないとのことで、Kinetis-LシリーズやNuvotonのフラッシュ書き込み
ドライバを実装して実力をつけた私も調査してみました。

上の二つの図はFM3マイコンに収納されたフラッシュ書き込みのバイトコード(書き
込みアルゴリズム)と書き込むべきデータを簡略化した物の修正前と後の比較です。

フラッシュ書き込みはJTAG/SWDから内蔵SRAMに流し込んでおいたバイトコードをOpenOCD
側の"run_algorithm"にて実行させることにより行われていますが、その中でSRAM上にある
"u32DummyRead"と"u32FlashResult"の値を参照しています。この二つの変数は、アルゴ
リズムを確保したメモリの先頭に置かれるため、アルゴリズム開始アドレスは、本来は
基底アドレス(BaseAddress)から+8ずれることになります。

おそらく最初にドライバを作った時のデバイスがMB9BF506NだけだったようでSRAMの基底と
なるアドレスが0x1FFF8000に固定化されていました。しかしFM3シリーズの内蔵SRAMの
構造は、0x20000000をベースとして上下に伸びていく仕組みなので安全牌で動かすためには
本来なら基底を0x20000000にしなければなりません。現状ではSRAM量が物理的に少ない
品種ではOpenOCDのcfgファイル内でSRAM量とSRAM開始アドレスを"正しく"指定すると、
jujurouさんの指摘通りSRAMが存在しないアドレスを参照することになり、書き込みが必ず
コケる羽目になってしまいます。

というわけで私も私なりに修正してなおかつ書き込みパフォーマンスを上げる修正を盛り
込んでパッチを作成しました。先ず以前使っていたMB9BF618Tで当然のように書き込みを
確認しました。さらに今回の問題が修正されてるのを確認するためにebayで小規模のFM3
マイコンMB9AF112K(Flash:128kB/SRAM:16kB)を仕入れて動作確認を行いました。
↓やっけつ基板

ログはこんな感じです。ばっちり書き込み出来てますね♥
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/vsllink_swd.cfg -f target/mb9af112k_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.8.0-dev-00117-gf7fed92-dirty (2013-08-12-20:01)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : OpenOCD runs in SWD mode
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
trst_only separate trst_push_pull
adapter speed: 500 kHz
cortex_m reset_config sysresetreq
verify Capture-IR is disabled
Info : Versaloon(0x15)by Simon(compiled on May 22 2013)
Info : USB_TO_XXX abilities: 0x0000076E:0x010001EF:0xC0000007
Info : clock speed 500 kHz
Info : Found SWD-DP id:0x2BA01477
Info : mb9bfxx2.cpu: hardware has 6 breakpoints, 4 watchpoints
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x00000114 msp: 0x20002000
auto erase enabled
Info : Fujitsu MB9[A/B]FXXX: Sector Erase ... (0 to 2)
Info : Fujitsu MB9[A/B]FXXX: FLASH Write ...
wrote 131072 bytes from file main.elf in 4.344639s (29.462 KiB/s)
verified 33456 bytes in 0.109398s (298.651 KiB/s)
shutdown command invoked

> Process Exit Code: 0
> Time Taken: 00:05

さて、上記FM3の修正のほかにkinetisドライバとNuvotonドライバのブラッシュアップも
行い、8月11日時点のOpenOCDのコミットに適用したパッチ群も更新しました。
もちろんOpenOCDのバイナリも修正していますので奇しくも時を同じくして一般販売と
なった｢FM3-USBSTICK｣を購入された方は試してみてください(私はMB9AF112Kで試し
ましたがメモリ構造が同様のMB9AF312Kでもまったく同様に使用できます)。

･･･
本来はこの程度の小ネタはブログトップのサブタイ欄にちょっと書いて終わるはずな
のですがVersaloonのBBSにKinetis-LドライバやNuvotonドライバのパッチを紹介した
ことでntfreakﾘﾝｻﾝの目に留まり、OpenOCDのgerritにFM3の修正を含めたいくつかの
パッチを叩き上げられることにめでたく相成りました。しかし、そのFM3ドライバのパッチ
はまだバグが修正仕切れてなかった欠陥版だったのがつい最近判明したので、
汚名返上のために私自身もOpenOCDのコードレビューシステムに電撃参戦する意を
決めました！！

とはいえパッチを提供するまでに覚える事柄が非常に多く英語による意思の疎通も
非常に重要になります。なんにせよひとつずつ目的達成までの課題をあせらずクリア
していくほかありませんが汚名挽回をしてしまわないように気をつけます･･･。

FM3マイコンを使ってみる4 -もう、誰も...-

もう触る気力がゼロになってしまったのでいつも見に来てくださってるFujitsuの方々
には真に申し訳ないのですがここで打ち切っていつものの公開をさせていただきます。

●勝てなかったよ…
当初実装予定だった以下のコードは私の力不足もあって盛り込めませんでした。
・外部SRAMアクセス
　->基板に半田付けまではしたけど配線めどい。
・松浦氏のmp3プレーヤー(libmad)の移植
　->STM32F4でhelixの方を移植しリベンジ完了。

●いつもの
私のぶろぐにおいていつものとはChaN氏謹製FatFsの移植例を指します。もちろん単に
移植しただけではなくTFT-LCDと組み合わせた(同じくChaN氏の)ファイラにより視覚的
に操作が可能になっています。どのMPUにかかわらずいつものは基本的に下記の機能を
網羅するようにしており他の用途にも簡単に応用できる仕組みとなっています。

・FatFs
・UART(TFT-LCDドライバ/FatFsテストルーチンの動作に必ず必要)
・TFT-LCDドライバ
・SPI転送(TFT-LCDドライバに使う)
・外部バス(TFT-LCDドライバ・SRAMに使う)
・タッチパネル入力(TFT-LCDドライバに使う・BlueScreenのものを汎用化して移植)
・タッチパネル入力用のデータ保持(FRK-FM3ではFRAMを使用)
・DMA転送(TFT-LCDドライバに使う)
・FONTX2ドライバ

●動かすためのハードウエアの準備

FRK-FM3にのっかっているレギュレータはデフォルトではLDO側の出力が使用されています。
これを600mA引き出せるDCDCコンバータ側に切り替えました。基板単体で通電した時の立
ちあがりとたち下がりの波形は以下の通り。

まぁ特に問題もないですね。(あったら困りますけど…)

基板から外の配線は、GNDとVCCの配線がものすごく簡単になるアイテムラボさんのパワ
ーメッシュユニバーサル基板を使用しました。

裏にはebayで大量に購入したmicroSDカードスロットを設けました。安価で引き回しもや
りやすいです♥

アナログ出力はローパスフィルタを通じて単電源オペアンプで構成されたボルテージ・
フォロワ経由で行います。3.5φのジャックをつけるコネクタの上に見えるヘッダピンは
ボリ松基板(LPC2388用)をつけるためのものです。

TFT-LCDモジュールはパラレル/シリアル用のポートを引き出してます。中央のICはくっ
つけただけで配線で挫折した1MBのSRAM...

いつものを動かしてみたところです。もはやここまでは基本の"き"ですね～。

8bit-i8080と8bitSPIのRGBデータのブロック転送はDMAに対応しています。ところで
外部バスを使用した場合のDMAはメモリ間転送扱いなのでまだ簡単なのですがMFSを用
いたSPIでDMAする場合の具体的な手順がいまいちわからず難儀しました。資料を探し
てFM3の英文の方のサイトの別品種のサンプル例にUARTでの転送手順があったのでこ
れをもとにDMA転送ルーチンを作りました。転送に関しては以下の要素が必要です。

・MFSのDMAはハードウエアのデマンド転送とする
・MFSの送信/受信割り込みをDMA要求として使用する
・DMACBxレジスタのEBビットは立てるのを忘れずに
・送信/受信割り込み許可ビット立てて転送開始

ぇっと詳しい手順はソースを見てください(丸投げ!)
XMEGAのMSPIでDMA転送できるようになった経験が生きました。

ちなみに速度は遅いですがソフトウエアSPIも出来るようにしてます。尤もFM3の場合
は9bitSPIが可能なので出番は無いと思います。

今回は表示系もちょっとだけパワーアップしてます。ロングファイルネーム(LFN)も表示
が出来るようになってます♥

これはWAVEファイルを再生してる画面ですがLFNの日本語ファイル名にももちろん対応
です。ちなみに私もf_stat()で取得したFILEINFO構造体のデータがLFNだけ拾ってこ
られない罠にはまった一人ですorzSFNからLFNを引っ張ってくる関数を一つ設けて実
現しています。

というわけでFM3にかなり寄り道してしまいましたがこの経験をSTM32F4に反映していこう
と思います。せっかく超格安全部載せ基板買ってしまってもったいないですし！

FM3マイコンを使ってみる3 -FatFsとTFT液晶表示の実装-

今月(2012年7月号)のInterface誌は予想に反して私のようなホビイストにはとてもあり
がたい内容となっておりました。ねむいさんは正直Windowsネイティブな環境でもGCCで
ビルドやデバッグできるのになぜか面倒なcygwinを使わせた上糞の役にも立たないLED
点滅で終わらせて実用的な作例はIARとかKEILのIDEのみで行って｢んんんｎ～～！！！
GCCは面倒ですぞ～！CQ出版がお勧めするIARやKEILを使ってくだされ～！１！｣って
販促するパタンで畳み掛けると思ったのですがどうせなら開き直ってDS-5とか推せよとか
いつも思っていたのですが今回は全然そういう事は全くなく、オープンソースなソフト
ウェア(OSS)(and フリーソフト)をフルに活用した記事が満載でした。
もちろんOSSにもメリットデメリットがあって邑中雅樹氏の講演のスライド13p目にそれ
が集約されていると思います。タダより高くつくものはないです。
しかしながら趣味でやる場合は互いに情報を出し惜しみすることなく情報をやり取りする
ことによって敷居を低くできるので横のつながりを大切にしていきましょうね。

私も"ねむいさんのページ見てもわかりづらくてOpenOCD動かせられなかったけど他の
人のページに書いてあるやり方だったら一発で出来た"と言われないような記事作りを
心がけて行きます(←まだ根に持ってる)

…さて戯言はこの辺にしといてFM3マイコンはFatFsとシリアル&i8080バス接続タイプの
TFT-LCDドライバを使ったいつものの実装を目標としています。FM3のデータシートや
アプリケーションノートは情報散らばりすぎでいまいち組み方がわかりづらかったのですが、
上記IF誌に収録されていた作例にわかり易いサンプル例が多数収録されておりそれを
最大限に活用させていただきました。

●UARTとFatFs
UARTは前回行ったのと同じですが、前回jujurou氏よりコメントいただいた通りSRAMの
割りあてはSTM32F4の時のように目くじら立てるほどのことではないことが判明し、ふつー
に128kByteの内蔵SRAMとして使うことにしました。私が試した限りではすべてのSRAM
領域でDMA可能でなおかつコード実行も可能でした。

というわけでChaN氏の作例にならってMFSを使ったMMC用のドライバも作り、危なげなく
FatFsも動作確認しました。ちなみにChaN氏はDMAを使用せずFIFOを使用していますがSCK
を18MHzにしたリード速度は下画像のようになりました。

STM32F107(DMA転送)の時とほぼ同じですね～。SPIモードの場合の理論上の転送スピードは
18MHzの時約2.2MByte/Secになりますから無理してDMA化する必要がなかったようですね。
尤もFM3においては内部の遅延により+3.3V駆動の際に保証されるSCLKの最高速度は7.2MHz
にしかならないそうです。STM32F4とかはSPIでも42MHzまで叩き出せるのにs**kです。

●シリアル接続タイプのTFT-LCD
扱いも容易でaitendoさんで手軽に購入できるようになったシリアル接続タイプのTFTLCD
も、FatFsの時と同じくMFSを利用してHALを作りました。もちろんGPIOによるソフトウェアSPI
にも対応していますが…FM3のGPIOはAPBバスにぶら下がっていてなおかつ1HCLK分ウエ
イトが掛かっているようでGPIOの出力レジスタに8bitのデータ投げるような単純にstr命令
だけが連続するような操作でもMAX12MHz、ビットバンド領域の単純なビット操作はその半分
のMAX6MHzしか出ないことが判明しあまりお勧めできません。

↑0xFFと0x00を交互にPDORFxに全速力でﾌﾞﾝ投げた時のI/Oトグル波形…
　STM32F1(18MHz)以下ですかorz

↑ビットバンドなアクセスの場合はCortexの仕様上最短2クロックサイクルかかるので
　さらにその半分orz
　TFT-LCDのRES線制御等の1ビット分だけの制御の場合はリードモディファイライトが
　行われないビットバンド領域のアクセスの方が早いです。ちなみにFM3にはSTやNxP系
　ARMマイコンにあるGPIO出力ポートのビットセット/リセットレジスタなぞありませんorz

また、上のFatFsの話の時は7.2MHzしかSPIの速度が出せないと述べていますがリードの
ことは考えずただLCDにシリアル信号をﾌﾞﾝ投げるだけなら18MHzでも全く問題ないので
どしどし使いましょう。とくにFM3では9bitシリアルもハードウエアで設定可能であり、
9bitシリアルにしかI/Fが対応していないTFT-LCDモジュールなどでは速度面で重宝します。

↑ということで9bitシリアルにしか対応してないHX8340B(N)なTFT-LCDモジュールを
　ハードウエア9bitSPIで動かしてみました。表示が早くなって感激です！
　これでNokia6070その他9bitシリアルな液晶さんたちが救われます！ちなみに…、

　いないさんの大事な部分が見切れていますがこれはPNG表示ルーチンの仕様です。

●外部バスとi8080バス接続タイプのTFT-LCD
今回のFM3基板に乗っかっているチップはA24までExternalBusInterfaceとしてアドレス
が出せられます。とはいえLCDを駆動するだけならアドレス線は一本だけで十分ですが…

こちらに関しては7月号の付録に収録されている松浦氏のMP3プレーヤーのLCD/SRAMアク
セス初期化部をかなり参考にさせていただき、さらにSTM32/LPC2388のように柔軟性を
上げて作り込みました。今回の松浦氏の紹介にあるMP3プレーヤーの基板の回路に互換
性をもたせてありますので他の方も再現できると思います(タッチパネル制御はADCを使
用せず、ADS7843に任せていますので非互換です)

↑この写真ではすでにタッチパネル制御も入れてます。

●タッチパネル制御
タッチパネルによる座標情報はタッチパネルコントローラICであるADS7843を使用して得て
います。AD7843はSPI通信の信号はかなり遅めにする必要があるので簡素なGPIOによる
ソフトSPIでも十分間に合います。

さて、タッチパネルはキャリブレーションが必須ですが、キャリブレーションした後のデータ
はこのFM3基板上実装されたFRAM(MB85RC16)にストアすることにしました。こちらに関
してもChaN氏がFRAM向けのI2Cドライバとして実装されていたのでこちらを活用し、ストア
・リストアするルーチンを作り込みました。使用していて気付きましたが、やはりFRAMであっ
てもWRITEを行った後は少しウェイトを挿入しないと次のWRITE操作に影響が出ることが
分かり、なるべく一つのデータにまとめて一つのWRITE操作で書き込むようにしています。

…ということでChaN氏のFatFsとファイラを実装して動かすという当初の目的が達成された
わけですが、PWM出力と外部SRAM、あと外部SRAMとのDMA転送も試してみたいので
もう少しコードは練った上での公開とさせていただきます。今の状態でも構わないから
コードを見たいという方はご連絡下さい。
STM32F0とXMEGAのFatFsのDMA化とTIのStellarisと東海自然歩道のネタが次に控えて
いて書くことがたくさんあり過ぎますがもう少しだけFM3です。

おまけ：FM3マイコンの性能やデバッグ効率を上げる小ネタです。

●FM3のパフォーマンスをアップする
HCLKが72MHz以上の時、FM3はプリフェッチバッファが有効になるそうですが(元から有効化
されてるみたいですが)この時さらに先読みした命令をストアできるトレースバッファを有効化
することもできます。FUJITSU提供のテンプレートでは有効化するルーチンは無いので
自分で挿入する必要があります。消費電流は100mAオーバー(HCLK=144MHz時)で結構
発熱しますがそれを厭わない方はｶﾞｼｶﾞｼ使って行きましょう。

●OpenOCD経由のフラッシュ書き込み速度を増加してデバッグ効率のアップ
現在のOpenOCDのFM3のフラッシュ書き込みルーチンは、I/Dコードバスにぶら下がっ
た内蔵SRAM領域にフラッシュ書き込み操作とフラッシュに書き込むデータをJTAG/SWD
で転送・実行していますが、ワークメモリの容量はハードコーディングされています。
128kByteもあるMB9BF618Tではもっと大容量のメモリを確保可能なのでこの部分をデバ
イスID別に可変にするようにしました(MB9BF618Tの場合は32768Byteにしました)。

ワークエリア増やしてもあんまし変らんだろと思っていましたがなんと驚くべき結果が！！
> "C:¥Devz¥AVR¥WinAVR¥utils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/jtagkey2.cfg -f target/mb9bf618t_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.6.0-dev-00595-g445a54a-dirty (2012-05-26-12:03)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
trst_only separate trst_push_pull
500 kHz
cortex_m3 reset_config sysresetreq
verify Capture-IR is disabled
Info : device: 6 "2232H"
Info : deviceID: 67358712
Info : SerialNumber: 22222222A
Info : Description: Amontec JTAGkey-2 A
Info : max TCK change to: 30000 kHz
Info : clock speed 500 kHz
Info : JTAG tap: mb9bfxx8.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : mb9bfxx8.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : JTAG tap: mb9bfxx8.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x00000114 msp: 0x20010000
Rize up to Internal PLLed Clock!
15000 kHz
auto erase enabled
Info : Fujitsu MB9Bxxx: Sector Erase ... (0 to 9)
Info : Fujitsu MB9B500: FLASH Write ...
wrote 1048576 bytes from file main.elf in 18.625118s (54.980 KiB/s)
verified 941740 bytes in 0.828131s (1110.534 KiB/s)
Info : JTAG tap: mb9bfxx8.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
shutdown command invoked

> Process Exit Code: 0
> Time Taken: 00:21

なんと
wrote 1048576 bytes from file main.elf in 18.625118s (54.980 KiB/s)
となって、前々回と比べると5倍以上高速化出来るようになりました！
なんというか新生青銅聖衣を装着して敵の本拠地にカチ込まんとする星矢さんのよう
な"よぉしこれで全力で戦える！！！"な気分です。

一通り検証も終わったのでOpenOCDビルド時のFM3向けパッチとしてすでに公開しています。
今回のパッチはiruka氏とjujurou氏の物を合わせたのをベースにしています。
また、OpenOCDのFM3向けコンフィグファイルと組み合わせないと性能が出ないので
上のOpenOCDのビルド&デバッグ方法をよく読んで試してください。

FM3マイコンを使ってみる2

一応ねむいさん的にはChaN氏のFatFsといつものTFT-LCDドライバの実装までを目標と
しています。今回はその中継ぎとしてSTM32F4の時に行ったメモリ構成の決定とFM3の
機能であるMFSを使ったUARTを使った標準関数のリダイレクト、そしてOpenOCDを使っ
たデバッグ環境の強化を行いました。

FM3のシリアル通信はMFSというUART,I2C,SPIの機能を柔軟に切り替えて使用可能な
ユニットを通じて行われます。マニュアルやサンプルコードをざっと見た感じでは非常に
めどそうな設定や操作項目が多い感じでした。

●基本の"き"、UART実装
…と言いたいところでしたがIF誌の特設ページを見るとなんとChaN氏自身がFatFsとシ
リアル通信関連のプログラムをFM3移植されていたのでこれを最大限に活用させていた
だき、まずUARTの環境を拵えました。ChaN氏のUARTのルーチンとはバッファ構成が少し
違っていてXMEGAを触った時に覚えたリングバッファ~~をパク~~で構成しました。

また、ChaN氏は周辺機器レジスタ定義をFujitsuが提供するCMSISのもの(mb9b610t.h)
ではなく自己生成のパブリックドメインな物を使用されていました。こちらも私の都合で
一部だけ利用させてもらい他はFujitsu製のレジスタ定義にしています。
1文字送信関数は動作したのでお次はprintf系の標準関数にリダイレクトを行いました。

●メモリ構成の決定と標準関数(newlib)のリダイレクト
もう何度も何度も言及していますが、GCC環境でARMを初めて触った人が引っかかるの
はprintf系の関数がビルドできない動作できないという点です。尤も今回のFM3マイコ
ン基板に限ってはIF誌を１章から馬鹿正直読み進めてその通りにしてしまうとLED点滅
すらできず(なんでそうなるかはよく読めばわかります)、人の話を聞かないねむいさんのよう
なタイプの人のほうがさっさと先に進めるというのは何とも言い難いところですが、これは
｢本やネットに書いてること鵜呑みにして自分の頭で考えないからそんなくだらない所で
嵌るんだよ｣というCQ出版の読者に対する挑戦なのでしょうか?もしそうならカンガルー先輩
を本国から再召還して編集部全員にヤキ入れ直しｔ済みません話逸れ過ぎました
20120522追:
カンガルー先輩がヤキ入れした結果

ぇっとprintfの話でしたっけ、GCCのビルド環境でたとえばSourceryCodeBenchでnewlib
を使うためにはいくつかの未定義の関数をユーザーが定義して紐つける(=リダイレクト)
が必要となります。細かい説明はLPC2388の時と同じです。

前回はLEDの点滅ができる程度で適当に決めていましたがnewlibを使用するにあたって
内蔵SRAMの構成をひとまず下のようにしました。
20120612変更：
内蔵RAM上のどのアドレス領域でもDMAできるのがわかったので分割は止めて、
128kByte分まるまる使う構成に変更しました。

MB9BF618Tの128kByteあるSRAMのうち0x1FFF0000から始まる64kByteはI/Dコードバスに、
0x20000000から始まる64kByte分はシステムバスに接続されているそうです。
まだ未確認ですがDMACがシステムバス経由でしかやり取りできないっぽいのでDMA用
のRAMを確保するために0x20000000から先の64kByte分はまるまるHEAP領域としました。
この構成はFatFsを積んだときにまた変わるかもしれません。
20120530追:
実験を行いましたが、どの領域でもDMAは可能でした。
また、同じくどの領域でもコード実行が可能でした

というわけでUART経由のprintf関数も無事動作。もちろんsprintfやscanf等も使用できます。
UARTに使用されるポートはボリ松拡張基板のUART入出力で使用されるMFS3_2なので、
(FRK-FM3ではCN3の33p&34p)ボリ板でも再現可能です。
ところでmankoiって何ですかって？ぐふふ…

●ioviewを使いOpenOCDからペリフェラルレジスタを参照する
Fujitsuが提供しているレジスタの定義は全てがビットフィールドの定義もなされて
いてフツーにプログラミングする際は便利です(mb9b610t.hのサイズが超でかくなっ
てはいますが)しかし、これをこのままioviewに適用するとunionの数が多すぎるのか
参照した瞬間にinsightやGDBが落ちてしまいました。
やはり地道に一つづつ定義していくしかないのかと思っていた矢先、ChaN氏謹製の
レジスタ定義があるのを思い出しこちらを活用させてもらいました！自動生成されて
いるので一部レジスタの定義が二重になっている箇所がありましたがすぐに気付いて
修正し、mb9bf61x_io_view.cの完成です！

ビット単位の参照が可能なのは現状PDORx系のレジスタのみです。私の動作検証が
進むにつれて主要な物はレジスタのビット参照可能なようにして行きます。

ということで長々とお話ししましたが前回のLED点滅プログラムに+αを加えた物は
すでに更新しています。以前のプログラムを使用してprintfとかしようとした人は
リンカスクリプトがまだ適当だったので多分できなかったと思いますすみません。

また、新井氏(絵描きのaraiさんと名前が被るので混乱を招かないためにこちらの
新井さんは以後漢字記名で統一させていただきます)のSystemCoreClockUpdate()
周りの修正も今回の更新にあたり反映させていただきました。

FM3マイコンはぢめました

20140318追:
かつてOpenOCDのFM3ドライバには様々な致命的なバグが存在しておりましたが
ネムイ・トリノミアスさんという美少女の活躍のおかげでほとんどのバグは解消され、
安定して使用が可能となっております。
私のぶろぐにおいてもFM3ドライバのバグが修正済の最新のOpenOCDバイナリ
を公開しておりますので是非ご利用ください。
20131031注：
OpenOCDのFM3ドライバは致命的バグが放置されております。他の方のHP/ブログ
経由で私の所にうまくいかないできないといった質問が何度も来てるのですが、IF誌
収録のバイナリはまだ修正しきれておりませんのでご注意ください。変なアレンジを
しようとしないでまずは私のやり方をまねてください！

私が公開してるOpenOCDのWindowsバイナリは上記致命的バグをすべて修正して
おります。Linux系OSユーザーの方のためにパッチも公開しておりますのでご参考に。

20120708注：
IF誌についてたQEMUはFM3固有のペリフェラルのエミュレーションなぞわざわざ
やってないので、私のやつをビルドして使ってもQEMUでは一切動きません！S**K!

富士通製Cortex-M3なARMマイコンのFM3シリーズであるMB9BF618T。これが実装された
付録基板が付いているInterface誌6月号の明日の販売を控え、帰宅途中に"たまたま"ふらっと
寄った新大阪の某所で売られていた6月号を購入しさっそく基板を動かして見ました。

…なんかねむいさん変てこりんなこと言ってるような気がしますが多分気のせいです。
あと国産マイコンは絶対に扱いませんといっときながらFM3は使うのかという突っ込
みに対しては中身は英国製ARMコアなのでノーカウントとさせていただきmasu！

…さて戯言はこの辺にして、今年1月ごろにはすでに基板に関する情報が出回っていた
ので先回りしてデータシートやマニュアルを熟読しSystickを使用した簡単なプログラム
を作成、いわば予習はすでに行っていました。
とはいえそれ程仰々しいものでもなく、最早慣れ親しんだCortex-M3だったのでLPC1343
とSTM32F107の物をベースにしたスタートアップコードやデータシート首っ引きでリンカ
スクリプトをこしらえGCCでビルド・デバッグ出来る物をサクッとやっけつました。
正直LPC1788の時の方がむずかしかったです。

そしてビルドして出来たバイナリをMB9BF618Tに書く手段ですが‥‥、これが都合よく少し
前にOpenOCDにFM3マイコンのフラッシュ書き込みルーチンが実装されていました。
なおかつjujurou氏が別型番のFM3マイコンにてOpenOCDからの書き込み・デバッグを
した時の成果をすでに残されていたのでこちらもありがたく使わせてもらい、MB9BF618T
のフラッシュ書き込みにも対応したOpenOCDを作成し、万全の体制で今日を迎え撃ちました。

で、結果ですがOpenOCDからプログラムの書き込み・デバッグに無事に成功しました！

↓書き込み時に出るOpenOCDのメッセージはこんな感じです。
> "C:¥Devz¥AVR¥WinAVR¥utils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/jtagkey2.cfg -f target/mb9bf618t_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.6.0-dev-00527-gf908bae-dirty (2012-04-24-21:47)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
trst_only separate trst_push_pull
500 kHz
cortex_m3 reset_config sysresetreq
verify Capture-IR is disabled
Info : device: 6 "2232H"
Info : deviceID: 67358712
Info : SerialNumber: 22222222A
Info : Description: Amontec JTAGkey-2 A
Info : max TCK change to: 30000 kHz
Info : clock speed 500 kHz
Info : JTAG tap: mb9bfxx8.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : mb9bfxx8.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : JTAG tap: mb9bfxx8.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x00000114 msp: 0x20000000
auto erase enabled
Info : Fujitsu MB9Bxxx: Sector Erase ... (0 to 0)
Info : Fujitsu MB9B500: FLASH Write ...
wrote 16384 bytes from file main.elf in 2.046889s (7.817 KiB/s)
verified 804 bytes in 0.421877s (1.861 KiB/s)
Info : JTAG tap: mb9bfxx8.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
shutdown command invoked

MB9BF618T向けのOpenOCDスクリプトはまだPLLでクロック上げておらずリセット時の
内部発振4MHzで動いてる状態です。今後クロックアップさせる予定なのでもう少し
使い勝手が良くなるでしょうね♥…ぇ？俺も早くOpenOCDビルドして試してみたいですって？
…ふっふっふ、とっくに対応済ですよぅ？

という所で本日試したPORTF3にぶら下がったLEDを点滅するだけのものすごく単純な
FM3基板(FRK-FM3でしたっけ)向けのGCCでビルドできるプログラムはこちらに。
また、↑をビルドするための超分かりやすいビルド方法はこちらになります。
↑をデバッグするための超分かりやすいデバッグ手順はこちらになります。
そうだね宣伝ｄ(ry

今はLED点滅だけですがこれにUART経由の文字列出力等の基本的なのを順次アップ
デートしていきます。私はSTM32F4弄るのがメインなのでFM3にはそこまで興味は
無く、予定は大幅に伸びるでしょうけども6月の半ばにはいつものがおきぱに現れ
て皆が利用できる状態になるとおもいます。

20120425追:
●OpenOCDからのフラッシュ書き込み速度をアップさせる試み
system_mb9bf61x.c内のSystemInit(でしたっけ？)関数のPLLを使ってクロックアップ
しているルーチンをOpenOCDのスクリプトに落としてみました。
ただし、汎用性を保つために大元のメインクロックは外部のシリコン発振器からの4MHz
ではなく内部RC発振の4MHzを使用し叩きあげるようにしました。

↓で、こちらが昨日と同じバイナリを書き込んだ結果です。
> "C:¥Devz¥AVR¥WinAVR¥utils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/jtagkey2.cfg -f target/mb9bf618t_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.6.0-dev-00529-gf28a5d9-dirty (2012-04-25-13:27)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
trst_only separate trst_push_pull
500 kHz
cortex_m3 reset_config sysresetreq
verify Capture-IR is disabled
Info : device: 6 "2232H"
Info : deviceID: 67358712
Info : SerialNumber: 22222222A
Info : Description: Amontec JTAGkey-2 A
Info : max TCK change to: 30000 kHz
Info : clock speed 500 kHz
Info : JTAG tap: mb9bfxx8.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : mb9bfxx8.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : JTAG tap: mb9bfxx8.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x00000114 msp: 0x20000000
Rize up to Internal PLLed Clock!
6000 kHz
auto erase enabled
Info : Fujitsu MB9Bxxx: Sector Erase ... (0 to 0)
Info : Fujitsu MB9B500: FLASH Write ...
wrote 16384 bytes from file main.elf in 1.671886s (9.570 KiB/s)
verified 804 bytes in 0.421878s (1.861 KiB/s)
Info : JTAG tap: mb9bfxx8.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
shutdown command invoked

wrote 16384 bytes from file main.elf in 2.046889s (7.817 KiB/s)
だったのが
wrote 16384 bytes from file main.elf in 1.671886s (9.570 KiB/s)
と結構改善してます。比較元のサイズが小さいので分かりにくいですが、バイナリのサイズ
がさらに大きくなると違いがさらに出てくることでしょう。
もちろんこちらにも反映済みです。

●毎年恒例の電源ラインは大丈夫か？
※使用したもの
　・PCのUSBポート
　・Interface2012年6月号付録のFM3マイコン基板(LED点滅書き込み済み)
　・5mのUSBA-miniBケーブル+1mのUSB延長ケーブル
　・テクトロのオシロ

※USBコネクタを指してPCのUSBポートから+5V電源を供給した時の+5Vラインと
　レギュレータ出力の+3.3Vラインの電圧波形を見る
　
　+3.3vの立ち上がり時に+5Vラインが一瞬突入で1Vほどドロップしてるけど
　以前みたく上に跳ねてはいないので基板単体で見たら大丈夫だ、問題無い。

※144MHzで動作中の時の+5Vラインと+3.3Vラインの電圧波形を見る
　
　大丈夫だ、問題無い。

※USBコネクタをPCのUSBポートから引き抜いて+5V電源を断った時の+5Vラインと
　レギュレータ出力の+3.3Vラインの電圧波形を見る
　
　大丈夫だ、問題無い。

※総評
　大丈夫だ、問題無い(イーノックみたいな顔で)

…ってねむいさんが太鼓判押したら大抵悪いこと起きるんですよね～