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に
反映していこうと思います。
せっかくSTM32F427超格安全部載せ基板買ってしまってもったいないですし！

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

今月(2012年7月号)のInterface誌は予想に反して私のようなホビイストには
とてもありがたい内容となっておりました。
ねむいさんは正直Windowsネイティブな環境でもGCCでビルドや
デバッグできるのになぜか面倒なcygwinを使わせた上糞の役にも立たないLED
点滅で終わらせて実用的な作例はIARとかKEILのIDEのみで行って｢んんんｎ〜〜！！！
GCCは面倒ですぞ〜！CQ出版がお勧めするIARやKEILを使ってくだされ〜！１！｣って
販促するパタンで畳み掛けると思ったのですがどうせなら開き直ってDS-5とか
推せよとかいつも思っていたのですが今回は全然そういう事は全くなく、
オープンソースなソフトウェア(OSS)をフルに活用した記事が満載でした。
もちろん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コアなのでノーカウントと
させていただきます！１１！！！！




…さて戯言はこの辺にして、今年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ラインの電圧波形を見る

　大丈夫だ、問題無い。

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


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

Go to top of page