Kinetis KEシリーズを使う
先月に引き続き温め過ぎて腐っちゃったシリーズ第2弾いきます！
元はFreeScle社製でしたがNxPに喰われさらにQualcommに丸ごと喰われてしまう予定で
すが+5V動作可能なARMマイコン、Kinetis-Eシリーズは現在も順調に展開されております。
(ていうか今のラインナップ5Vで168MHzで動くM4コア製品まで拡張されてるのか…)
今回はその最初期にリリースされたKE02シリーズとその評価ボード(以下FRDM板)を紹介
させてもらいます。
ボードの背後でいないさんが何かを主張していますが気にしないでください★
もともとノイズの多い環境でノイズ耐量を得る目的として開発されたマイコン故に+3.3V
動作はもちろんの事+5Vでも動きますがそれ故に動作周波数は当時はM0+コアの中でも
特に低く、AVRと同じ20MHz動作が上限となっています。
内蔵Flash/SRAMも其々最大64kB/4kBとささやかものとなっています。
当時はまだFreeScale預かりだったのでサンプルコードもKLシリーズとかよりもさらに
適当な奴しかなく、Keilのu'Visionに収録されたサンプルコードやヘッダファイルを
参考にGCC向けにプロジェクトを落とし込んでみました。
基本的なMCUアーキテクチャは従来のKinetisと全く同じなので不用意な書き換えですぐにBricked
ってしまう問題も健在です☠
KEシリーズのフラッシュ書き込み機構は従来とは違い、レジスタ構成がまったく別のもの
になっているのでOpenOCDのフラッシュ書き込み用のソースは他のKinetisシリーズとは
別のものになっています。ねむいさん評価報告やっただけだけですけどなんでか知らなんのです
けどソースの作者名に名前連ねてもらっています。ありがとうございます。
> "C:¥Devz¥Coreutils¥bin¥make.exe" programOpenOCDでフラッシュ書き込みした時のログはこんな感じです。
openocd -s C:/Devz/ARM/OCD/tcl -f interface/jlink_swd.cfg -f target/kexx_swd_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.10.0+dev-00161-g1725abc-dirty (2017-06-23-00:33)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
swd
Info : add flash_bank kinetis_ke kexx.pflash
cortex_m reset_config sysresetreq
none separate
adapter speed: 1000 kHz
Info : No device selected, using first device.
Info : J-Link OpenSDA 2 compiled Oct 13 2015 12:10:56
Info : Hardware version: 1.00
Info : VTarget = 3.300 V
Info : clock speed 1000 kHz
Info : SWD DPIDR 0x0bc11477
Error: MDM: failed to read ID register
Error: MDM: Failed to check security status of the MCU. Cannot proceed further
in procedure 'init' called at file "C:/Devz/ARM/OCD/tcl/target/kexx_swd_flash.cfg", line 125
in procedure 'ocd_bouncer'
Info : SWD DPIDR 0x0bc11477
Info : kexx.cpu: hardware has 2 breakpoints, 2 watchpoints
Info : MDM: Chip is unsecured. Continuing.
target halted due to debug-request, current mode: Thread
xPSR: 0x21000000 pc: 0x000000cc msp: 0x20000c00
Info : Watchdog stopped
auto erase enabled
Info : KE02 sub-family
Info : Flash clock ready
Warn : flash configuration field erased, please reset the device
Info : Flash clock ready
Info : Kinetis KE: FLASH Write ...
wrote 8192 bytes from file main.elf in 0.734375s (10.894 KiB/s)
verified 7936 bytes in 0.093750s (82.667 KiB/s)
Info : MDM: Chip is unsecured. Continuing.
shutdown command invoked
> Process Exit Code: 0
> Time Taken: 00:01
かつて幾つかのKinetisの品種では通常のreset initで繋ぎに行くとウォッチドッグ
リセットが発動し、上手くhaltしないと言う問題があってちょっとトリッキーなcfgを
組む必要があったのですが最近のコミットでソースコードそのものとcfgとで連携して
ひとまずウォッチドッグを止めに行く措置が取られ、ほぼすべてのKinetisの品種で
安定して書き込み・デバッグができるようになりました。
ちなみにFlexRAMやFlexNVMを設定している場合でもコケないで正しく書き込みが
出来るようにも修正されています。数年前はかなり危ない実装だったんｽね…
FRDM板の標準デバッガはOpenSDAですがはっきり言ってあまり使えないので速攻
J-Linkに差し替えてしまいましょう！上記ログもJ-Linkで繋ぎにいったものとなって
います！
JLinkのファームに書き換えるとmbed対応済の証であるマスストレージが見えます。
ちゃんとドライブラベルもJLinkになってて芸が細かいですね。使いませんけど。
ちなみにねむいさんのこさえたプログラムはLED点滅をしながら…
FRDM板上にある速度センサの値をprintf関数で返すという評価板の機能フルに利用
したものとなっております☆
尤も冒頭で述べたとおりこのボードで使用されているKE02ZはKEシリーズの最初期
の品種でコアクロック上限が20MHzまでとなるのでUARTのボーレートもねむいさん
標準の230400bpsではさすがに無理で115200bpsに落としています。
最初購入した当初はノイズ云々はサブ的なものでホントは8bitな+5Vマイコンの置き
換え狙いかと思っていましたが2017年現在では168MHzで動くCortex-M4の品種にも
拡大されておりノイズに厳しい環境下での使用をマジで狙ったものとなっているようです。
私も興味が出てきましたのでM4コアの奴が手に入ったらまたレポートさせて頂きます！
トラ技ARMライタをARMライタとして使わない
今回はトラ技ライタをCMSIS-DAPデバッグアダプタとして使用せず一般的なARM基板と
して使用してみました。
トラ技ライタに乗っかっているLPC11U35/501はお尻の"501"の部分がミソでRAMが2kb
増量しています。残念ながら元からあるRAM0とはアドレスが繋がっていないので用途
は限られてしまいます。使い道としてはSTM32F4みたいにスタック領域として使うの
が良いと思います。
あとねむいさんがNxP系のマイコン扱う際に開口一番に言うことはもうわかっている
かとは思いますが何度も何度も何度も何度もｎ…もういいや(諦観)
ちなみにRAM1はPOR直後は寝ているのでクロックを供給して起こしてやらないといけ
ません。少電力をうたうマイコンではこういった罠がよくあるのでマニュアルは目を
皿にしてじっくり読みましょう。さもなければ貴重な時間を無駄にしちゃいます！
そういうことも頭に入れつつGCCのプロジェクトを作成してみました。内容はLEDを交互に
点滅させてなおかつUARTから文字列を垂れ流すといったごくごく基本的な代物です。
ベースプログラムは自分のLPC11U14の物で、UARTドライバはChaN氏のLPC2388
のFatFs移植サンプルにあったFifoバッファを使ったものをさらに移植しております。
めんどくさいので私が使用してるパソコンオシロPicoScope3206Aのロジックデコード機能
を用いて230400bpsで文字列が吐かれてるのを確認しました(やっけつ
このパソコンオシロなPicoScope、ソフトウエアのバージョンアップでロジック解析機能も
付いたのはいいのですがXPで起動不可能というかなりF**Kな不具合があったのですが、
Version6.8.6でようやく直ってくれたようです#波形保存とかもできるのですがスクショ機能は
ちょっと貧弱なのでWinShot等のキャプチャツールも使いこなしています。
今回のプログラムの書き込み/デバッグに関しては私の定番のOpenOCDからとなります。
OpenOCDのコンフィグファイルはLCP11U14の物をそのまま使用出来ます。makefile中の
デフォルトデバッグアダプタはCMSIS-DAPからとしていますが、Versaloon,STLink/V2等
の一般的なSWDで繋がるデバッグアダプタももちろん使用可能です。
ちなみにこのLPC11U35、データシート上ではJTAGインターフェースもサポートしてる
ように見えるのですが、LPC800シリーズと同じくバウンダリスキャン用に特化されて
いるのでJTAG経由では書き込みやデバッグは一切できません。
SWDの方が信号の数も少なく使い勝手もいいのでこれからの小規模なARMマイコン
ではSWJ-DPではなくSW-DPが完全に主流となるでしょう。
LPC800シリーズを使ってみる4 -ついでにトラ技ライタも使う-
私もご多忙にもれずトラ技ライタなる基板(雑誌は付録)を買ってきましたよ。
今回は基板単体ではすぐに使うことはできずUSB-miniBコネクタと1.27mmピッチ*2の
ヘッダ、そして幅が狭いタクトSWが必要です。
上記のものはマルツで買わなくても秋月で以前購入したものでほぼまかなえるので、
秋月フリークな貴方は全く問題はないでしょう。私も以前JTAGKey2Compatibleを作成
した時にチョイスした面実装タクトSWを利用しております。ちょっとコツが要ります
が、私のぶろぐ見てる方ならこの程度の作業は楽勝だと思います。
とりあえず最低限のパーツを付けるとこんな感じになります。あーそうそう、…2/9は
いないさんの誕生日でしたね♥うっかり写っちゃいましたね♥ぱんつは駄目だったけどぶらなら
繊細なぴいぶろ君は怒らないみたいなので学校や職場でどんどん見てほし
さて、このトラ技ARMライタはLPC11U35が載っていて、CMSIS-DAPのファームを仕込む
ことによって文字通りライタにせしめることができます。正直これに関してはLPC812-MAX
のMBED版CMSIS-DAPと全く同じなので特記すべきことはありません。
もちろんふつーにOpenOCDから使用可能です!
ターゲットは300milのDIPと化したLPC811さんです！秋月さんの8PinDIP変換を2連結
で16Pinとして使うのがミソです★
このDIP化ネタ、もはや10番煎じくらいの手あかが付きまくったネタなのですがやら
ずに居られません。
前回LPC810で遊んだ時のように空中配線のやっけつです。ところで…
…
CN5にJST-EHの8Pinコネクタつける際に気付きましたが…
LPC-Link2からのコピペですかトラ偽らしい(ﾆｰｻﾝ顔で)…まぁいや
新声社亡き後誤植を継ぐ者はCQ出版だけですから(諦観
20140313追:
あのさぁ…
この程度は誤植のうちに入らぬということかー！！！
20140220追：
ねむいさんの探し方が悪いだけだと思いますがトラ技ARMライタの回路図が誤植満載の
紙媒体以外で全く見当たりません(怒)今どきPDFで回路図提供しないとかどういう根性
しているのでしょうか(ﾋﾞｷﾋﾞｷホントふざけてますね(ﾋﾞｷﾋﾞｷ
やはりカンガルー先輩をオーストラリアから召還し〆て頂かないと駄目ですねマジで(ﾋﾞｷﾋﾞｷ
思えば過去の記事ではカンガルー先輩に対して"やる気がわかないと仕事をしない気分屋"
とかいう駄目な日本企業にありがちな駄目な経営者目線でレッテルを貼っています。
頑張って仕事して(いる仕草を見せ)ない奴は駄目な奴だ！！！苦労して仕事をしない奴は
生意気だ！！！と言わんばかりの陰湿な主張がにじみ出ているようでそれとはまったく
真逆のマトモな精神を持つカンガルー先輩はCQ出版と袂を分けて正解だったのであろう
…とひしひしと感じます。
ちなみに現在のカンガルー先輩は本国に帰国後、己の野性に目覚めたのかビルドアップした
筋肉超満載状態となっております。なぜこんなにムキムキになる必要があるのかというと
巨大動物図鑑さんからの解説から考察すると上半身(上腕)で相手の攻撃を制し破壊力がある
蹴りで攻撃するという独特な戦闘法を取っている事にあることが考えられます。
ここまで述べた時点でもう気づいた方もいるかもしれませんが…
そう、これは二代目霊界探偵の仙水忍さんが体得した霊光裂蹴拳です！あらゆる武術を
体得した上でないと使用が許されないあの！
こうなるとカンガルー先輩は暗黒天使(ダークエンジェル)である可能性まで出てきました。
魔界の穴があくまでもう時間はありません！急げ幽助！
MBED版CMSIS-DAPもなひたふさんビルドのCMSIS-DAPも特に書き込みの性能差はなく、
同様に使用可能ですが何度も言っておりますがMBED版の方はVCPドライバのインストール
を行わないとCMSIS-DAPが認識されないのでご注意ください。
ちなみにフラッシュの書き込みは全般的に遅いです。これはOpenOCDからCMSIS-DAPを
使った時の致命的な弱点で、OpenOCD側のプログラムの構造上PC->ターゲットのデータ
送信時にブロック転送コマンドを使わずすべてちまちまと転送を行っているからです。
Versaloonもおなじような感じなのですがUSBバルク転送なのである程度ひとまとめにして
ドカンとやり取りができ速度的にはまだ何とかなっております。しかしCMSIS-DAPはHID
クラスを利用しているのでバルク転送が出来ず、インタラプト転送になります。
USBのフルスピードの場合はフレームあたり1mSec区切りとなるので、インタラプト転送
でも64バイト送れるはずなのですが、上記のとおりターゲットへの書き込みの際にブロッ
ク転送コマンドを使用していないため4バイトずつデータを送っているのと全く同じに
なってしまい、さらに転送の確認を行っているため実際には2mSecごとに4バイト書き込む
ということになるためどう頑張っても2kByte/Sec以下の書き込み速度になってしまうの
ですorzさらにマイコン-CMSIS-DAP間のSWDのオーバーヘッドもあるので実際の書き
込み速度は1.5kByte/Sec以上出たら御の字ですorz
(注:READの際はブロック転送をおこなっているので早い)
そう言った弱点をトラ技で解説してさらに対策とか講じるのかなと思ったのですが…
OpenOCDに関しては案の定貫徹スルーで商用ツールからの使用を解説しておりました。
解決するためにはadi_v5_cmsis_dap.cにメスを入れて送信時もブロック転送を使えるように
しなければならないのですが他のデバッグアダプタと整合性が取れなくなってしまうので
私もどうしたらいいか今非常に困ってます…。
以前も述べましたがLPC-Link2ならばUSBハイスピードで繋がり、フレーム間隔も125uSec
ごとにスプリットされるので多少速度的にはマシになります。OpenOCDからCMSIS-DAP
をまともに使いたいのなら現状ではLPC-Link2で行うべきです。
20140213追：
なひたふさんも全く同じことを指摘していますね
↑一応記しておきますが…なひたふさんと偶然同時刻に偶然同じ事実を指摘しただけです。
私は自分の記事を書くのに夢中でなひたふさんのブログエントリを全く見ておらず、
一切パクってませんのであしからず！
↑ってしっかり念押ししとかないと斜め読みする人にtwitter上で有ること無いこと流されそうですので
20150406追:
CMSIS-DAPが本来の力を取り戻しました。
糞遅かったOpenOCDからの書き込みも快適に行えます☆
それはさておき今回のトラ技の特集ではなひたふさんがJTAGから始まり主流になった
SWD(正確にはSWJ-DP/SW-DP)に至る流れも含め非常に分かりやすく解説されているので
OpenOCD等のデバッガの動作原理の理解を深めたい方にとって必読だと思います。
基板はあくまでおまけですよおまけ！
おまけのおまけ
…
F**K!!!!!!
LPC800シリーズを使ってみる3 -LPC810のことはもう忘れた-
…これが1EURの時代ですか…時代は変わったものですね…!
というわけで私もLPC812-MAXをゲッツしました。ちょっと時間がかかった理由はというと、
値段がキャンペーン価格(1EUR)だったおかげで税関で怪しまれて止められたという
ものだったりしますがこういうケースに遭遇したのははじめてでした。
以前購入していたLPC812XPressoにI2CなAD/DAとI/Oエキスパンダが加わり、基板の
レイアウトもArduinoのシールドが載るようになっていま…
…コネクタがちょっとずれてる…まぁこれは見なかったことにして！
この基板はXpresso系とは違い、mbedとして利用が可能なLPC11u35がmbedチップとして
載っていてさらにこれはCMSIS-DAPとしても働きKeilのuVisionからデバッグも可能と
なっていま…
おや…PCF8591Tの足に変なものが…
…ハンダボール発見！…おいおい
価格は1EUR(送料込)なので細かい部分に文句たらさずミシン針でﾋﾟｼっと弾いて対処
完了です。これにて一件落着！…したら今日のぶろぐ終わっちゃうのでまだ続けます…
●とりあえずVersaloon
私の定番のOpenOCDとの連携です。この時注意すべきはSWDの2つの信号がmbedチップと
干渉するのでMSCブートローダーモードにしてmbedチップ側のSWDを殺しておく必要が
あります(CMSIS-DAPのファームウエア側でトライステートにしてくれたら手間省ける
のですが…)。
も一つ注意すべきは回路図をよく見れば気づくはずですが12MHzのXTALが繋がっておらず
mbedチップ側からクロックが供給されているのでスタートアップの定義を内部CR発振に
するなり半田でつなぎかえる等の変更は必要です。LPC812に関しては内部の12MHz発振
からPLLで24MHzにするのが最も潰しが効くかと思います。
そんなわけでおきぱにあるLPC812のサンプルは既にLPC812-MAXにも対応済です。
まだLEDとsystickだけですが順次拡張予定です。
●MBED CMSIS-DAPを試す
話が前後しますがLPC812-MAXをPCと接続するとマスストレージ(MSC)が認識されます。
そこからさらにmbedのドライバをインストールするとUSBコンポジットデバイスが認識され、
続いてUSB-CDCの"MBED VCOM"とUSB-HIDの"MBED CMSIS-DAP"が認識されてmbed
の仮想COMとMSC,そしてCMSIS-DAPが使用できるようになります。なお、当ぶろぐにおいて
はマトモに商用のIDEからCMSIS-DAPを使うはずもなくいつものOpenOCDから使用する
ことになります。
以前KL25Zを使用した時にCMSIS-DAPをお試ししてましたがその時はほとんど使い物に
ならない代物でした。しかしgerritに上げられた後は修正がどんどん入り現在ほぼ完成
状態になりました。もちろんデバッグ可能なコードサイズの制限は一切ありません！
さらにSTLink系のHLAアダプターでは不可能なローレベルアクセスも可能です！Kinetis
系のチップ使ってやらかした時も大丈夫！細かい部分は後日OpenOCDの記事にて解説
しますが今はとりあえず使用してみましょう。
フラッシュ書き込み
デバッグ
初期と比べるとかなりいい感じです。
さらっと使用した感じではUSBのパケットを有効利用していないのか書き込みが極端に遅く
感じます。CoFlashではちゃんと早く書き込めているのでここら辺はさらに改善の余地が
あるでしょう。ここをクリアできたらゴールかしら…。
私のおきぱのOpenOCDはまだCMSIS-DAP対応ではありませんが、OpenOCDのコミットに
マージされたら即座にSWD版Versaloonのコードと一体化させて反映させるつもりです。
●おまけ
KL25ZもMBED版CMSIS-DAP化して書き込んでみました。
PE-MICRO提供のCMSIS-DAPとMBED版CMSIS-DAPは少し仕様が違うのでご注意を。仮想
COMが使えるMBED版をお勧めします。
書き込んだときはこんな感じです
当たり前ですが上記のCMSIS-DAP化したLPC-Link2でも使用可能です♥
HighSpeedなのでちょっと書き込み速度が上がります♥
(ところでLPC-Link2用のMBED版CMSIS-DAPはまだでしょうか‥‥？)
Kinetis Lシリーズをつかってみる3
20161123追：
FreeScaleはNxPに喰われた後さらにQualCommに喰われました
VersaloonのBBSにはすでにレポートしていますが、FreeScaleのKinetis-Lシリーズを
OpenOCDから使う際のフラッシュ書き込みのスピードを大幅に増加させることに成功
しましたのでこちらでもご報告します。
以前、私はKL25Z,KL05Z等のKintis-LシリーズのマイコンにOpenOCDからの書き込みに
対応させていました。しかしこれらのマイコンは"Program-LongWord"という4バイト単位で
フラッシュロムに書き込むコマンドしかなく、SWD接続でちまちまやり取りをしている
と1KiB/Sec程度の速度しか出ないため、役に立たない代物でした。
さらにそのときにSRAM上で動くブートローダーが必要だ…と言っていました。結局
自分で作成する羽目になりましたorz
原理はそこまで難しくは無く、上記のSRAM上で"Program-LongWord"を送り込んだワー
ド単位のデータの数だけ動作するプログラム(とデータ)を送り込んで実行するだけです。
具体的には先ずC言語で以下の関数をコンパイルして…
void kinetis_lwrite(uint32_t *pLW,uint32_t faddr,uint32_t wcount)
{
volatile uint8_t * pfstat = (uint8_t*) (0x40020000u+0);
volatile uint32_t* pfcoob3 = (uint32_t*)(0x40020000u+4);
volatile uint8_t * pfcoob0 = (uint8_t*) (0x40020000u+7);
volatile uint32_t* pfcoob7 = (uint32_t*)(0x40020000u+8);
#define FTFx_FSTAT (*(pfstat))
#define FTFx_FCCOB3 (*(pfcoob3))
#define FTFx_FCCOB0 (*(pfcoob0))
#define FTFx_FCCOB7 (*(pfcoob7))
for(register uint32_t i=0;i<wcount;i++){
/* wait till CCIF bit is set */
while((FTFx_FSTAT&FTFA_FSTAT_CCIF_MASK) != FTFA_FSTAT_CCIF_MASK){};
/* clear RDCOLERR & ACCERR & FPVIOL flag in flash status register */
FTFx_FSTAT = FTFA_FSTAT_ACCERR_MASK|FTFA_FSTAT_FPVIOL_MASK|FTFA_FSTAT_RDCOLERR_MASK;
FTFx_FCCOB3 = faddr;
FTFx_FCCOB0 = 0x06;
FTFx_FCCOB7 = *pLW;
faddr += 4;
pLW++;
/* All required FCCOBx registers are written, so launch the command */
FTFx_FSTAT = FTFA_FSTAT_CCIF_MASK;
/* Wait for the command to complete */
while((FTFx_FSTAT&FTFA_FSTAT_CCIF_MASK) != FTFA_FSTAT_CCIF_MASK){};
}
}
出てきたアセンブラリストをさらに最適化を行い今度はその最適化したアセンブラ
ファイルをコンパイルしてマシン語を得ます。
で、このマシン語をOpenOCDのおソースにデータの形で持ちます、↓こんな感じです。
/* Kinetis Program-LongWord Microcodes */
const uint8_t kinetis_flash_write_code[] = {
/* Params:
* r0 - workarea buffer
* r1 - target address
* r2 - wordcount
* Clobbered:
* r4 - tmp
* r5 - tmp
* r6 - tmp
* r7 - tmp
*/
/* .L1: */
/* for(register uint32_t i=0;i<wcount;i++){ */
0x04,0x1C, /* mov r4, r0 */
0x00,0x23, /* mov r3, #0 */
/* .L2: */
0x0E,0x1A, /* sub r6, r1, r0 */
0xA6,0x19, /* add r6, r4, r6 */
0x93,0x42, /* cmp r3, r2 */
0x16,0xD0, /* beq .L9 */
/* .L5: */
/* while((FTFx_FSTAT&FTFA_FSTAT_CCIF_MASK) != FTFA_FSTAT_CCIF_MASK){}; */
0x0B,0x4D, /* ldr r5, .L10 */
0x2F,0x78, /* ldrb r7, [r5] */
0x7F,0xB2, /* sxtb r7, r7 */
0x00,0x2F, /* cmp r7, #0 */
0xFA,0xDA, /* bge .L5 */
/* FTFx_FSTAT = FTFA_FSTAT_ACCERR_MASK|FTFA_FSTAT_FPVIOL_MASK|FTFA_FSTAT_RDCO */
0x70,0x27, /* mov r7, #112 */
0x2F,0x70, /* strb r7, [r5] */
/* FTFx_FCCOB3 = faddr; */
0x09,0x4F, /* ldr r7, .L10+4 */
0x3E,0x60, /* str r6, [r7] */
0x06,0x27, /* mov r7, #6 */
/* FTFx_FCCOB0 = 0x06; */
0x08,0x4E, /* ldr r6, .L10+8 */
0x37,0x70, /* strb r7, [r6] */
/* FTFx_FCCOB7 = *pLW; */
0x80,0xCC, /* ldmia r4!, {r7} */
0x08,0x4E, /* ldr r6, .L10+12 */
0x37,0x60, /* str r7, [r6] */
/* FTFx_FSTAT = FTFA_FSTAT_CCIF_MASK; */
0x80,0x27, /* mov r7, #128 */
0x2F,0x70, /* strb r7, [r5] */
/* .L4: */
/* while((FTFx_FSTAT&FTFA_FSTAT_CCIF_MASK) != FTFA_FSTAT_CCIF_MASK){}; */
0x2E,0x78, /* ldrb r6, [r5] */
0x77,0xB2, /* sxtb r7, r6 */
0x00,0x2F, /* cmp r7, #0 */
0xFB,0xDA, /* bge .L4 */
0x01,0x33, /* add r3, r3, #1 */
0xE4,0xE7, /* b .L2 */
/* .L9: */
0x00,0xBE, /* bkpt #0 */
/* .L10: */
0x00,0x00,0x02,0x40,/* .word 1073872896 */
0x04,0x00,0x02,0x40,/* .word 1073872900 */
0x07,0x00,0x02,0x40,/* .word 1073872903 */
0x08,0x00,0x02,0x40,/* .word 1073872904 */
};
引数に取るレジスタはARMの関数呼び出し規約に即します。ここで間違えると失敗しま
すのでご注意を。Kinetis系のマイコンの場合は最悪のケースになる場合がある(後述)
のでマジでご注意を！！
後は上のプログラムの小片を流し込んで実行させるだけです。
OpenOCDには"target_run_algorithm"という仕組みがあるので引数にとるレジスタを
正しく設定したあとこれを利用して実行するとSWDの通信を介さずターゲット上で書
き込みプログラムが実行されます。通信のオーバーヘッドが無いのでもちろん書き込
み動作はとしては非常に早くなります♥
こちらに新旧の書き込み速度を比較したlogをVersaloonとSTLink/v2で試したものを
まとめた圧縮ファイルがあるので参考にしてください。見るのがめんどくさい方の為
に下に要素だけ抽出しましたが、書き込みスピードは10倍以上改善されたのが分かる
と思います。
旧ドライバ:
wrote 36648 bytes from file main.elf in 26.328295s (1.359 KiB/s)
新ドライバ:
wrote 36648 bytes from file main.elf in 1.906275s (18.774 KiB/s)
これで市販のツールに勝るとも劣らないパフォーマンスを得ることが出来ましたので
GCC環境でもVersaloonかSTLink/V2を持っていさえすればOpenOCDでﾊﾞﾘﾊﾞﾘ書き込み/
デバッグが可能です！
あと、しつこいくらいに言っておきますがこちらの件だけはご注意ください。security
とmass-erase disableを同時に有効にしてしまうとMDM-APでも復帰不可能の完全な
ゴミにしてしまいます！
…ねむいさんも今回のドライバ改良の際にFRDM-KL25Zをゴミにしてしまいましたorz
簡単にゴミに出来て回復手段も全くないとか雄度高すぎですよこのマイコン…
で、仕方ないのでおなじのを買うはめになりました…
↑良く見ると基板りビジョンのほかにチップの刻印も違っていた…
ちなみにFRDM系ボードにあるOpenSDA側のK20マイコンもバッチリsecurityとmass-erase
のdisableが掛けられていやがってSTマイクロのDiscovery系の板みたいな自由度は全く
ありません！ぜんぜんFreedomぢぁない！！F**K!
…はぁはぁ…失礼、とにかくすでにバイナリには反映してますので皆さんもﾊﾞﾘﾊﾞﾘ使っ
てください…今のところ私以外で試された方はAlanさんただ一人のようですが‥
●おまけ
KinetisのOpenOCDのコード見ててなんとなくフラッシュドライバの追加の方法が分かって
来たのでNuvotonのNUC1xx系のマイコンのドライバの実装も試行中です。
実はすでに低速なSWD通信によるProgram-LongWordの書き込みには成功してたりします。
こちらもアトミックに書き込みできるようになったら別枠でご報告とさせていただきます。
LPC-Link2(という名のLPC4370評価ボード)を使ってみる
前回は2013/06中旬現在も謎に包まれたNxPのLPC4370が搭載されたLPC-Link2を
OSSで動かし、さらにLPC4370がトリプルコアであることまで突き止めました。
今回はまず安定してLPCLink2として動かすところから切り込みたいと思います。
もちろん今回もメーカ製のツールの事はスルーです！そもそも私のぶろぐに基本的な
使い方なんて期待して見に来ている人なんて誰ひとりいませんから…
●LPCLink2をJ-Linkとして"安定して"動かそう
さて、購入時にNxPが提供するdfutoolからJ-Linkファームウエアをダウンロード
するところからはぢめますがちょっとUSBの認識がおかしいのに気づきました。
↑たぶん正しいときのPOR
↑ちょっと変なPOR
気になってリセット波形を見るとLPCLink2上のLPC4370のreset信号のPORの波形が
微妙に違うときがありました。まさかPORの幅が短い時があるせいですか？と思い、
外付けのリセットSWを付けましたがやっぱり認識しない時は駄目。
それでVCC周りから回路をオシロでずーっと調べていたのですがそんな折にNxP
公式のconfiguration-toolがアップデートされ旧J-LinkファームのUSBがコケる問題が
あったことが判明!!つまりファームの問題！Tooooooo S**K!!
2013/05/31付けのファームと入れ替えることによりUSBの認識は安定するように
なりましためでたしめでたし♥J-Linkエミュとして使用されている方は早急にファームの
変更を行ってください。
つぎに本来の目的だったOpenOCDから使うことを目指しました。前回お見せした
通りJ-LinkファームでOpenOCDから書き込みデバッグできるのですが、たまにchain
読めずその時点でコケて上手くいかない状態が出てきました。
以下、STM32F407ZGT6に書き込みしようとした時のログです。
↓上手くいくとき
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/jlink.cfg -f target/stm32f4x_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.8.0-dev-00024-g08d4411-dirty (2013-06-06-10:12)
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 speed: 1000 kHz
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
cortex_m3 reset_config sysresetreq
verify Capture-IR is disabled
Info : J-Link initialization started / target CPU reset initiated
Error: J-Link command EMU_CMD_VERSION impossible return length 0x7008
Error: J-Link command EMU_CMD_VERSION failed (0)
Info : J-Link JTAG Interface ready
Info : clock speed 1000 kHz
Info : JTAG tap: stm32f4x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : JTAG tap: stm32f4x.bs tap/device found: 0x06413041 (mfg: 0x020, part: 0x6413, ver: 0x0)
Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : JTAG tap: stm32f4x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : JTAG tap: stm32f4x.bs tap/device found: 0x06413041 (mfg: 0x020, part: 0x6413, ver: 0x0)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x080450cc msp: 0x10010000
Info : reduce speed request: 21000kHz to 12000kHz maximum
adapter speed: 21000 kHz
auto erase enabled
Info : stm32f4x errata detected - fixing incorrect MCU_IDCODE
Info : device id = 0x10006413
Info : flash size = 1024kbytes
wrote 655360 bytes from file main.elf in 16.062500s (39.844 KiB/s)
verified 555708 bytes in 0.656250s (826.946 KiB/s)
adapter speed: 1000 kHz
Info : JTAG tap: stm32f4x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : JTAG tap: stm32f4x.bs tap/device found: 0x06413041 (mfg: 0x020, part: 0x6413, ver: 0x0)
shutdown command invoked
> Process Exit Code: 0
> Time Taken: 00:19
↓いかないとき
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/jlink.cfg -f target/stm32f4x_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.8.0-dev-00024-g08d4411-dirty (2013-06-06-10:12)
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 speed: 1000 kHz
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
cortex_m3 reset_config sysresetreq
verify Capture-IR is disabled
Info : J-Link initialization started / target CPU reset initiated
Info : J-Link LPC-Link 2 compiled May 31 2013 17:31:46
Info : J-Link caps 0xb9ff7bbf
Info : J-Link hw version 18010000
Info : J-Link hw type uknown 0x12
Info : J-Link max mem block 38488
Info : J-Link configuration
Info : USB-Address: 0x0
Info : Kickstart power on JTAG-pin 19: 0xffffffff
Info : Vref = 58.368 TCK = 12 TDI = 1 TDO = 0 TMS = 1 SRST = 0 TRST = 1
Info : J-Link JTAG Interface ready
Info : clock speed 1000 kHz
Info : TAP stm32f4x.cpu does not have IDCODE
Warn : JTAG tap: stm32f4x.cpu UNEXPECTED: 0x00000000 (mfg: 0x000, part: 0x0000, ver: 0x0)
Error: JTAG tap: stm32f4x.cpu expected 1 of 1: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : JTAG tap: stm32f4x.bs tap/device found: 0xd0023bff (mfg: 0x5ff, part: 0x0023, ver: 0xd)
Warn : JTAG tap: stm32f4x.bs UNEXPECTED: 0xd0023bff (mfg: 0x5ff, part: 0x0023, ver: 0xd)
Error: JTAG tap: stm32f4x.bs expected 1 of 1: 0x06413041 (mfg: 0x020, part: 0x6413, ver: 0x0)
Warn : Unexpected idcode after end of chain: 33 0x209820a5
Warn : Unexpected idcode after end of chain: 65 0xffffff83
Error: double-check your JTAG setup (interface, speed, missing TAPs, ...)
Error: Trying to use configured scan chain anyway...
Error: stm32f4x.cpu: IR capture error; saw 0x0e not 0x01
Warn : Bypassing JTAG setup events due to errors
Warn : Invalid ACK 0 in JTAG-DP transaction
Polling target stm32f4x.cpu failed, GDB will be halted. Polling again in 100ms
Polling target stm32f4x.cpu failed, GDB will be halted. Polling again in 300ms
Info : TAP stm32f4x.cpu does not have IDCODE
Warn : JTAG tap: stm32f4x.cpu UNEXPECTED: 0x00000000 (mfg: 0x000, part: 0x0000, ver: 0x0)
Error: JTAG tap: stm32f4x.cpu expected 1 of 1: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : JTAG tap: stm32f4x.bs tap/device found: 0xd0023bff (mfg: 0x5ff, part: 0x0023, ver: 0xd)
Warn : JTAG tap: stm32f4x.bs UNEXPECTED: 0xd0023bff (mfg: 0x5ff, part: 0x0023, ver: 0xd)
Error: JTAG tap: stm32f4x.bs expected 1 of 1: 0x06413041 (mfg: 0x020, part: 0x6413, ver: 0x0)
Warn : Unexpected idcode after end of chain: 33 0x209820a5
Warn : Unexpected idcode after end of chain: 65 0xffffff83
Error: double-check your JTAG setup (interface, speed, missing TAPs, ...)
Error: Trying to use configured scan chain anyway...
Error: stm32f4x.cpu: IR capture error; saw 0x0e not 0x01
Warn : Bypassing JTAG setup events due to errors
Warn : Invalid ACK 0 in JTAG-DP transaction
Error: Target not examined yet
Runtime Error: C:/Devz/ARM/OCD/tcl/target/stm32f4x_flash.cfg:85:
in procedure 'script'
at file "embedded:startup.tcl", line 58
in procedure 'reset' called at file "C:/Devz/ARM/OCD/tcl/target/stm32f4x_flash.cfg", line 85
make: *** [program] エラー 1
> Process Exit Code: 2
> Time Taken: 00:02
J-Linkハードウエアのイニシャライズでコケているような感じはしましたが、コケ
るときとうまくいくときに規則性があるのを見つけてOpenOCDコード内のjlink.cに
切り込みました。
ソースコードを読んだ限りではinit関数の中でJ-LinkハードウエアのI/O設定を通過
する部分があり、LPCLink2によるエミュの場合はそこを通過してしまうと逆にまずい
ことが判明。
というわけでHW-Versionを読み取りJ-LinkのハードがLPCLink2エミュの場合はその
場でinit関数を抜けるようにバイパスしたところうまい具合に動作は安定化してchain
を読みに行くときにコケることは一切なくなりました！
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/jlink.cfg -f target/stm32f4x_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.8.0-dev-00037-gc60deb5-dirty (2013-06-14-23:02)
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 speed: 1000 kHz
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
cortex_m3 reset_config sysresetreq
verify Capture-IR is disabled
Info : J-Link initialization started / target CPU reset initiated
Info : J-Link LPC-Link 2 compiled May 31 2013 17:31:46
Info : J-Link caps 0xb9ff7bbf
Info : J-Link hw version 18010000
Info : J-Link hw type J-Link on LPC-Link2
Info : Vref = 3.300 TCK = 1 TDI = 1 TDO = 1 TMS = 1 SRST = 1 TRST = 1
Info : J-Link JTAG Interface ready
Info : clock speed 1000 kHz
Info : JTAG tap: stm32f4x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : JTAG tap: stm32f4x.bs tap/device found: 0x06413041 (mfg: 0x020, part: 0x6413, ver: 0x0)
Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : JTAG tap: stm32f4x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : JTAG tap: stm32f4x.bs tap/device found: 0x06413041 (mfg: 0x020, part: 0x6413, ver: 0x0)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x080449f4 msp: 0x10010000
Info : reduce speed request: 21000kHz to 12000kHz maximum
adapter speed: 21000 kHz
auto erase enabled
Info : stm32f4x errata detected - fixing incorrect MCU_IDCODE
Info : device id = 0x10006413
Info : flash size = 1024kbytes
wrote 655360 bytes from file main.elf in 15.531250s (41.207 KiB/s)
verified 555708 bytes in 0.640625s (847.116 KiB/s)
adapter speed: 1000 kHz
Info : JTAG tap: stm32f4x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : JTAG tap: stm32f4x.bs tap/device found: 0x06413041 (mfg: 0x020, part: 0x6413, ver: 0x0)
shutdown command invoked
> Process Exit Code: 0
> Time Taken: 00:17
こちらの修正はすでにOpenOCDバイナリに反映しているのでLPCLink2のJ-Linkエミュでも
安心してお使いいただけます。自前でビルドされる方向けにパッチ群も更新しておきました。
UrJTAGも類似した箇所でコケているのでこちらも調査/修正を行う予定です。
20130620追：
UrJTAGも修正掛けました！
所でLPCLink2をJ-Linkとして動かすとNxPのチップにしか使えないはずなのですが
STM32やFM3とかにもOpenOCDからバリバリ書き込み/デバッグが出来てます。"NxP
のチップしか使ってはならない"っていう規約的に使用不可であることを示す文面は
どこにも見当たらないのでねむいさんみたいな使い方しても全く問題ないでしょう。
問題あったら6月上旬の時点でNxPFanﾘﾝｻﾝに〆られてますし。
20130709追:
ライセンス制限が追加され、NxPのデバイス以外で使用を禁ずると明記されました。
OpenOCDからSTM32やKinetisやFujitsuやAtmelのARMマイコンに無制限に書き込み/
デバッグできますが、もう絶対にやってはいけません！やるなよ！絶対にやるなよ！
●LPCLink2をLPC4370評価ボードとして使う
こっからが本懐です！たった2000円と少しでトリプルコアLPC4370が搭載されたマイコ
ン評価ボードが使えるのですから…！
前回のUrJTAGによりコアが3つあるMPUということが判明しています。同時にLPCLink
無印の時みたいにMCUのセキュリティは全くかかっていないのが分かったのでJTAGkey2
でやりたい放題にできちゃいます♥
LPC4370がLPC4350の機能拡張版なのを推定し、LPC4330-Explorerの時に使ったサンプル
をLPC4370向けに作り変えてみました。ひとまずM4のみのシングルコア動作です。
ビルドしたバイナリはボード上にあるSPIFI-SPIROMにプログラムを書き込みます。ここ
ら辺の操作はLPC4330の時と同じですがspifiブートはリセット2回でコケるerrataは無
いのでへんてこなOpenOCDのcfgは書かずに済みます…しかしLPCLink2上のSPIROMは、
openOCDのSPIFIドライバに対応していなかったのでこちらも対応させました…と言って
も単にSPIROMのIDとセクタ/容量を追加しただけです。
↓OpenOCDのログはこんな感じです。もちろんOpenOCDバイナリ・cfgファイルは上記の
修正を反映済です。M0コアが2つ、M4コア1つが見えますね。
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/ftdi/jtagkey2.cfg -f target/lpc4370_lpclink2_spifi.cfg -c "mt_flash_bin main.bin 0x14000000"
Open On-Chip Debugger 0.8.0-dev-00037-gc60deb5-dirty (2013-06-14-23:02)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
cortex_m3 reset_config vectreset
none separate
adapter speed: 2000 kHz
Info : clock speed 2000 kHz
Info : JTAG tap: lpc4370.m4 tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : JTAG tap: lpc4370.m0_0 tap/device found: 0x0ba01477 (mfg: 0x23b, part: 0xba01, ver: 0x0)
Info : JTAG tap: lpc4370.m0_1 tap/device found: 0x0ba01477 (mfg: 0x23b, part: 0xba01, ver: 0x0)
Info : lpc4370.m4: hardware has 6 breakpoints, 4 watchpoints
Info : lpc4370.m0_0: hardware has 2 breakpoints, 1 watchpoints
Info : lpc4370.m0_1: hardware has 2 breakpoints, 1 watchpoints
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x1400350a msp: 0x200029a0
background polling: on
TAP: lpc4370.m4 (enabled)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x1400350a msp: 0x200029a0
Info : Found flash device 'win w25q80bv' (ID 0x001440ef)
cleared protection for sectors 0 through 15 on flash bank 0
auto erase enabled
wrote 65536 bytes from file main.bin in 0.953125s (67.148 KiB/s)
Warn : Invalid ACK 0x7 in JTAG-DP transaction
Polling target lpc4370.m4 failed, GDB will be halted. Polling again in 100ms
Polling target lpc4370.m4 succeeded again
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x1400350a msp: 0x200029a0
cleared protection for sectors 0 through 15 on flash bank 0
verified 4656 bytes in 0.031250s (145.500 KiB/s)
Warn : Invalid ACK 0x7 in JTAG-DP transaction
Polling target lpc4370.m4 failed, GDB will be halted. Polling again in 100ms
Polling target lpc4370.m4 succeeded again
shutdown command invoked
> Process Exit Code: 0
> Time Taken: 00:03
上記のログで"Warn : Invalid ACK 0x7 in JTAG-DP transaction"が出ていますが、
これはOpenOCDから直接レジスタを叩きcoreresetを掛けているために発生しているので
実害は全くありません。
↑いつものデバッグも自由自在です(LPC4370の素性がわかる範囲で)
ひとまず問題なく動くと思われるLPC4370のプログラムをこちらに置いておきますので
物好きな方は試してみてください。最初に述べた通りLPCLink2は余計なプロテクトは
全くないので失敗を恐れずいろいろ試すことが出来るので、なかなかいじりがいが
あるボードだと思います！
Kinetis Lシリーズをつかってみる2
20161123追：
FreeScaleはNxPに喰われた後さらにQualCommに喰われました
え？これは何って！？…さぁ…あ、あたしの弟がぁ…かってにぃエントリしちゃって〜
ま、まぁねむいさんセフィロス派ですがmbedには話のタネにちょっと登録してみた
だけですよぅ〜
mbed/Arduinoのようなハード・ソフトお仕着せ環境はねむいさんは興味はないだけで、
そもそも否定はしておりません。それよりもそれぞれのやりたいことが素直に実現
できてそれぞれが面白いと感じたプログラミング環境をそれぞれが見つけ出し、
素晴らしい製品・作品をつくっていくことこそが最も重要なことだとねむいさんは声を
大にして申し上げさせていただきます！(ただしcygwinと素のEclipseは仏敵)
さて戯言はこの辺にして、今回は前回のKL25に続きさらに機能がシンプル化された
KL05シリーズが搭載された評価ボードFRDM-KL05Zを紹介したいと思います。
この子はKL25ZのものよりもさらにArduinoを意識した作りになっていて"シールド"も
+3.3V互換のものなら搭載できるようになっているようです。
とはいえそっちはほとんど興味なかったので前回OpenOCDに突貫で実装したKinetis-L
ドライバがちゃんとほかの品種でも書き込みできるかの実証に移りました。OpenOCDの
バイナリ見られた方は知っているでしょうけど、結論から言うとKL05Zにも問題なく
書き込み・デバッグ出来ることを確認しました。
↓Versaloon+OpenOCDで書きこんだときのメッセージです。
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/vsllink_swd.cfg -f target/kl05z_swd_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.7.0-dev-00204-g1da9e59-dirty (2013-03-25-10:47)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : OpenOCD runs in SWD mode
none separate
Info : add flash_bank kinetis pflash
adapter speed: 1000 kHz
cortex_m3 reset_config sysresetreq
Info : Versaloon(0x15)by Simon(compiled on Mar 4 2013)
Info : USB_TO_XXX abilities: 0x0000076E:0x010001EF:0xC0000007
Info : clock speed 1000 kHz
Info : Found SWD-DP id:0x0BC11477
Info : kl05z.cpu: hardware has 2 breakpoints, 2 watchpoints
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x21000000 pc: 0x000000cc msp: 0x20000c00
Rize up to Internal PLLed Clock!
auto erase enabled
Info : Probing flash info for bank 0
Warn : flash configuration field erased, please reset the device
Warn : Kinetis L Series supports Program Longword execution only.
wrote 9216 bytes from file main.elf in 5.421875s (1.660 KiB/s)
verified 8308 bytes in 0.125000s (64.906 KiB/s)
shutdown command invoked
> Process Exit Code: 0
> Time Taken: 00:06
STLink/V2でももちろん書き込みデバッグは可能ですが、前回も述べましたがSTLink/V2
からではMDM-APを直接叩くことは出来ないので間違ってセキュリティビット掛けてしまった
フラッシュの救済はできませんのでくれぐれもご注意を…。ねむいさん提供のサンプルを
使う限りはハード/ソフトの両面から対策されてるのでセキュリティビットがうっかりかかる
問題はありません。
そして↑のサンプルですが…FRDMのソフトウエアパッケージのほうのサンプルの出来が
あまりというか非常に良くないというかところどころk40シリーズからのコピペな手落ちが
多数見受けられたのでUARTドライバは完全にCMSISに対応するように大幅に書き変えて
おります。同じくKL25Zのサンプルもこちらの変更を反映しCMSIS完全対応してます。
おまけ
●CMSIS-DAPがOpenOCDから使えるようになってるらしい
まぢですか…！とねむいさんも早速ビルドして試してみましたが…
…あかん…
…今後に期待ですね…現状オープンソース系は機能追加が容易なVersaloon一強な
印象です…とはいえFRDM系の基板は書き込み用のハードも一体化されてるので無理
してOSSに走らなくても十分戦えますが、冒頭で述べたとおり自分が取り組みやすい
環境で各々の実現したいことを目指すのがベストだと思います！と説得力のあまり
無い発言で今日の記事をしめくくらせていただきます。
Kinetis Lシリーズはぢめました
20161123追：
FreeScaleはNxPに喰われた後さらにQualCommに喰われました
"OpenOCD + CMSIS-DAP"の検索で飛んできた方はこちらをご覧ください。
バレンタインチ○コのかわりに先行で公開しておりましたが、VersaloonとOpenOCDを
使用したいつもの書き込み・デバッグ環境がFreescaleのCortexM0+コアが載ったKL25
シリーズでもできるようになりましたのでお伝えします。
●もうこういう無駄な買い物は止めようはと思います…が
このFRDM-KL25ZというボードにはMKL25Z128VLK4というKinetis Lシリーズの石が乗っか
っています。当時はいち早くCortexM0+コアを搭載を謳っていた物で、またOpenSDAとい
うオープンソース(らしい)デバッガハードウエアも搭載されて1000円台で販売されてます。
それにしてもこのボードも安いですね。どのメーカもデバッガハードウエアがついて
1000円台が当たり前の時代になりました。
時系列的には同じくCortexM0+コアを持つLPC800と同時期に入手していましたがFreeScale
の石はあまり食指が伸びずほおっていました。そのまま腐らせるのももったいないので
ちょっといじってみようと思いたったわけです。
私が目を付けたのはKL25Zの石よりもOpenSDAの方でした。とにかくデバッガ側のUSB
コネクタをPCと繋げるとマスストレージとVCPとが認識されます。このマスストレージ
はmbedでおなじみのD&Dで書き込みができるってタイプの奴です。ソースコードデバッ
グを行うためにはOpenSDAのファームウエアを書き込む必要があります。同じくこれに
対応したGDBサーバをP&Eマイクロから取得する必要があります。
が、
フリー版のそれは使用に耐えないくらい動きがｶｸｶｸでプログラムのダウンロードも制限
されています。我慢してこれ使うくらいなら最初のマスストレージ使う書き込みでカット
アンドトライした方が10000倍マシです。というわけでボード単体でデバッグ環境建てる
やり方に見切りをつけて冒頭で述べたSWD接続方式のVersaloon+OpenOCDという王道で
環境を作ることにしました。
↑ｶｶﾛｯﾄ！お前がｶｸｶｸナンバーワンだ！
↑ちなみにOpenSDAのファームをCMSIS-DAPに入れ替えるとCoFlashが使えます。
●Versaloon+OpenOCDで使えるようにしてみる
FreeScaleの石といえどもコアがCortexM0+なのでSWDで引っ掛けるのはたやすいです。
先ずはマスストレージで書き込んだプログラムをOpenOCDとinsightでデバッグは問題
なく確認できました。ちなみにOpenSDAのSWDは切り離さずともVersaloonとつながる
ので基板パタンのカットなどの作業は必要なくSWDの線を引っ張り出すだけです。
次に書き込みですが…OpenOCDのkinetisドライバは現在KL25Lシリーズには対応して
いないのでLPC800の時と同じように自分で実装する必要がありました。
kinetisドライバはフラッシュ書き込みを行うのにRAMにプログラムを乗っけて一気に
書き込む方式と4バイトずつ書き込んでいく方式があります。これはkinetisの各モデル
で使用できる書き込み方式が決まっていてKL25では後者の"Program Longword"という
コマンドでしか書き込むことはできません。
幸いにもKL25シリーズはチップ固有IDがかなり細かいところまでわかるのでこれを
利用して既存のモデルの書き込みになるべく影響しないようにKL25の書き込みルーチ
ンを作りこんでいきました。
↓そして完成したドライバの書き込み結果がこちら
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/vsllink_swd.cfg -f target/kl25z_swd_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.7.0-dev-00159-g87668ae-dirty (2013-02-15-17:44)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : OpenOCD runs in SWD mode
none separate
Info : add flash_bank kinetis pflash
adapter speed: 1000 kHz
cortex_m3 reset_config sysresetreq
Info : Versaloon(0x15)by Simon(compiled on Feb 20 2013)
Info : USB_TO_XXX abilities: 0x0000076E:0x010001EF:0xC0000007
Info : clock speed 1000 kHz
Info : kl25z.cpu: hardware has 2 breakpoints, 2 watchpoints
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x21000000 pc: 0x000000cc msp: 0x20003000
Rize up to Internal PLLed Clock!
Info : Probing flash info for bank 0
Info : KL24/25Series Erase All Blocks
Info : Write to MCU security status unsecure
erased sectors 0 through 127 on flash bank 0 in 0.046875s
Warn : KL24/25 supports Program Longword execution only.
wrote 6676 bytes from file main.elf in 5.453125s (1.196 KiB/s)
verified 6676 bytes in 0.156250s (41.725 KiB/s)
shutdown command invoked
> Process Exit Code: 0
> Time Taken: 00:07
先にも述べましたが低速な"Program Longword"による書き込みは現状のkinetisドライバ
ではDAPを毎回叩いてﾁﾏﾁﾏホストPCから命令をおくっているため通信のオーバーヘッド
が非常に大きくなりMAX2kByte/Secくらいしか速度が出ませんorz
STM32みたくRAM上に小さいブートローダー流し込んでそこをデータの受け渡し場にして
アトミックに書き込みを行うようにしないとこれ以上速度は出ませんが私にそこまで技術力
ないのでこの辺で勘弁してあげましょう(泣
↑結局自分で実装しました！超快適です♥
↓ちなみにSTLink/V2でも当たり前のように書き込み・デバッグが可能です。
20130419追：重要!!!
STlink/V2 firmware version MUST upgrade to V2.J17.S0!
↓
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/stlink-v2.cfg -f target/kl25z_hla_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.7.0-dev-00159-g87668ae-dirty (2013-02-15-17:44)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
none separate
Info : add flash_bank kinetis pflash
Info : This adapter doesn't support configurable speed
Info : STLINK v2 JTAG v16 API v2 SWIM v0 VID 0x0483 PID 0x3748
Info : Target voltage: 2.894991
Info : kl25z.cpu: hardware has 2 breakpoints, 2 watchpoints
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x21000000 pc: 0x000000cc msp: 0x20003000
Rize up to Internal PLLed Clock!
Info : Probing flash info for bank 0
Info : KL24/25Series Erase All Blocks
Info : Write to MCU security status unsecure
erased sectors 0 through 127 on flash bank 0 in 0.046875s
Warn : KL24/25 supports Program Longword execution only.
wrote 6676 bytes from file main.elf in 5.078125s (1.284 KiB/s)
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0x20003000
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0x20003000
verified 6676 bytes in 0.062500s (104.312 KiB/s)
shutdown command invoked
> Process Exit Code: 0
> Time Taken: 00:05
まぁOpenSDAのマスストレージからの書き込みが使い勝手が非常に良いので書き込み
はMSCから、デバッグはVersaloon+OpenOCDと使い分けるのがよいでしょう。そのうち
kinetisドライバに手を入れてくれる人が出ると思いますから…ふふ
●FreeScale Kinetisシリーズを使う上で必ず守るべき事項
今回の記事はこの項を特に頭に叩き込んでおいてください。
知らずにやってしまうとｺﾞﾐにしてしまいます！！！！！
KinetisシリーズのARMマイコンはNxP系のARMマイコンと同じくフラッシュメモリの
特定の領域にMCUのコンフィグレーションが設定されています。
具体的に言うと0x00000400番地以降の16バイトが相当します。メーカお仕着せのツー
ルではこの番地にユーザープログラムを置かないように配慮されておりますがGCCで
一からプロジェクトを作り上げる人はこの番地はコンフィグレーション専用の番地と
してしっかり設定して置きましょう。具体的にどうやるかは私のサンプルを参考にし
てください。ついでですがメーカ提供のUARTドライバというかいろんなものがちょっと
出来が悪すぎるのでSTM32でも使ってるUARTドライバを移植してます。
話がそれましたが、一番気を付けるべきはフラッシュメモリの0x0000040Cから読みだし
設定されるFSECというレジスタです。ここの値の下2bit分が(00,01,11)の場合Secure
状態と判断されSWD経由のアクセスがある特定の操作を除いて一切不可能になります
(マニュアル73-74p参照)。…もうお気づきだとは思いますが、つまりは内蔵フラッシュ
メモリの２番目のセクタの消去orメモリ全消去の操作をしてアンプログラムド(すべて
のビットが1)にしてしまうとコードセキュリティが働いて以後のSWDのアクセスが特定の
操作以外は実質不可能になってしまいます！！！
おまけにSTM32やLPCマイコンでは可能だったシステムブートローダからの起動による
セキュリティ状態をキャンセルするという軟弱な救済措置は、KL25シリーズではシス
テムブートローダ自体が存在しないため不可能という非常に男気あふれる仕様となって
おります！！(注:工場出荷時は0x0000040Cに0xFEを書き込んで出荷されているため、
いきなり動作不能とかはないです)
唯一の解除方法はデバッグポートの下位のレベルの"MDM-AP Control register"に全消去
ビットを送り込んで(この操作を行うと全消去された後0x0000040Cに0xFEが書き込まれる)
で工場出荷時のフラッシュメモリの状態に戻すことです。ねむいさんが試したところで
はOpenSDAのマスストレージモードやCMSIS-DAPはこの操作を先に行っているようで、
わざと0x0000040Cが0xFFなプログラムとか書き込んだ後でもふつーに操作可能です。
幸いにもOpenOCD中のarm_adi_v5.cにはkinetisマイコンに対してローレベルでSW-DP
を叩くことができるコードが追加されています。ねむいさんはこちらにも手を加えて、
KL24/25シリーズでもこの復活措置を可能にしました。しかしながらこの操作はSRSTの
物理操作が必ず要求されるため、VersaloonにSRSTの線を追加するかもしくは手動
リセットでタイミングよく解放してやる等の小手先の技が要求されます。
秒単位の話なのでタイミングに慣れるとそれほどの事じゃないですが…
それと当たり前ですがarm_adi_v5.cを経由しないSTLink/V2やTI-ICDIのようなAPI召還型の
タイプのアダプタは直接SW-DPを叩けないためこの回復技は一切不可能なのでご注意を。
ちなみに0x0000040Cにはmass_erase許可ビットも4-5bit目に存在しており、"0xEF"と
書き込んじゃうとSW-DPを直接たたく全消去操作もできなくなってしまい完全にｺﾞﾐと
化しますので試合会場や展示場でライバルを制したいときに非常に有効な技です！。
ねむいさんが公開しているFRDM-KL25Z向けのサンプルプログラムとKL24・25シリーズ
に対応したOpenOCDはプログラム上でも書き込み時も0x0000040Cに0xFFにしてしまわ
ないように配慮を行っているので安心してお使いください。
あとは書き込み速度さえ何とかできればOpenSDAやCMSIS-DAPに頼らずともVersaloon+
OpenOCDの組み合わせだけでも幸せになれると思います。
ぱっちもここに置いてるのでだれか腕のある人続けてくだち…。
↑結局自分で実装しました！超快適です♥
LPC800シリーズを使ってみる2
-前回までのあらすじ-
OpenOCDで最初の1kByteしか書けなくてふてくされて他の事やってました。特に
いないさんの誕生日が近づいてきているのでそれの準備に虹裏メイドパワーを
お注ぎ申したり(もう製作完了しました！2月9日はこうご期待！)、副業先の引っ
越しに巻き込まれたり500mも移動してませんが住み家の引っ越しやらでいろいろ忙し
かったのですが、ちょっと落ち着いたのでOpenOCDのコミットを見るとLPC43xx系の
フラッシュありタイプの書き込みサポートがレビュー中状態で追加されていました。
気になって変更箇所見てみるとLPC800シリーズの書き込みにも関する大きなヒント
が見つかったので再びチャレンジしてみた次第です。
ゲームは一瞬で終わっていた…ユーザーマニュアルにちゃんと明記されてたorz
LPC812はLPC2000系やLPC17xx,LPC12xx,LPC13xx,LPC11xxx系と違いIAPスタックの
最大消費量が少し多くなるとの事です。少しの差が成否を分けていたようですorz
そいやvsprogのコードにもそんなこと書いてあったような…まぁいいです。
それをもとにちゃんとドライバを作り込むと拍子抜けするくらい簡単に書き込みが
出来るようになりましためでたしめでたし！
↓LPC812完全対応のOpenOCD+SWD接続のVersaloonで書いた時のメッセージです。
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/vsllink_swd.cfg -f target/lpc812_swd_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.7.0-dev-00151-g4a5c9a4-dirty (2013-01-31-19:33)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : OpenOCD runs in SWD mode
none separate
adapter speed: 250 kHz
cortex_m3 reset_config sysresetreq
Info : Versaloon(0x15)by Simon(compiled on Jul 18 2012)
Info : USB_TO_XXX abilities: 0x0000072E:0x010001EF:0xC0000007
Info : clock speed 250 kHz
Info : lpc812.cpu: hardware has 4 breakpoints, 2 watchpoints
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0xf1000000 pc: 0x1fff0008 msp: 0x10000ffc
auto erase enabled
wrote 2048 bytes from file main.elf in 0.499965s (4.000 KiB/s)
verified 1600 bytes in 0.109367s (14.287 KiB/s)
shutdown command invoked
> Process Exit Code: 0
> Time Taken: 00:01
↓SWDで繋がるということはもちろんSTlink/V2も使用できるということですね♥
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/stlink-v2.cfg -f target/lpc812_hla_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.7.0-dev-00151-g4a5c9a4-dirty (2013-01-31-19:33)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
adapter speed: 1000 kHz
none separate
adapter speed: 250 kHz
Info : clock speed 250 kHz
Info : STLINK v2 JTAG v16 API v2 SWIM v0 VID 0x0483 PID 0x3748
Info : Target voltage: 2.869535
Info : lpc812.cpu: hardware has 4 breakpoints, 2 watchpoints
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0xf1000000 pc: 0x1fff0008 msp: 0x10000ffc
auto erase enabled
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x10000004 msp: 0x100000c8
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x10000004 msp: 0x100000c8
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x10000004 msp: 0x100000c8
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x10000004 msp: 0x100000c8
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x10000004 msp: 0x100000c8
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x10000004 msp: 0x100000c8
wrote 2048 bytes from file main.elf in 0.343750s (5.818 KiB/s)
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x1000002e msp: 0x10000ffc
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x1000002e msp: 0x10000ffc
verified 1600 bytes in 0.062500s (25.000 KiB/s)
shutdown command invoked
> Process Exit Code: 0
> Time Taken: 00:01
STLink/V2のほうが若干書き込み速度が速いですか…！
でもLPC800系はフラッシュ容量の最大が16kByteなので特に気にならないかと
思われます…。
当たり前ですがいつも通りのデバッグもいつも通り可能です。
もちろんSTLink/V2でも自由自在に可能です♥
て訳でLPC812の書き込み・デバッグに完全対応したOpenOCDのバイナリとパッチを
公開します。OpenOCDのLPC812対応に関しては全世界でねむいさんが最初です！
あとは秋月さんがLPC810のDIP品を売ってくれるのを待つばかりですね〜♥
あ、ついでにLPC812-LPCXpressoのプロジェクトも更新してます。
おまけ
尺が余ったのでもう少し続けます。
先日ChaN'氏がFatFs0.09bをリリースしました。ドライブのボリュームラベルに対応
しています！ねむいさんもこちらの適用を進めてすでにおきぱにて対応済みのサンプル
を公開しています。今回の作業でSTM32VL,STM32Lでボリュームラベルを設定した時に
ディレクトリ構造が破壊される恐ろしいバグが自分のMMCドライバ側に眠っていたのが
判明したので何気に修正してます。
…ぇーっといままでwriteの方は放置してましたすみません！！
LPC800はぢめました(Versaloonを使ってLPC812に書き込み&デバッグを行う)
……ッッ
ギ ブ ア ッ プ orz
去年末に入手しVersaloon+OpenOCDで書き込みデバッグせしめることを頑張って
きましたがもうお手上げですorz
20130201追：
OpenOCDからも書き込みができるようになりました！！
さすが私！
と書き切ってしまうと今日のブログ終わっちゃうのでvsprogから書き込みを行う別の
突破口を見つけ成功しましたのでLPC812使用記を兼ねてお知らせします。
Cortex-M0+コアが使用されているLPC800系のペリフェラルのアーキテクチャはM0コアの
LPC1114系とは違う部分があります(USB付きだからかLPC11uxx系も全く違う)。
フラッシュメモリの構造もその一つですが、フラッシュサイズの上限が16kByteまでしか
無いLPC800シリーズではLPC11xx系とは比較すると以下のようにセクタ/ページサイズ
が細かくなっています。
*セクタサイズ
LPC11xx : 4kByte
LPC8xx : 1kByte
*ページサイズ
LPC11xx : 256byte
LPC8xx : 64byte
OpenOCDやvsprogに代表されるフラッシュ書き込みルーチンはLPC系のARMマイコンでは
JTAG/SWD経由でもIAPを召還して書き込みを実行する方式のため新たなデバイスの
対応に特段に難しい措置は必要はありません。
だから公式に対応してなくとも自分でセクタ/ページサイズの定義をちょちょいと追加して
やれば終了のはず…なのですがOpenOCDでは1セクタ目を書いた時点でHardFaultに
なってしまいアウチとなったのでしたorz
20130201追：
OpenOCDからも書き込みができるようになりました！！
さすが私！
しかしvsprogではあっさり成功してしまいましたので誰かがOpenOCDで頑張ってくれる
までは当分vsprogでLPC812に書き込みを行います。
↓書き込んだときのメッセージです。PN2のコンソール出力キャプチャに対応させる
ため、LPC800と直接関係ない表示系も少しいじってますのでご了承を。
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
vsprog -clpc812m101fdh20 -ms -I main.hex -oe -owf -ovf
VSProg 1.0 svn:1364M
CopyRight(c) 2008-2010 by SimonQian
URL: http://www.SimonQian.com/en/Versaloon
mail: SimonQian@SimonQian.com
Info: Versaloon(0x15)by Simon(compiled on Jul 18 2012)
Info: USB_TO_XXX abilities: 0x0000072E:0x010001EF:0xC0000007
Info: Target runs at 0.000V
Info: SWDID = 0x0BC11477
Info: AHB-AP_ID = 0x04770031
Info: ROM_ADDRESS = 0xE00FF003
Info: CFG = 0x00000000, Little-endian
Info: CORTEX-M0 r0p0 processor detected
Info: CPUID = 0x410CC600
Info: Bootloader version 13.1
Info: Chip-id read is 0x8122.
Info: erasing flash
erasing flash |========================================| 0.06s used
Info: flash erased
Info: SWDID = 0x0BC11477
Info: AHB-AP_ID = 0x04770031
Info: ROM_ADDRESS = 0xE00FF003
Info: CFG = 0x00000000, Little-endian
Info: CORTEX-M0 r0p0 processor detected
Info: CPUID = 0x410CC600
Info: programming flash
writing flash |========================================| 0.39s used
Info: flash programmed for 1600bytes(4.00KB/s)
Info: verifying flash
reading flash |========================================| 0.09s used
Info: flash verified for 1600bytes(16.80KB/s)
> Process Exit Code: 0
> Time Taken: 00:01
OpenOCDはフラッシュ書き込みはできないもののそれ以外のすべての操作はLPC11xx系と
同様に可能です。いつものInsightを使ったデバッグとI/OViewも自由自在です。
※STLink/V2もデバッグ可能です。
ということで少々セコ技ですがいつもの構成で開発環境が整ったのでLPC812Xpresso
用のプロジェクトファイルを公開します。
同時にLPC812に書き込み可能なvsprogのwindows用バイナリとLPC812のcfg入りのOpenOCD
も更新しました。vsprogと同じフォルダにはLPC800系対応のパッチがありますので興味ある
人は自分でビルドして試してみてくださいね。
でもどちらかというとねむいさんは
20130201追：
OpenOCDからも書き込みができるようになりました！！
さすがわた(ry
LPC4330を使ってみる3 -デュアルコアで動かす-
LPC43x0シリーズはCortex-M4FコアとCortex-M0コアが一つのチップに同時に存在する
"Heterogeneous"なデュアルコアSoCです。某巨乳女子高生雀士のiPS細胞に関する主張
を全面支持しているねむいさんにとってはヘテロは敵にあたるわけですが早くiPSが実用化
されていないさんに私の子供をﾊﾞｺﾊﾞｺ孕まｓ
…ぇーっと今回はLPC4330のM4コアとM0コアを連係させて動作させてみます。
LPC4330においてはM4コア側がMaster,M0コア側がSlaveの関係となってます。
パワーオンor外部リセット直後はM0コアはリセットしっぱなし状態になっておりM4側から
起こしてやることでようやくM0コアが走り始めます。
どっかの壺では全く逆のでたらめが書かれていますので注意してください。UM10503の
38pに"The IRC is selected as CPU clock and the Cortex-M4 starts the boot loader."と
明記され、さらに94pにもリセット後の各コアのステートが明記されておりますので必読です！
NxPのマルチコアのアプリケーションノートにも起動順がはっきりと明記されております！
嘘を嘘と見抜けないと(掲示板を使うのは)難しいってファラコのホテプ�言い気鵑盡世辰討泙垢掘�
他人の言うことをうのみにしないで自分の頭で考えて自分に最適な答えを導き出す
癖をつけましょう。
このM0コアのプログラムはどうするのかというとM4用のプログラムをビルドするときに
M0コアのプログラムをオブジェクトとして丸々取り込み、一つのバイナリとしてこさえる
必要があります。これを起動時に簡易なブートローダーでSRAM上にM0用プログラムを
転送して、M0コアのリセットを解除してやります。メモリ構成のイメージとしては下図の
ような感じになります。
また、M0用プログラムは0x00000000にシャドウされ実行するのでM0用プログラムは必ず
0x00000000から実行するようにビルドします。それに対してスタックポインタは実アドレス
を指定しなければなりませんのでご注意を。
M0用のコードはその存在意義上小さく作りこむ必要があるので32kbyte程確保しておけば
良いでしょう。今回の例としてはLocalSRAM2の0x1008000に置きましたが、LocalSRAM1
やAHBRAMにもプログラムを置くことができます。とはいえ両方のコアをSPIFI上ではなく、
SRAM上で動かさないと本来の性能は全く引き出せず、M0コアのことも考えるとますます
窮屈になってしまいますね。
やはりもう少しSRAM欲しかったな…204MHzでアクセスできるのが1MBくらい…。
↑M0用プログラムの転送後はM0用のベクタアドレスを設定するのを忘れないでください。
ここもスタックと同じく実アドレスを指定してください。
M4コアとM0コア間の通信方法は何通りもありますが今回は公式で配布してるサンプルに
倣ってSEV命令で各コアに割り込みを発生させて通知するようにしています。
↑写真じゃよくわかりませんですけどもデュアルコアで動いてます。
今回お話ししたGCCでコマンドラインビルド可能なプロジェクト一式はこちらです。
注意書きはしておりますが、M0->M4の順で必ずビルドを行ってください。
ついでですがOpenOCDのLPC4330-Xplorer向けのコンフィグファイルを少し変更しました。
外部リセット(SRST)を一切使わずリセット制御レジスタの操作で賄うようにしてます。
もともとSWD接続のVerasloonで使いたかったのでSRSTがないデバッガハードウエア向けに
外部リセットを操作しないでも使えるようにするのが目的でした…が、LPC4330がデュアル
コアでSWDは一つのコアにしか対応していないの忘れていました。結局JTAG接続専用に
なってしまいましたのでご注意を。
そもそもOpenOCDのspifiドライバがJTAG接続べったりの実装になってるのでぱっち当てるのめどいです
SPIFIブートにバグがあるLPC4330の動きを抑えるためのミソは以下の点です。
1.cortex-m3のリセット設定は"vectreset"にする。
2.srst/trstは"none"にする。
3.リセット信号の操作はRESET_CTRL0レジスタのCORE-Resetビットを叩く
具体的には0x40053100に0x00000001を書き100mSec程十分に待つ。
これは外部リセットとほぼ同じ効果を持ちます。
4.reset-init時にM0コアを確実にhaltさせるためにM0コアの
リセットを解除する。
具体的には0x40053104に0x00000000を書く。
これでやると外部リセットなくてもほぼうまくいきます♥
詳しい内容、使い方はlpc4330_xplorer_spifi.cfgと私のLPC4330向けプロジェクトファイルに
あるmakefileを熟読の上。
因みにspifiブートの時に外部リセットを2度かける必要がある理由は、(パワーオン時の)
リセット後の外部リセットでspifiのROMドライバにあるイニシャライズが必ずコケて暴走
するから(だからリセット後いきなりHardFaultしたように見える)で、その次の外部リセッ
ト操作ではそれがクリアされて再々イニシャライズが成功するからだそうですF**K!!!!
LPC4330を使ってみる2 -OpenOCDでSPIFI-SPIROMに書き込む-
先日秋月さんからもLPC4330-XplorerとLPC1830-Xplorerが販売されたわけですが、
ななんとデバッガハードウエアのULINK-MEもついて6200円ですって！本体+DHLの
送料合わせて1万ちかく払って半分壊れたのよこされた私はなんだったのか！？あと
たった2週間ちょっとまてばULINK-MEゲッツ出来たじゃないか！と悔やんでも仕方が
ないのでホビイストとしては手元にあるものを100%活用していこうと思います。特に大将
からご指名受けてしまい放り投げることもできないのですがFatFs実装はあつをさん
おねがいいたします(ﾊﾟﾀ
さて、LPC4330-Xplorer上ではSPIFIというインターフェースでマルチチャネルI/O対応
のSPI-ROMとLPC4330とが繋がっています。
LPC4330は起動オプションによりこのSPIFI-SPIROMから直接起動&プログラム実行&
リニアな参照ができるというなかなかニクい機能があるわけですが、内蔵フラッシュを
持たないLPC43xx・LPC18xxはどうにかしてこいつにプログラムを書き込まなければ
なりません。有効と思われる方法は以下の2通り。
1.付属のULINK-MEを繋げてKEILのIDEを使ってプログラムをSPIFI-SPIROMに書き込む。
↑ULINK-MEもってないので却下。
2.DFUブートローダー経由でSPIFI-SPIROMに書き込む
↑情報が出そろってませんがいずれ試します…。
RAM上には流せられるのは確認しました。
OpenOCDは実はSPIFI-SPIROMの書き込みにすでに対応していました。もちろん公式
にはコミットはされていないので自分でパッチ当て+再ビルド必須ですが、私の試行した
限りではいい結果を得られたので上述の確実な2通りに"もう一つ"追加したいと思います。
20120927追：
公式のコミットにも上がりました！
今回はこのOpenOCDを使った方法をご紹介します。
●その前にGCCでコマンドラインビルド可能なLチカるプログラムをこさえる
前回の時点ですでにOpenOCDにつなげて最初に書き込まれていたSPIROMの内容
のバックアップは取っていましたが自分でこさえたのをやっぱり書き込みたいよねと
いうことでいつもののLPC4330版を見据えたベース作りを行います。
LPC4330のSRAM+SPIFIの構成は以下の図のようになっています。
LPC4330コアの最大周波数204MHzでアクセスできるLocalSRAMは合計で200kByte
ありますがご覧のとおりアドレスは連続になってはおらず、128kByte・72kByte分で
ぶつ切りとされています(AHBRAMは構成的に64kByte分すべて連続アクセス可能です)。
SPIFIから実行した場合,104(MHz)/2(Byte)の読み取り速度のボトルネックがあります
ので見かけの動作速度は超大雑把に見積もって30MHz以下になっちゃいますが、ひと
まず一番単純な構成でプログラムも組み易いEXECUTE FROM SPIFIなメモリプラン
を構成しLチカプロジェクトを組みました。
…やっぱLocalSRAMはSH2Aみたく1MByteくらいほしかったなーと感じますね。これ
100PinのチップですからSRAMもSDRAMも外に引き出すのがまた面倒ですし。実際に
204MHzの動作速度を生かしつつ何か作ろうと思ったらプログラムは128kByte以内に
必ず納めてフォントやテーブルなどの比較的低速でもよい大容量データは全部SPIFI
にうっちゃる等の工夫が要求されるでしょう。
SPFI-SPIROM上動作版のリンカスクリプトの冒頭はこんな感じになってます。
●OpenOCDで繋げて書き込む
現在のOpenOCD0.7.0では公式のソースにSPI-ROMとNxP固有のSPIFIドライバのパッチ
をあてて再ビルドする必要があります。私のぶろぐ上で提供しているOpenOCDのWin32bit
版バイナリはこのパッチを適用しています。(下述の書き込みスクリプトも同梱してます)
今回使用するデバッガハードウエアはJTAGKey2Cloneとします。後述しますがLPC4330
のエラッタにより外部リセットの直接操作が非常に重要となるのでリセット(SRST)が使える
ブツが必須です。
それとお気の毒ですがULINK-MEはOpenOCDにハードウエアレベルで対応していない
ので、一切使えません(ファームを書き換えた初代ULINKだけ可能です)!
さて、いよいよSPIFI-SPIROMにプログラムを書き込みます。SPIROMの消去を含む操作を
するためにはFlashのプロテクト解除を必ず行う必要がありました。これを省くと書き込み時に
エラーを返されて失敗します。
↑20130814追：少し前のコミットで修正されました。
↓書き込み時のメッセージは以下のようになります。
書き込み直後にSRSTを直接操作して外部リセットを2度かけています。
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/ftdi/jtagkey2.cfg -f target/lpc4330_xplorer_spifi.cfg -c "mt_flash_bin main.bin 0x14000000"
Open On-Chip Debugger 0.7.0-dev-00001-ga4830e7-dirty (2012-09-24-10: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
cortex_m3 reset_config sysresetreq
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain
adapter speed: 2000 kHz
Info : clock speed 2000 kHz
Info : JTAG tap: lpc4330.m4 tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : JTAG tap: lpc4330.m0 tap/device found: 0x0ba01477 (mfg: 0x23b, part: 0xba01, ver: 0x0)
Info : lpc4330.m4: hardware has 6 breakpoints, 4 watchpoints
Info : lpc4330.m0: hardware has 2 breakpoints, 1 watchpoints
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x21000000 pc: 0x10000428 msp: 0x10091fe8
background polling: on
TAP: lpc4330.m4 (enabled)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x21000000 pc: 0x10000428 msp: 0x10091fe8
Info : Found flash device 'sp s25fl032' (ID 0x00150201)
cleared protection for sectors 0 through 63 on flash bank 0
auto erase enabled
wrote 65536 bytes from file main.bin in 1.062507s (60.235 KiB/s)
shutdown command invoked
Polling target failed, GDB will be halted. Polling again in 100ms
なんでわざわざSRSTを直接いじっているかというとLPC4330-Xplorerに乗っかってる
チップのリビジョンは内蔵されたSPIFI-ROMドライバがPOR後の外部リセットした後の初期化
で必ずコケて次の外部リセットで正常に動くというイミフなerrataに起因してます。
こいつのせいで今までうまくいった正攻法が全く通じずワークアラウンド満載な
書き込みスクリプトにせざるを得ませんでした。
まぁ結果的に安定したからOKということにしましょう。因みSRSTを繋げてなくてもSWD
接続のversaloonやSTLink/V2で書くことはできますが、この場合いちいち主電源を入り
切りする必要が生じ面倒です。
また、デバッグ中に変なステートに落ち込んでJTAGのアクセスが一切不能に陥ることも
あります。この場合はディップスイッチでブート方法を別の経路にして電源を入れ直すと
ひとまずJTAGで繋がるようになるので落ち着いてSPIFI-SPIROMの内容を全消去して
ください(その後はブート方法をもとに戻すのを忘れずに)。
●OpenOCD+Insightでデバッグ
最後の仕上げにOpenOCD+Insightでソースコードデバッグできる環境も作りました。
こちらもワークアラウンド満載でgdbにattachしたときにsoft_reset_haltをかけてプログ
ラムの先頭で停止するようなトラップを仕掛けてます。
SPIFI-SPIROM上のプログラムを直接参照できるのでとてもありがたいですね♥
もちろんいつものIOViewでGPIOのビットの状態も一目でわかります♥
ちなみにGPIOの初期設定の時にInputBufferを有効にしておかないとピンの状態が一切
読めませんのでご注意ください！(普通のプログラムでも引っかかりやすいポイントです)
●SPIFI-SPIROMからブートしてSRAM上で実行してみる
SPIFIから実行すると大幅にパフォーマンスが下がってしまうので実際に使えるレベル
で試用するならばLocalSRAMからプログラムを実行する必要があります。SRAMの構成上
プログラムと初期設定値があるデータと合わせて128kByte以内に収めないといけない
制約が出来てしまいます。したがって大容量のフォントorデータテーブル等はSPIFI
におきっぱにしておくべきです。
今回はPCと連携せずにスタンドアロンで起動し、SRAM上で実行できる環境を拵えます。
原理としてはきわめて原始的なブートローダをSPIFIに仕込む形になりますが、大まかに
いうと以下の流れで行います。
1.SPIFIのアドレス(0x14000000)からブート
2.Reset_Handlerに飛ぶ(けどアドレスはまだSPIFI上の0x1400****)
3.".text"〜".data"の領域までLocalSRAM(0x1000000)にコピー
4.PCをSRAM上に指定してジャンプ
5.BSS領域をゼロクリア・各種クロック・I/O設定
6.main()に飛ぶ
"4."の部分がミソなわけですが実際のアセンブラのコードを見てもらうと…
一見無意味なことしてるように見えますがその場(SPIFI上)でジャンプすると着地点が
LocalSRAM上になりそのままSRAM上で何事もなくプログラムを継続できる仕組みに
なるわけです。
もうお気づきの方いると思いますが大昔AT91R40807でやってたことと全く同じですね。
また、上記のからくりを実行するためにはbin形式でSPIFI-SPIROMに書いてやる必要が
あります。LMA/VMAの情報を保持しているelf・ihex形式だと失敗しますのでご注意を。
ということでLPC4330-Xplorerもこちらとこちらに準拠したビルド・デバッグ環境をこしらえ
ました。あとはどんどん上位層のプログラムを作りこんでいくだけです！
20121003追:
GCCビルド可能なLED点滅(シングルコア動作)プログラム公開します。
LPC4330はぢめました -まだLチカもできない-
積み基板どころか"詰み"基板になるのが分かっていながら人はなぜ、何故、同じ過ちを
繰り返してしまうのだろうか？
…しかしねむいさんはLPC1788にMCI版FatFsを移植を行ったので十分挑戦権があると
自負しています！日本のアマチュアでは今度こそ一番乗りで(あつさんがすでに触ってました…)LPC4330が
搭載されたLPC4330-Xplorerの使用感を報告させて頂きたいと思います！！
この基板インド製だそうですがもう時代は中華大陸飛び越えてインドですよインド！
さて、この基板はNxP社肝入りのCortex-M4F+CortexM0のデュアルコアが搭載された
最新のマイコンLPC4330が搭載されています。最大動作周波数はCortex-M系最高速の
204MHzに上り(M4,M0コアの両方とも)、クアッドSPIが使えるインターフェース"SPIFI"も
搭載されています。
USB-HSのPHYもLPC4330内に搭載しており(USB0のみ)、外付けHS-PHYも必要ありません！
もちろんねむいさんのいつものに必要なMCIインターフェースもあります！
んでもって基板の構成ですがSTM32F4Discovery宜しく音アプリを強く意識した構成と
なっていてAudio-CodecやEthernet-PHYも実装されています。さらに基板上にMicroSD
カードコネクタやSPIFI用のシリアルROMも乗っていてFatFsの移植も少しは楽になり
そうですね♥
さぁケーブル繋いで通電だー！と思ったのですが良く見るとコネクタがなんだか変…
写真分かりづらいですが無理やりねじこんだように金具の上側が微妙に曲がってます…
そして付属ケーブルの口見たらこんなになってやがりました…
注：最初からこんなになってました。ねむいさん壊してないですよぅ！
もちろん刺さりませんorz
もうﾅﾝ持ってｲｪｪと叫びたくなるのを我慢してさらに基板をよく見ると
手半田で修正した跡がありDIPスイッチが溶けてLEDが焦げてました…
もうﾀﾞﾌﾞﾙｵﾄﾞﾛｷですよねほんと印度クオリティすごいってまたひｔ
インドのNGXから直接購入したので修理交換の手間と金が非常にかかってしまうと感じ、
結局自分でコネクタ・LED他の付け替え修理を行いました。
LPC4330-Xplorerに実装されたmicroUSB-Bコネクタとほぼ似た形状の奴をtaobaoで購入
しており、スムーズに付け替えは完了しました。ちなみに秋月さんちで売ってるタイプの奴
はコネクタを挿す向きとピンの並びが逆のため付け替えができません！ご注意ください。
LEDの交換ついでに3.3VのLDOもMLCCが使用可能なZLDO1117に換装しておきました。
最初に付属していたUSBMicro-Bのケーブルは捨てて手持ちのを使います。
後はチュートリアルに従いVcomのドライバ入れて基本操作を確認しました。
NGXのチュートリアルにはUSB0サイドのUSBHIDデバイスは挿したらすぐに動くように
見られますがまずUSB1サイドをPCに刺し、その次にUSB0サイドをPCに刺し、最後に
SW2を押すとUSB0サイドのHIDデバイスとして認識されるようになります。
またSW2を押した後は仮想COMポート上で上画像のように各種チェックルーチンが
走るようになっています。
同時にEtherNetもアクセス可能です(192.1681.1.123固定なのでご注意下さい)
LEDの操作がブラウザ上から可能になっています。
最後にJTAGで繋いでみてOpenOCDからどう見えるか確かめてみました。
LPC4330-XplorerのJTAGコネクタがちいさ過ぎてTI-StellarisのICDI付属のケーブル
しかピッチが合うのなかったので、JTAGkey2Cloneの代わりに急遽これを使いました。
↓で繋いだ状態はこんな感じに…
openocd -s C:/Devz/ARM/OCD/tcl -f interface/ftdi/luminary-icdi.cfg -f target/lpc4350.cfg
Open On-Chip Debugger 0.7.0-dev-00001-ga4830e7-dirty (2012-09-10-17:57)
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 speed: 500 kHz
cortex_m3 reset_config sysresetreq
Info : clock speed 500 kHz
Info : JTAG tap: lpc4350.m4 tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : JTAG tap: lpc4350.m0 tap/device found: 0x0ba01477 (mfg: 0x23b, part: 0xba01, ver: 0x0)
Info : lpc4350.m4: hardware has 6 breakpoints, 4 watchpoints
Info : lpc4350.m0: hardware has 2 breakpoints, 1 watchpoints
確かにCortex-M4とCortex-M0のふたつのコアが見えてますね〜
ほんとに触っただけというかそれ以前のやっと修理したばっか状態なのでLチカ
すらも進んでませんが、豊富なサンプルをベースにいつものを作っていきます。
LPC1114を使ってみる3
こちらとこちらの記事に続いて通算3つ目のLPC1114についての記事です。
前回述べたとおり秋月さんよりLPC1114のDIP版が180円で販売されて私も購入しました。
"どうせLチカ(LED点滅の意)で終わらすんだろ"とお思いの方が大多数とは思います。
その通り私はDIP版LPC1114をLチカせしめてこの記事を書くためだけに購入しました！
と、すべてに対する防御壁作ったところで今日の本題に入ります…。
●DIP版LPC1114のいいところ
1.ブレッドボードに最適なDIP28Pinなのはいいのですが600mil幅という無駄な広さ
IOとかSRAM削ってる(後述)くせにこの広さって…"ほらDIPにするとこんな
無駄にでかくなっちゃうんだよみんな面実装の奴使おうね★"というメッ
セージなのでしょうか…
2.SRAMの容量がTQFP48Pin(面実装品)の物から半分に削られた
"TQFPパッケージは8kByteも使えるよみんな面実装の奴使おうね★"という
メッセージなのでしょうか…
3.I/OピンがTQFP48Pin(面実装品)の物からいくつか削られた
"TQFPパッケージはもう少しI/Oピンが使えるよみんな面実装の奴使おうね★"
というメッs もうええっちゅうに
LPCXpressoに乗っているLPC1114と違う点は上記DIP版はPowerProfileが追加された
第二世代のLPC1100Lにカテゴライズされる製品となってます。現在はLPC1100XLまで
ラインナップされています。
●Lチカる
基本的にLPC1114のソースコードがそのまま転用できますが、上述のとおりSRAMが
4Kbyteしかないのでスタックの値は要調整です。私の公開してるプログラムはMARYにも
対応してる(内部RCをPLLのソースとする)ので取り合えず定義をこちらにしてやればVCC・
GND・SWDIO・SWDCLKのたったの4本でOpenOCDから書き込み・デバッグできます。
(なぜかリンカスクリプトファイルを全くいじらず8kByteのままでもふつーに動きました…
STM32F107みたく隠しでSRAMあるのか！？）
が、
OpenOCDで繋がるってことはソースコード一行も書かなくてもGPIOくらいは動かせられる
(＝Lチカれる)ってことで早速やってみました。ブレッドボードすら使いません！１！
…ねむいさんただTCLの"スクリプト"組んだだけだからねCの"ソースコード"は一行も書
いてないy止めろ石投げるな
●LPC1114(DIP版)にプログラムを書き込む
注:2019年現在はこの方法は古すぎて通用しません！
私の最新のOpenOCDバイナリに同梱されている説明書きと対応MCUをよく読み
コンフィグファイルとコマンドを実行してください！
…さて、今度こそ真面目にソースコードビルドして出来たプログラムを書き込みます。
書き込む方法は何通りもあります。UARTブートローダー(ISP)を利用する場合はFlashMagicを
使って書き込む・ChaN氏のLPCSP使って書き込むという方法が、さらにSWD接続においては
LPCXpressoを使用して書き込みを行う詳しい方法がLynx-EyEDあつ氏から紹介されています。
私が紹介するのはおなじみのOpenOCDからSWD接続のVersaloonやSTLink/V2を使って
書き込みを行う方法です。OpenOCD0.6.0ではCortex-M0並びに一部のSWD接続可能な
デバッガハードウエアのサポートが進められています。
Versaloon使って書き込む方法はこちらやこちらを参考にしてください。
DIP版のはSRAMが4kByteしかないのでLPC1114ではなくLPC11U14(←SRAMが4kByte)
と思って書き込みしてやるとうまくいきます。
↑Versaloonで使う場合はlpc11u14_swd_flash.cfgを指定すれば終わりです。
次に、デバッガハードウエアとしてSTLink/V2を使う方法ですがこちらも手順は確立
されていてVersaloon並みに簡単に書き込み・デバッグが可能です。
今回はSTM32F0Discoveryにビルドインされた物をSTLink/V2として使用します。おそ
らくCQ出版系の雑誌記事では営業的な理由で絶対にお目にかかれない内容なので
私が紹介してる方法は貴重なものになるかと思います。
↑外部にSWD線・電源線を引き出す準備です。
↑
lpc11u14_stlink_flash.cfgを選択。
20130501追:
時代は変わり、STLink/v2以外にもベンダ提供APIが使えるデバッガが出来てきましたので
現在はlpc11u14_hla_flash.cfgに変更しております。
-f lpc11u14_stlink_flash.cfg から
-f interface/stlink-v2.cfg
-f target/lpc11u14_hla_flash.cfg
と読み替えてください。
20140829追：
さらに時代は変わりました。
HLA系のデバッガアダプタの使用例はこちらをご覧ください。
ねむいさんのぶろぐで公開しているOpenOCDバイナリはすでにこのコンフィグファイル
は含まれております。また、今回のDIP版LPC1114やLPC11U14等の少SRAMの品種の
書き込みに対応するためにlpc2000.cへのパッチは必須となりますが、ねむいさんの
OpenOCDバイナリはパッチ済ですので安心してお使いください。
20130314改変:
OpenOCDからSTLink/V2を叩く時のデバイスドライバはSTマイクロ提供の物を
そのまま利用可能です。逆に以前使用していたLibUSB(libusb0.1系)は廃止し
使用不可能なのでご注意を！
↓にSTLink/V2で書き込んだときに表示されるメッセージを置きます。
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f target/lpc11u14_stlinkv2_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.6.0-rc1-dev-00015-g47728f9-dirty (2012-08-29-17:12)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
1000 kHz
none separate
250 kHz
Info : clock speed 250 kHz
Info : lpc11u14.cpu: hardware has 4 breakpoints, 2 watchpoints
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0xc1000000 pc: 0x1fff0040 msp: 0x10000ffc
auto erase enabled
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x10000004 msp: 0x100000b4
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x10000004 msp: 0x100000b4
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x81000000 pc: 0x10000004 msp: 0x100000b4
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x10000004 msp: 0x100000b4
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x81000000 pc: 0x10000004 msp: 0x100000b4
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x10000004 msp: 0x100000b4
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x81000000 pc: 0x10000004 msp: 0x100000b4
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x10000004 msp: 0x100000b4
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x81000000 pc: 0x10000004 msp: 0x100000b4
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x10000004 msp: 0x100000b4
wrote 4096 bytes from file main.elf in 0.468753s (8.533 KiB/s)
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x100000e2 msp: 0x10000ffc
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x100000e2 msp: 0x10000ffc
verified 1580 bytes in 0.062500s (24.688 KiB/s)
shutdown command invoked
フラッシュメモリの容量が32kB程度なので速度もそれほど必要ないかと思います。
異なる会社間のツールが使用できるのか！？
そもそも出来たばかりの未知のチップに書き込みができるのか！？
否、出来る、出来るのだ！集中線のフォーカスが明後日の方向いてるけど！
20130427追:
↓うまく書き込みができない場合の確認事項↓
１.そんな結線で大丈夫か
->もう一度ターゲットとSTLink/V2のSWD信号がちゃんと繋がってるか確認！
そんな基本的なこと間違うわけないだろって奴に限って間違ってます！
２.そんなDiscoveryのジャンパ設定で大丈夫か
->STM32L/F4/F0DiscoveryにビルドインされたSTLink/V2はデフォルトでは
STM32側に繋がってます。ジャンパを必ず外しましょう。
STLink/V2はマルチドロップSWDに対応していないため通信がこけます。
３．そんなVtgtで大丈夫か(←これで引っかかる人多し!)
->V17以降のSTLink/V2のファームはvtgtをきっちり合わせないと撥ねられて
書き込みが失敗します。かならず接続しましょう。
STM32L/F4/F0DiscoveryにビルドインされたSTLink/V2ではVtgtからAD入力
に繋がる抵抗が未実装なので回路図をよく見て100ohmも必ず実装しましょう。
おなじみInsightを使用したデバッグ画面。I/OもIOViewも楽々操作です♥
上記の操作をすぐに試すことができるLPC1114DIP版も対応のプロジェクトファイルはこちらです。
ビルド手順はこちらを、デバッグ手順はこちらを参照してください。
DIPに対応するにはmakefileの定義を少し変えるだけでOKです！
●大事なことなので何度でも言います
最後に注意点ですが(これも過去に何度も何度も言及していますが)LPC1114を初めて使う
際は、NxP系のマイコンに存在するCheckSumValidationやCodeReadProtectionも考慮に
入れてください。詳しい解説は本家のユーザーマニュアルに譲りますが、LPC1114では
内蔵フラッシュからプログラムを実行する場合、下図のような構成にされるべきです。
基本的に"ActiveVectorRegion"のCheckSumValidationより少ないアドレスにある情報は
ほぼ固定値となるので(変わるとしたらスタックの頭を変えるときくらい)リンカスクリプト内
でも"KEEP(hoge)"で固めておくとビルドのたびにCheckSumの値を変える必要がなく非常に
便利です。LPCXPressoやmbedではCheckSum値は書き込み時に自動計算されて書き込
まれるのでユーザーは意識しないで済みますが、上記のことを知っておかないと素でビルド
した時にLPCXpressoで動くはずのプログラムが"動かない"と詰まる羽目になります。
(実際にはISPに飛んで行ってしまいます)
また、CodeReadProtectionも0x2FC番地という場所にあってこれを厳格に定義してしまうと
0xC0~0x2FBまでのフラッシュ領域が無駄になってしまいます。よってこちらもあまり変える
ことが無い".data"や".bss"等のSRAM領域の初期化ルーチンを決め打ちで置いてやるように
すればフラッシュ面積の無駄になりません。
私が公開しているプロジェクトのNxP系のマイコンはすべて上記の考慮をしておりますので、
AVRやPICから入られた方は、一度リンカスクリプトやスタートアップファイルをじっくりと読み、
どのように組むべきかを把握しておくとのちのちに役に立つでしょう。
あ、NuvotonのNUC120のこと忘れてた…
OpenOCD0.6.0を使ってLPC1114に書き込み＆デバッグする為のめそっど
20160311追：
もう4年前の非常に古い記事ですがアクセスがいまだに多いので補足します。
LPC1100(u系も含む)をOpenOCDで書き込み・デバッグしたい場合は、
ねむいさん謹製のcfgファイルlpc11xxx_swd_flash.cfgをお使いください。
現在はLPC1100系は上記のファイルですべてカバーできるようになっております。
上記cfgファイルを含むねむいさんがビルドしたOpenOCDのバイナリはこちら。
SWD接続が可能なデバッガハードウェアVersaloonは、STM32使いの人たちの間では
オープンソースでSWD接続が手軽に利用できる数少ない手法の一つとして重宝されて
いますが私のぶろぐにもコメントをよくいただいている竹本氏のVersaloonに関する記事が
2012年2月号のトラ技にて紹介され、さらに多くの注目が集まるようになりました。
ちなみに記事最後の参考文献の所でトラ技名物の誤植どころか段落が下の段落に
めり込んでめちゃくちゃになって肝心なURLがわからなくなってしまっているのですが
記事を書いた竹本氏は何一つ悪くないです。悪いのはチェックが毎回適当で誤植や検証
もせずにいい加減な記事のせてるCQ出版のほうなんですから！！１１！(憤怒
野獣と化したカンガルー先輩に喝入れ直してもらった方がいいと思います。
いちおう丁寧に文章がぐちゃぐちゃになってる箇所をご指摘して差し上げたのですが、
もちろんお詫びと訂正には反映されませんでしためでたしめでｔ…たくねぇ！
はぁはぁ…すみません話逸れ過ぎました…。NxP社のLPC1114に代表されるCortex-M0系
デバイスはデバッグ用ポートにJTAGはなくSWDしか存在しません。おまけにOpenOCDの
Cortex-M0系コアのデバッガの実装はSWDしか接続方法がないゆえに手が入っておらず、また
またおまけにCortex-M0系コアの実装がまだ不完全ゆえにフラッシュ書き込みルーチンも
不完全と３重苦となっています。しかしながらCortex-M0系のコアはCortex-M3系コアのサ
ブセットなのでほんの少しの箇所の変更で何とかできるようになります。
また、当たり前のことですが多くのCortex-M0デバイスはSWDしか存在しませんので
SWD接続が可能なVersaloonもしくはSTLink/v2必須です
20120712追：
公式でCorte-M0がサポートされるようになりました♥しかしワークメモリが少ない
LPC11U14はopenOCDのビルド時にフラッシュ書き込みのソースにパッチを当てる
必要があります。こちらの手順をご覧ください。
以下の話はVersaloon対応のOpenOCD(0.6.0)がビルドできる環境&ビルド時の多少の
トラブルを回避できる能力を持ってる人対象です！ここでようやく本題！
●LPC1114(Cortex-M0系)専用のOpenOCDを作る
１．先ずはノーマルで動作を確認
gitからとってきた新鮮なOpenOCDのコードにVersaloonのパッチを当ててビルド、
LPC1769やLPC1343にSWD接続で繋がりフラッシュの書き込み/デバッグが正常に
できてるかチェック。問題があれば不具合のないコミットまで巻き戻そう！(逃
2012/01/26現在は私はこれで動作確認しました。あと最近のコミットはSTM32F2/4
系で大バグが作りこまれていますが後述
２．ソースコード修正
openocd/src/target/cortex_m.c内の2025行目あたりにある下記の内容
/* Cortex-M3 has 4096 bytes autoincrement range */
armv7m->dap.tar_autoincr_block = (1 << 12);
を
/* Cortex-M0 has 1024 bytes autoincrement range */
armv7m->dap.tar_autoincr_block = (1 << 10);
に書き換えて再ビルド。
これでLPC1114(Cortex-M0)専用OpenOCDができました。めでたしめでたし。
この中にも上記修正他をまとめたcortex_m0.patchがあります。
３．といいたいところですが
OpenOCD+VersaloonでLPC1114を動かすための特別なスクリプトファイルを用意する
必要がありますね。既に私がフラッシュ書き込みルーチン付きのものを用意しているので、
こちらを使ってくださいね。
ただ注意すべき点は、私も過去に何度も述べてきたNxP系のARMマイコンに存在する
CheckSumValidationです。LPC1114もご多忙にもれず"calc_checksum"を付与して自
動計算した値をフラッシュの所定の番地に書き込んでおかないとユーザプログラム
が実行されずISPの番地に勝手にすっ飛んでしまいます(calc_checksum付けなくても
前もって計算結果を埋めこんどいてもよいです)。
これはmbed等のクラウド環境から離れ初めて地に降りた時"動くはずのプログラム
が動かない"とよく引っ掛かるポイントです。ねむいさんクラウドよりもセフィロス派なので
mbedはとんと興味ないのですが大事なことなので何度でも言います。
４．LPC1114以外のCortex-M0のマイコンでは可能か？
LPC1227:
->できるじゃない！
同じCortex-M0系のLPC1227も書き込み&デバッグが可能です。しかしLPC1227は
リセット直後はウオッチドッグがONになっているせいかデバッグが途中からに
なってしまいます。うまく動く組み合わせを検証中です。
20120210追：
OpenOCDでattachした直後に一旦ISPのアドレス(0x1FFF0000)に飛んでから
実行するとmain関数の先頭で停まるようになりました！
このスクリプトファイルは公開しております。
LPC11U14:
->できるじゃない！
LPC11U14はフラッシュ書き込みに必要なワークメモリの最小値がどうしても確保
できず、書き込みはできませんでした。フラッシュメモリの消去のみと別な方法
でフラッシュに書き込んだ後デバッグ動作はできます。
20120530追:
LPC2000.c内のマイコン内ワークメモリアロケ―ターの下限値を下げることに
より書き込みが可能なことが分かり、パッチに反映しています！
STM32F0:
->余裕でできるじゃない！
NuvotonのNUC120はvsprogのほうは対応されたのでOpenOCDももうすぐでしょうね♥
尺が余ってしまいましたので小ネタをいくつか
●最近のOpenOCD(0.6.0dev)でSTM32F2/F4系のマイコンにつないだ瞬間に
OpenOCDがセグメンテーションフォールトする
とあるコミットからFlashSizeRegisterなるメモリアドレスにSTM32F2/4系の固有値と
して書き込まれているらしい内蔵フラッシュメモリの実サイズ値を読みだして設定
するという実装に代わっていますが…こいつがでたらめな値を引っ張ってきて設定
しやがるため即ひでぶしやがります…。
"私の環境では問題ないです"とおっしゃられてる方もそういわずに100kByte以上の
バイナリ作って書き込んでみてください。おそらく最初に作りこんだときにLED点滅
するだけのような10kByte以下のバイナリのサイズでしかチェックしてなかったので
ひでぶを免れていただけだったのでしょう。
なんでこんな変なことしてるんだろうと思ってSTM32F4のリファレンスマニュアル
(Doc ID 018909 Rev 1)を参照すると…
先ず0x1FFF7A10に各チップごとに固有のuniqueIDがあって
次に0x1FFF7A10に16bitサイズのFlashSizeがストアされたれじすｔ…
…アドレスが被ってる!?
なんかドキュメントが変ですよこれ！？
てわけでねむいさんの虎の子のOpenOCD+InsightでSTM32F407ZGT6(RevY)に接続し
該当するメモリの付近を捜索してみましたが…
…アドレス0x1FFF7A22に0x0400(1024kByte)が見える…
これが本物のFlashSizeRegisterかしら…
念のため手持ちのSTM32F2/4系のマイコン片っ端から引っ張り出してアドレス
0x1FFF7A22の値調べてみました。私の手持ちはすべて1024kByteの品種なので、
このアドレスが真のFlashSizeRegisterならば全部0x0400(1024kByte)にならな
ければなりませんがはてさて…
STM32F207VGT6(ES) :0xFFFF
(現在のOpenOCDの実装は0xFFFFだと1024kByteを想定して書くのでセーフ)
STM32F207ZGT6(RevY) :0x0400
STM32F407VGT6(RevA) :0x0400
STM32F407ZGT6(RevA) :0x0400
…ビンゴかよ…ES品の207VGT6は仕方ないですが。
とりあえずOpenOCDとSTMicroの中の人にメッセージ投げときましたけど気づいて
くれるでしょか???だめだったらフォーラムにも。
20120214追:
STから問い合わせ結果返ってきました。やはり0x1FFF7A22が正しいです。
リファレンスマニュアルも後日差し替えしますとのことです。
また、OpenOCDのほうも対応してくれました。
●aitendoさんのTFT-LCDモジュールを使う
そうだよまただよ
こっちとこっちは至ってごく普通のモジュールなんですが、TFT2P0327-Eのほうは
Vledが3.2VtypではなくLED2個直列つなぎの6.2Vなんです…データシートが3.0~3.4
って書いてあっておもいくそ間違ってます。まぁチャイナクオリティ(ry
といいたいところですけどねむいさんが買った3つがたまたまTFT2P0327-Eにくり
そつの別のLCDモジュールだったかもしれませんし大陸系の店は何があるかわから
ないんですけど買ったの今のところ私だけみたいですからまぁいっか…
半透過式の液晶なので視野角が広く太陽光下でもそれなりに見える代物らしいです
LPC2388向けのデモを整備しました
5月の末、STM32F207V/ZGT6を夢中でいじっていた折に、がた老氏からLPC2388向けの
プログラム、とくに割り込み動作について質問をいただきました。
LPC2388については、TFT液晶表示プログラムだけは更新を続けていてそのほかは去年
の1月以来放置状態でしたので、動作チェックがてら更新してみようかとおもっていたら
おもいくそはまったので顛末を記録しておくことにします。
起：Thumbモードで割り込みが動かなくなっていたことに気づいた
まずおかしいと気づいたのがこれで、FreeRTOSとは関係なしに最新のCodesourceryG++
ではThumbモードでコンパイルした場合、ユーザーモードから割り込み許可するために
SWIかましたら先に進まなくなっていたことが判明。ARMモードでビルドしたり動作確認
した１年くらい前のCodesourceryG++のVerでは正しく動いていたのでこのときはコンパ
イラのバグかとおもって放置していました･･･。
承：FreeRTOSのデモもうごかなくなっ(ry
がた老氏はFreeRTOSからRTC(と割り込み)を動かすこと画策されていて、私の公開
していたFreeRTOSV6.0.1向けのデモとBare-Metalなprintfのプログラムを参考にされ
ていました。しかしビルドが通らなかったとのことで、どのファイルをインクルードもしく
は定義すべきかを伝えて私もちょっくら確認しますかとおもって最新のCodesourceryG++
を使用しARMモードでビルドして書き込んでみるとなんと動かなかった･･･。
そもそも公開した当初は｢とりあえずこれなら動く｣状態だったため、Keilのデモや
Marthin'thomas氏やChan氏のプログラムやらが全部まぜこぜになっていて一年放置
後の私が見ても何がどうなってるのかよく分からない代物になっていました。
実はほかの方からもちらほらそういう質問いただいていたのですが、これはまずいと
思い立ちこの時点でやっとこ大規模な回収改修をすることにしました。
転：スタック領域のアラインメントを8バイトずつにあわせる
動いていたころのVerは"Sourcery G++ Lite 2009q3-68"でしたが20110630時点で手に
入る最新のものは"Sourcery G++ Lite 2011.03-42"です。このVerはGCC4.5.2になって
いてLinkTimeOptimizationというリンク時に最適化を行う機能が利用可能となっています。
また。どちらもABI(Application Binary Interface)はEABI(Embedded ABI)となっていますが･･･。
よくよく調べてみるとEABIはスタック領域のアラインメントを8バイトにそろえるべし。
と記述されていました。audin氏もこの件について触れています。さらにFreeRTOSの
フォーラムにもこの件についてのやり取りがありました。
(audin氏は.ARM.exidxと.eh_frameにも触れられていましたがそちらは幸い回避済でした。)
私のリンカスクリプトを調べてみると.stackがalign(4)になっていました。あらら。
てわけでこちらは修正。
この時点でARMモードでFreeRTOSのLED点滅のみの簡単なプログラムは動くようになりま
したが、FreeRTOS上で割り込みがいまだ動かない･･･。
結1：FreeRTOS上においての割り込みを正しく記述する
Sourcery G++ Lite 2009q3-68では割り込みまわりは結構いい加減でも問題な
かったのですが、Sourcery G++ Lite 2011.03-42だと以下のようにしないといきなり動かな
かったり、また動いてるように見えても10sec程度で止まったりでまともに機能しません。
↑UART0を例にとるとUART0の割り込みハンドラのwrapperを作り
割り込みがかかるとまずwrapperに飛ぶようにします。
↑UART0のヘッダファイル内で上記画像のように定義してやる必要があるみたいです。
がた老氏は最終的に自力で上記の解決方法を見つけられたようで、私ももう少し調べて
から的確な返事をすべきだったと反省してます。同じくおきばやリンク張ってるけど
放置状態のものも最新のコンパイラでビルド/動作できるようにしておくかもしくはばっ
さり削除することをしないと後に続く人を混乱させて無駄な時間を喰わせてしまうことに
なってしまうのでこれから先はこまめに対処していきますね。
結2：Thumbモードでふたたび割り込みをうごかす
"Sourcery G++ Lite 2009q3-68"では問題なかったので気づかなかったのですが、本来な
らばタイマやUART等の割り込みのハンドラがあるCのファイルは必ずARMモードでコン
パイルすべきだそうで、それを守ってmakefile内でARMモードでコンパイルするファイルを
明示してやるだけでよかった。･･･はずでしたが-fltoのオプション効かせてるとやっぱり
エラー吐いてビルドがとまったりビルドできても動かなかったりでmakefile内でThumb
モードを指定している時は-fltoのオプションを除外するようにしました。これで"Sourcery
G++ Lite 2011.03-42"でビルドしても大丈夫となりましためでたしめでたし。
ていうか自分で注意書きかいててすっかり忘れていましたorz
結3：ほかのLPC2388向けのプログラムもレストアする
て言うわけでコンパイラじゃなくてねむいさんが悪いのが分かったので最低限おきばで
公開してるのは最新化しておきました。
特にLPCUSBを使用したMassStorageClassはChan氏のMCIドライバを連結し転送速度
UPに成功しました！
58MByteのファイルを読み出し
58MByteのファイルを書き込み
以前は0.1MB/s、がんばっても0.2MB/sくらいだったのですが書き込み0.4MB/s、
読み出し0.5MB/sに！さらにArai氏のLPC1768向けLPCUSBの改修例を参考に最大4GByte
までしか認識できなかった容量も私の手持ちのSDカードで最大容量16GByteのものが認識
できるようになりました。
STM32Primer2のデモも同じような理由で最大4GB制限があり、今回対処法が分かったので
修正しました。
LPC1769を使う4
※トレランの記事を書く予定でしたがLPCXpressoLPC1769版が手に入ったため次回！
先日から騒がれはじめていますが、LPCXpressoのLPC1768版にLPC1769が乗っている
ものがある。という話。実際に市場に出回っているのはすでにLPC1769のものに置き換わり初
めているようです。ねむいさんもLPC1769版をゲッツしました！！
↑ご覧のように"TARGET LPC1769"と明記されているので安心です♥
↑LPC1768版で問題だったRTC用のクロックがピンコ立ちになってた件は今回のLPC1769版
ではちゃんとSMDの製品にかわりスマートな形状に戻りました。
1768版買わずにずっと我慢してた甲斐があったぜ…
さて、LPC1768とLPC1769の違いですが、単にクロック動作上限が100MHz->120MHzに変わ
っただけです。チップリビジョンも"-"の無印なのでエラッタもごっそり引き継いでいます。
細かい部分は各自エラッタシートをご参照ください。
以前に別基板で120MHzにて動作実験を行い、aitendoさんのOLEDを動かすパフォーマンス
とかもやってますが、今回もLPCXPresso1769版でおさらいをしてみました。
↑お約束で真っ二つに切断。
LPCLinkとかLPCXpressoIDEとかはもちろん一切使いません。
いつもの通りCodeSourceryG++とmakeとVersaloonとinsightを使えば十二分に戦えます！
ところでLPC1114/LPC1343版ではフリースペースになっていた部位はLPC1769版ではI/Oピン
が出ています。このピン群の扱いは当面何も付けないでおいてあとあとどうするか考えます…。
とりあえず秋月のロープロのコネクタを両サイドに取り付けました。
↑二つに割ってしまったせいで+3.3Vの供給のことすっかり頭から飛んでましたorz
仕方ないのでVersaloonの3.3Vから拝借。他者の製品同士が合体してシュールですね…。
↑Versaloon+VSGUIでSWDが繋がるのとOpenOCD立ち上げてLED点滅プログラムがSWDデバ
ッグ出来るのを先ず確認。
↑次にいつもの如く液晶表示とかやってみるのですが、今回はSPI接続専用で128x160pixel
なTFT-LCDを使ってみました！コントローラICは皆さんもおなじみのST7735です。
↑表示周りは完全にモジュール化させてるのでデバイス依存部以外はほぼコピペです。
120MHzまできっちりまわせよ(某豆腐屋みたいな顔で)
…そういえば5か月くらい前に中華LPC1769基板をいぢっていたような…気のせいか…
前回と全く同じことをしているような気がするわけでもないかもしれなくもない…
LPC1769にはまだFatFs積んで動作確認させた実績ないので早急にベースを固めなけれ
ばなりませんね。
LPC1343はぢめました(+Versaloonを使ってSWD接続でOpenOCDデバッグ)
8/16日にARMマイコン パーフェクト学習基板なるものが販売されました。基板に搭載されて
いるマイコンはLPCXPresso(LPC1343版)とおなじLPC1343です。
奇しくもLPC1114・LPC1769の開発環境のとっ掛りが出来たので死蔵していたLPC1343も
はぢめて見よう か な とおもって手を出してみました。決して便乗ではありませんよぅ！
肝心かなめのスタートアップはLPC13xx系がCortex-M3なのを利用してSTM32で使用した
ものとほぼ同一のものとしました。NxP系ARMマイコン特有のCRP&CheckSumValidation
ももちろんスタートアップに盛り込みます。
また、LPC1343にはUSBインターフェースがあるのでXPresso基板にUSBminiBコネクタ
から+5Vを引けるようにし、とある1.5A/3.3Vレギュレータでシステム全体に3.3Vを給電する
ようにしました。SMDだしセラコン使えるし秋月で買うとかなり安値で買えるし性能高いし
で良いLDOだと思います。
え？秋月のはセラコン対応じゃないのになんでデータシート無視して使ってるのですって！？
…さぁ？…誰かがなにかを間違えてるんじゃないかなぁ…？ほら型番とか…
↑ねむいさんは画像掲示板の住人なので画像で語る
それはさておき基板単体で給電できるようになったので、次はフラッシュの書き込み&デバッグ
に挑戦です。使用するのはSWD接続なVersaloonです。LPC-Link?何スかそれ？
LPC1114ではまだeraseしかできずあまり期待してませんでしたが、LPC17xx系と同じように
OpenOCDからSWD接続でフラッシュ書き込みを行うことができました…これは…ありがたい…！
あとはLPC11xx系のフラッシュ書き込みに対応してくれたら…！
20120229追:
JTAGが無いって言われた時にぃ、じゃぁLPC1114でもSWD接続のOpenOCDつかって
フラッシュ書き込み&デバッグできるじゃない！って確かそういった気もするんですよね
先ずはいつものLED点滅からです。邪魔なうんちゃらLinkはもちろんぶった切ってます。
SWD接続なVersaloonでOpenOCD+Insightによるデバッグ中の画面です。ペリフェラルは
LPC1114の時と同じくaudin氏のOpenOCD用IOViewをLPC1343向けに移植しました。
もうLPCXPressoIDEなぞ要りません。
というわけでLPC13xx系の開発環境の足場作りも整いました。これをとっかかりにして
色々広げていきたいと思います。
ところで、LPC11xx,LPC13xxはフラッシュ容量が32kBしかないので外部に何か容量の超
でかいROMをぶら下げる必要があります。いま私が記録媒体としてターゲットにしているのは、
少し前になひたふ氏も触れられていたSSTの大容量SPI-ROM(手持ちはSST25VF016B)です。
これは現在一般PC用のBIOSROMとして超大量に流通し、使用されているのでmouserや
digikeyでも安価に購入できるようになっています。
こいつに自在にデータを書き込めるようになったらPCのBIOSアップデートに失敗しても
もうなにも怖くはありません！！(←実はこれが主目的)
兎にも角にもSPI-ROMを使いこなすのだッ！
↑接写できるコンデジに買い替えたのでむやみに接写
…駄目だ上手く撮れない
追：おきぱを改修しました。
それに伴いSTM32F107VCT6,LPC2388用のTFT表示プログラムも最新に更新しています。
LPC1769を使う3
mbedやLPCxpresso,Arduino等の圧倒的な利点というのは、ベースとなるハードウエアが
共通かつ基礎的なアプリケーションフレームワークがおぜん立てされているという点で、
他の方が作られたすぐれたアプリケーションを手元で誰でも簡単にすぐに追実験できる
ということに尽きると思います。
1年前はまだまだ秘境だったARMの分野の裾野を一気に広げたというのは賞賛すべきこ
とだと思いました！一方、情(に)弱(い)ねむいさんは足しか出ていないような中華LPC1769
基板をひたすらどうにかしていた…。
超高速なIOを利用して件のSPI接続可能でQVGAな液晶をSoft-SPIで…。SPIバス接続して
さらにDMAでぶん投げられたらもっと早くなるでしょう。
さて、先日NxPのサイトにてLPC17xx用のペリフェラルライブラリがアップデートされました。
こちらを元にテスト段階のLPC1769の環境も固めていきたいとおもいます。
このライブラリはGCC向けにはCodeSourceryG++の使用を前提としてスタートアップ・
リンカスクリプト・etcが用意されています。LPC13xx,LPC11xx系はほぼ自前でこさえま
したがせっかくなのでLPC17xx系は豊富なメモリ資産があるのでCodeSourcery提供のも
のを積極的に使用していきます。
で、注意しなければならないのがそのスタートアップ等なのですが、そっくりそのまま使う
人はべつにどうということはないのですが私のようにCRPの記述入れてたりChecksum
Valitdateを直打ちな人は不整合が起こらないようにしなければなりません。あと見落と
しづらいのがdataやbss領いｋ(iruka氏が分かりやすく解説してくれてますので省略)
んでもってaudin氏に尋ねられた浮動小数点演算でハングする件をちょっと試してみました。
冒頭のカワウソ画像に見える浮動小数点演算の結果はsprintf(書式は%f)+FONTXドライバの
文字表示で表示していますが、NxPのLPC17xxのライブラリのGCC向けで使用されているCodeSourceryのスタートアップ(CodeSourcery Common Start-up Code Sequence (CS3))
を使うとsyscalls.cというかsbrkを作り込まなくてもふつーにsprintf関数とか使えました。
しらんかった…。ということで私の環境では浮動小数点演算ＯＫでした。
そろそろベースも固まってきたことですからLPC1769用のとっかかりプログラムも更新するつ
もりです。またaudin氏がOpenOCD+Insightから利用できるIOビュー画面機能を実現する方法
を公開されていますのでこちらもありがたく使わせてもらいます！
今日はもう一件、どちらかというとこっちの方が重要な事柄なんですけどVersaloonで使用で
きるSWD接続なOpenOCDデバッグがまだ制限付きですがLPC11xx,LPC13xx系でようやく
出来るようになっています！
LPC1114,LPC1343はJTAG接続というものが存在せず、SWDでしか接続できません。
OpenOCDが0.5.0に上がるのを機にSWD接続も対応になるとのことですがそれに先立って公開
されていたパッチを適用してデバッグを試してみました。
↓フェイクじゃなくてマジもんです。SWD接続に使用したデバイスはもちろんVersaloon。
キャプ画像見てもらったら分かるともいますが、audin氏のIOView機能をLPC11xx系に
適用して、ビット単位でGPIOのポートを見れるようにしています。コレめちゃくちゃ便利すね…!
もうLPC-LinkとかLPCXpressoのIDEとか必要ですらないです…これで勝つる！！１！
…と言いたいところですがデバッグは問題ないですがOpenOCDからのフラッシュメモリ操作
がまだLPC11xx系には完全対応しておらず(LPC13xx系は普通に使えること確認しました！)、
eraseしかできません。
まぁvsprogがあるので書き込みはこっち使っておいて正式対応までちょっと我慢です。
↑おまけ。LPC1114の基板に改造加えてEtherPodっぽくしてみました
LPC1769を使う2
※連日の猛暑で頭がたいぶ湧いてます。この段落は読み飛ばしてくだち
8月2日はぱんつの日でしたね…♥ぐふふ…♥
訓練されたとしあき君や｢｣ならモザイク掛けても緑と黒と肌色の配色でいなちゃんだっｔ
ぇっとこれは3.2インチの240x400液晶モジュール(aitendoさんのとは別の品)なんですが…
taobao経由で買ったこれは御多分にもれずユーズド品でいきなりLEDがブッ壊れてたり
タッチパネルの内部配線が断線してたりで3つ購入したたうち1つしかまともに動かんorz
さて戯言はここら辺にして、前回少し触ったLPC1769のボードの続きをやってみた
いと思います。今回は100MHz動作から120MHz動作に変更して動きを確かめてみます。
動作周波数(=CCLK)の変更はLPC2388の時と同じくPLLレジスタをいじって目的の倍数に
設定してやればよいです。LPC1768のCMSISライブラリのPLL周辺の初期化コードが値
決め打ちで書いてあって分かりずらいこっちゃないってことで少してこずりましたが
ユーザ・マニュアル片手に120MHz化できました。
LPC1769はUSBのクロック生成専用にもう一つPLLがあって、なおかつメインのPLLから
も従来通りUSBクロックが設定可能という柔軟な対応ができるようになってました。
てわけで120MHz動作にしたLPC1769でGPIOの単純なトグリングしてみました。
ﾔﾀﾞ超早い…♥
100MHz動作のLPC1768(mbed等)を想定した場合はこんな感じ。
波形汚いのはご容赦を。
以下はCodeSourcery G++(GCC4.4.1)のOptimize-2でコンパイルして吐かれたアセンブ
ラリストの一部抜粋です。
〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜
LPC_GPIO1->FIOSET = (1<<28);
3dc: f2c2 0309 movt r3, #8201 ; 0x2009
3e0: f04f 5280 mov.w r2, #268435456 ; 0x10000000
(↑最初に必ず入る)
3e4: 619a str r2, [r3, #24]
LPC_GPIO1->FIOCLR = (1<<28);
3e6: 61da str r2, [r3, #28]
LPC_GPIO1->FIOSET = (1<<28);
3e8: 619a str r2, [r3, #24]
LPC_GPIO1->FIOCLR = (1<<28);
3ea: 61da str r2, [r3, #28]
LPC_GPIO1->FIOSET = (1<<28);
3ec: 619a str r2, [r3, #24]
LPC_GPIO1->FIOCLR = (1<<28);
3ee: 61da str r2, [r3, #28]
LPC_GPIO1->FIOSET = (1<<28);
3f0: 619a str r2, [r3, #24]
LPC_GPIO1->FIOCLR = (1<<28);
3f2: 61da str r2, [r3, #28]
・
・
・
〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜
Cortex-M3はフラッシュアクセスがゼロ・ウエイトの場合かつロード・ストア命令が連続する場合
Rx,[Ry,#imm] は、常に1サイクルになるので(Cortex-M3マニュアル参照)、ゼロ・ウエイトで
動作が可能でなおかつGPIOがAHBバスにぶら下がっているLPC1769はGPIOのトグリング
周波数がMAX60MHzまで出るということですね。
ちなみにLPC2388の場合は同条件でARMモードでコンパイルした場合、以下のように
展開されました。もちろんLPC2388のFIOのアクセスです。
"DISPLAY_CONTROL_CLR = CTRL_WR;"の部分は
FIO4CLR1 = (1<<1);
FIO4SET1 = (1<<1);
に読み替えてください。
〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜
DISPLAY_CONTROL_CLR = CTRL_WR;
61c0: e3e03103 mvn r3, #-1073741824 ; 0xc0000000
61c4: e2433c3f sub r3, r3, #16128 ; 0x3f00
61c8: e3a02002 mov r2, #2
61cc: e5432062 strb r2, [r3, #-98] ; 0x62
DISPLAY_CONTROL_SET = CTRL_WR;
61d0: e5432066 strb r2, [r3, #-102] ; 0x66
DISPLAY_CONTROL_CLR = CTRL_WR;
61d4: e5432062 strb r2, [r3, #-98] ; 0x62
DISPLAY_CONTROL_SET = CTRL_WR;
61d8: e5432066 strb r2, [r3, #-102] ; 0x66
DISPLAY_CONTROL_CLR = CTRL_WR;
61dc: e5432062 strb r2, [r3, #-98] ; 0x62
DISPLAY_CONTROL_SET = CTRL_WR;
61e0: e5432066 strb r2, [r3, #-102] ; 0x66
DISPLAY_CONTROL_CLR = CTRL_WR;
61e4: e5432062 strb r2, [r3, #-98] ; 0x62
DISPLAY_CONTROL_SET = CTRL_WR;
61e8: e5432066 strb r2, [r3, #-102] ; 0x66
DISPLAY_CONTROL_CLR = CTRL_WR;
61ec: e5432062 strb r2, [r3, #-98] ; 0x62
DISPLAY_CONTROL_SET = CTRL_WR;
61f0: e5432066 strb r2, [r3, #-102] ; 0x66
DISPLAY_CONTROL_CLR = CTRL_WR;
61f4: e5432062 strb r2, [r3, #-98] ; 0x62
・
・
・
〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜
ARM7TDMI-Sの場合はstrが最小2クロックサイクルなので、ゼロ・ウエイトで動作が
可能でなおかつGPIOがAHBバスにぶら下がっているLPC2388ではトグリング周波数が
最大18MHzになります(CCLK=72MHzの時)。
↑実際の波形です。波形汚いのは(ry
んでもってSTM32F103BVT6の場合はこんな感じ
"DISPLAY_CONTROL_CLR = CTRL_WR;"の部分は
GPIOD->BRR = GPIO_Pin_12;
GPIOD->BSRR = GPIO_Pin_12;
に読み替えてください。
〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜
DISPLAY_CONTROL_CLR = CTRL_WR;
800459a: f44f 5380 mov.w r3, #4096 ; 0x1000
800459e: 6163 str r3, [r4, #20]
DISPLAY_CONTROL_SET = CTRL_WR;
80045a0: 6123 str r3, [r4, #16]
DISPLAY_CONTROL_CLR = CTRL_WR;
80045a2: 6163 str r3, [r4, #20]
DISPLAY_CONTROL_SET = CTRL_WR;
80045a4: 6123 str r3, [r4, #16]
DISPLAY_CONTROL_CLR = CTRL_WR;
80045a6: 6163 str r3, [r4, #20]
DISPLAY_CONTROL_SET = CTRL_WR;
80045a8: 6123 str r3, [r4, #16]
DISPLAY_CONTROL_CLR = CTRL_WR;
80045aa: 6163 str r3, [r4, #20]
DISPLAY_CONTROL_SET = CTRL_WR;
80045ac: 6123 str r3, [r4, #16]
DISPLAY_CONTROL_CLR = CTRL_WR;
80045ae: 6163 str r3, [r4, #20]
DISPLAY_CONTROL_SET = CTRL_WR;
80045b0: 6123 str r3, [r4, #16]
・
・
・
〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜
STM32F1xx系は72MHz動作だとフラッシュアクセスに2ウエイト掛かるのでトグリング周波数
は18MHzになります。LPC2388と同じ早さです。
STM32F1xx系は72MHz動作ではフラッシュのプリフェッチバッファが効いて分岐なしで動かした
場合はノーウエイトと等価になりGPIOもMAX36MHzでトグリングできるはずですが･･･、
STM32ではAHB->APB2(GPIOがぶら下がってるバス)にかかるSTR命令は最短2クロック
サイクル(※)となるため、MAX18MHzで頭打ちとなります。同じ理由で内蔵高速RAMから
実行してもMAX18MHzになります。
※:AMBAの仕様書(IHI0011A_AMBA_SPEC.pdf)参照
↑期待値通りですね。波形汚いのは(ry
GPIO上げ下げだけじゃナンなのでaitendoさんで急に人気沸騰(?)のOLEDを使用してLPC1769
内蔵フラッシュに書き込んだ画像と文字表示を。LPC1769固有のSPIモジュールの詳細は
まだ調べてないので制御はソフトSPIです。
ノーウエイトの超高速のGPIOでブンまわしてもOLEDは付いてきました！
さて、これからLPC1769使って何をするかですが、I2Sのデバイスも数種類手に入れているので
I2Sの学習しながらベタですがMP3プレイヤーを作るという方向性で考えています。
mbedとかLPCXPresso1768版とか超楽しそうスね(涙目)
TFT-LCD Shieldの開発に当たって、ねむいさんもついにArduinoを購入しました！
最初はEtherpodのプラットフォームだけで動かすことしか考えてませんでしたが、
HP200LX持ってないのにmorphyone作ろうとして盛大にコけたどこぞのぺ○野郎のこと
が頭よぎったので、ちゃんとArduinoを理解してライブラリも作れるようになるために
購入しました…。まぁSTM32ですでにできたことをAVRに移すだけですから驚くほど簡た…
ごめんもう白旗上げていいかな…(※xmegaの二の舞)
ところでxmegaで思い出しましたがxmegaでFatFS(のMSPI)をDMA化出来たという話を
全く聞きません。情報もってる人がいたら教えてください…
20120907追:
xmegaでFatFsのDMA化できるじゃない！
さて、前フリはこれくらいにしといて本題に入りますが、Cortex-M3の系統のARMマイコン、
LPC1768を使用したハイエンドかつ安価な評価ボードがいくつか出ています。mbedや
LPCXpresso(LPC1768版)等がそれに当たりますが、ねむいさんはそれのどれにも手をつけず、
taobaoで液晶買った時についでに中華LPC1768ボードを買っていたのでした！！
↑のLPCXpresso1768版出るなんて知ってたら買ってなかったのですが…くやしい…でも…
過ぎたことは仕方ないので私も通電してみることにしました。
↑KeilのMCB1700互換なミニボードだそうです。周辺が全くない代わりにほぼすべての
IOが外部に引き出されています。
↑即LPC1769に交換ッッ！！１!LPC1768を凌駕する120MHzで動きますッ！
恐らく私が日本国内で初めてLPC1769を動かした女になるでしょう(多分)
R&D dailyの綿谷氏がとうの昔にされていましたorz生意気言ってごめんなさいッ
マイクロマウスの開発されている方たちはなんとうか本当に格が違いますね…
さて、基本の'き'であるLED点滅から始めてみたいと思いますが、上述のとおりMCB1700互換
なので、NxPのサイトにある、
"LPC17xx CMSIS-Compliant Standard Peripheral Firmware Driver Library (GNU, Keil, IAR)"
というExample付きのCMSISライブラリがそっくりそのまま使えます。
GNU用のExampleはこれまたCodeSourceryの使用を前提にされていて、ねむいさん的にも
好都合です。手順に従い、程なくバイナリを生成出来ました。
バイナリの書き込みはもちろんJTAGKey2Clone+OpenOCDから行います。LPC17xx系統の
対応状況は現在JTAG接続のみです。NxP製のARMマイコン特有のCheckSumValidation
に注意してスクリプトファイルを作り、JTAG接続にて書き込みました。書き込みの過程はこんな感じです。
↓
> "C:/Devz/AVR/WinAVR/utils/bin/make.exe" program
openocd -f C:/Devz/ARM/OCD/daemon.cfg -f C:/Devz/ARM/OCD/tcl/interface/jtagkey2.cfg -f C:/Devz/ARM/OCD/tcl/target/lpc1769_rclk_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.5.0-dev-00450-g450aaad (2010-07-22-09:39)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.berlios.de/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
adapter_nsrst_delay: 200
jtag_ntrst_delay: 200
none srst_pulls_trst
500 kHz
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: lpc1769.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : lpc1769.cpu: hardware has 6 breakpoints, 4 watchpoints
RCLK - adaptive
Info : JTAG tap: lpc1769.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: 0x1fff0080 msp: 0x10001ffc
flash 'lpc2000' found at 0x00000000
auto erase enabled
wrote 8192 bytes from file main.elf in 1.328142s (6.023 KiB/s)
verified 4968 bytes in 0.531257s (9.132 KiB/s)
requesting target halt and executing a soft reset
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x01000000 pc: 0x000000e0 msp: 0x10007fe0
shutdown command invoked
現状LPC17xx系のアーキテクチャのすべてを理解はしていないのでLPC2388みたく高速
書き込み/ベリファイはまだ出来ませんが、そちらも使い込むにつれ対応していきます。
↑LED点滅プログラムが動いてるところ。
↑JTAGkey2Clone+OpenOCD+Insightでのデバッグも自在です。
↑NxP提供のCMSISのExampleはLPC1768向けになっており、それをそのままビルドしている
ので,動作周波数はまだ100MHzです。
まぁつかみはこんな感じでしょうか。私が行った最初のとっかかりのプログラムを自分用環境
に移植したものをこちらに。OpenOCDのスクリプトファイルはこちらに置いておきます。
ご利用は自己責任で〜
おまけ
じっと見てたら気づいたけど何かに似てる…
LPCXpresso(LPC1114)はぢめました
20120130追：
OpenOCDで書き込みとデバッグできるようになったから熟読すべし
なんてうかうかしてるうちにXpressoのLPC1768版登場ですって奥さん！ねむいさんは
中華製1768ボードを買ってしまいましたので今すげぇ涙目です！！！
(でもいいんだ、こっちの方が自由度あるし！！全然負け惜しみじゃないし)
さて、LPC1768の件も語ることが多いので次回にゆだねるとして、今回は巷で流行りの
LPCXPressoを使用してみました。今回はLPC1114版の方を使用します。
まずは環境作りなんですが、いつもの通りCodeRedが提供しているEclipseベースのIDE
はガン無視でコマンドラインからのビルド環境を構築しました。構築にあたりtodotani氏、
Lynx-EyED氏、microBuilder.euほかのページを参考にさせてもらいました。
構築と言ってもやってることはLPC2388やSTM32でやってたことと全く同一で、リンカ
スクリプトとスタートアップコードをLPC1114用にこさえるだけです。Cortex-M0も
CMSISライブラリが提供されていてSTM32のものと似たような構成にすれば間違いなく
正しく初期化し、動作するものを作ることができます。
私はさらにこれに加えてNxP製のARMマイコンに特有のCRPのセクションを追加しました。
(まだありますけど後述)普段は使用しないのですが万が一のこと考えてです。
CRP無効にしていますがもちろん他のプロテクションレベルにもできます。
親切心を装って"とりあえずこのプログラム書き込んで試してみて"なんてCRPLevel3
の地雷を故意に仕込むことも可能なのでとてもお勧めですが絶対にやってはいけません！
んでもってLPCXpressoのIDEに同梱されていたLED点滅のサンプルをビルドし、書き込み
ます。書き込みの際にはLPCLinkではなくてSTM8S-DiscoveryのST-LINK部分を改造した
Versaloonを使用してみました。
なんと少し前にLPC1xxxシリーズもSWD接続・フラッシュ書き込み対応になっています！！
…でもまだちょっと不安定。さらなる改善を期待します。
LPC2388で経験されている方も多いでしょうが、大切なことなので2度言いますが
NxP製ARMマイコン書き込みの際に注意しなければならないのは電源投入->リセット後必ず
実行されるビルドインされたブートローダによるVectorCheckSumチェックです。
これはどういうものかというと特定のアドレスまでの(大抵はVector領域)のチェックサムを
とった値とさらに別の特定のアドレスの値をたして0に(2の補数をとる)ならなかった場合、
フラッシュ上のユーザプログラムを実行せず強制的にISPのアドレスにすっ飛ぶという仕組み。
(これにCRPも絡みますが細かいことは各自UserManualで確認のこと)
OpenOCD等でLPC系のARMマイコンのcfgファイルに"calc_checksum"と言う単語があるの
はそのためです。calc_checksumを有効にしているとフラッシュの書き込みアルゴリズム
の中でVector領域のチェックサムの2の補数を取った数がLPC2388なら0x00000014に書き
込まれます。これによりユーザプログラムが実行できるわけですが、今度は0x00000014に
違う値が書き込まれていることになってしまうため、べリファイが通りません…
…OpenOCDの仕様上どちら立たずなのでしょか…
JTAGkey2Cloneの時も述べましたが、どうせほとんど変更とか無いですからスタート
アップにあらかじめ自分で計算して書き込んでおけばcalc_checksum無しでもダイジョブで、
かつOpenOCDからベリファイも使用できるようになりますすみません脱線しました。
話を戻すと、上記のVector領域のチェックサムの2の補数を置くべき場所はLPC1114
では0x0000001cになります。ここにあらかじめ計算しておいた値を書いておけば良いです。
LPCExpressoにビルドインされているLPC-Linkフラッシュライタは自前で計算&書き込み
できます。VersaloonもVSProg上では"-A"のオプションを付けることにより対応可能になり
ますがOpenOCDで使うときの為スタートアップコードに書き込んでおきました。
SimonQian氏のサイトを見てると、もうそろそろOpenOCD0.5.x系にも対応するよ〜な記述が
みられますね…。自分の使いやすい環境で開発するのが一番なので今後の対応を
期待しています！
てわけで基本のLED点滅のソースを…ご利用は自己責任で…
次はLPC1769でもやってみましょか…
LPC2388にもTFT液晶モジュールを
よし。
LPC2388の高速なFIOでもノーウエイトで十分に動かせられるのでかなり使えますね〜。
とりあえずaitendoさんに追加で発注掛けときました。これは良いものだ(マ・クべ顔で)
ソースはこちらに。ご利用は自己責任でどうぞ。今日はこれにて！
…と言いたいところだが！！話はSTM32、現在私が使用している最中のSTM32F107VCT
の話に戻ります。STM32のフォーラム見てたら例のブートローダーが動かないバグが
正式にerrataとして上がってました。
> During the boot loader activation phase,
> if the USART1_RX (PA10), USART2_RX (PD6,
> remapped pin), CAN2_Rx (PB5, remapped pin),
> OTG_FS_DM (PA11) and/or OTG_FS_DP
> (PA12) pin(s) are connected to low level or left floating,
> the boot loader cannot be used.
> It is not possible to connect to the boot loader through either
> of CAN2 (remapped), DFU (OTG
> FS in Device mode), USART1 or USART2 (remapped).
だそうです。本来ならSTM32F103VBT6でうまくいってた接続ではSTM32F107/5系に
乗り換えても本来は正しく動くはずですが、errataのせいで正しい状態に遷移出来てな
かったようです。んでWorkAroundは…
> ● For 100-pin packages: depending on the used peripheral
> the pins for the unused
> peripherals have to be kept at a high level during the
> boot loader activation phase as described below:
> . If USART1 is used to connect to the boot loader
> : PD6 and PB5 have to be kept at a high level
> . If USART2 is used to connect to the boot loader
> : PA10, PB5, PA11 and PA12 have to be kept at a high level
> . If CAN2 is used to connect to the boot loader
> : PA10, PD6, PA11 and PA12 have to be kept at a high level
> . If DFU is used to connect to the boot loader
> : PA10, PB5 and PD6 have to be kept at a high level
一応回避策はあるようですね。…しかし…
>● For 64-pin packages: none. The boot loader cannot be used.
> In 64-pin packages, the USART2_RX remapped pin PD6 is not available and is internally
> grounded. Therefore, the bootloader cannot be used at all.
ねむいさんはSTM32F107VCT6(100Pinデバイス)なのでまだ負けていません。回避できるか
どうか早速試してみました。STM32F103VBTで使用していたUSART1は107系ではUSB-OTG
のvbusとぶつかってしまう為にremapされたUSART2を使うのが都合が良いようです。
あとシステムメモリブート起動時のプルアップはworkaroundには"kept at a high level"とだけ
書いていますがこれが10kohmとかでプルアップしただけじゃ全然ダメで、一部のポートは
1kohmくらいで強めに引っ張り上げとかなくてはなりませんでした。
20091216変更:
PB5に別の検証で使ってたデジトラのコレクタがぶら下っててこれ取り除いたら
10kohmでも問題ないことが分かり修正orz
20101206追加:
デジトラのコレクタがぶら下ってて気づくの遅れたのですが、どうやら
最初にサンプルで貰ったSTM32F107VBT6では1kohmで引っ張らないと無理っぽです。
まぁESですから文句は言えませんね
remappedされたUSART2でブートローダーを使うときには以下の組み合わせで…。
PA10(USART1_RX) :10kohm
PD6(USART2_RX) :10kohm
PB5 (CAN_RX) :10kohｍ
PA11&PA12(USB_DATA) :4.7kohm
USART2(とUSART1も結局試したけど)はブートシーケンスに入るタイミングがかなりシビア
です。ちんたらしてるとすぐに失敗します。なんとかホストPCとの通信に成功すると
いつものダイアログが出てくれます。
ここまでくれば安定してフラッシュの読み書きができます。でもここまでに至る過程が
非常に不安定です。それにCQ-STARMの基板流用してUSBから電源供給してるので
USART2からのブートのためにPA11,PA12(DP&DM)プルアップしてるとダイアログが出まくって
非常にうっとうしいです。USBと絡めて使うときはUSARTのブートは使えませんね。
次にDFUで起動するかどうかを試しました。DFUでブートするためにはPA11,12のプル
アップはもう必要ないですが、vbus供給必須です！
先にも述べましたがvbusはUSART1のTXにぶち当たるのでリマップさせない限りUSART1は
使用できなくなります。STM32EVAL-CのデモもすべてUSART2(remapped)に切り替わっ
てるのでSTM32F105/7系でUSART1をあえて使う理由もありませんが…。
念願のDFUが起動しました…
シリアルナンバーは"STM32"で固定です。一度ドライバ読んだら次からはUSBポート
のどこさしてもドライバは要求されません。
内部フラッシュメモリの読み書きのほかにoptionbyteもいじれるみたいですね。
書き込み速度は流石にJTAGにはかなわないです。でも単体でUSB経由でファームの
更新できるので出先でも書き換えができます。(実装次第ですが)
…と懸念事項であったSTM32F105/7のブートローダーが起動しない問題もworkaroundで
一応の解決を見たのですがerrata-sheetを見るとUSB-OTGやEthernetMACのerrataもたん
まり増えてます。これから使いたい機能にもろかぶりしてしまってるので、はまって足止め
くらわされないようにじっくり検証していきたいですね。
日々是学習
夏の喧騒も過ぎ去り、朝夕はすでに秋の気配を感じさせる季節になりましたが、皆様
皆様いかがお過ごしでしょうか？私は到来した民主政権の乱世を生き抜くべく棘付き
肩パッドとモヒカンカツラと火炎放射器を用意したぜﾋｬｯﾊｰ！!!でも七つの傷を持つ
男だけはかんべんな！
…と検索で情報を求めて飛んできた人をまわれ右させたところで本題に入ります…
ゆっこ(伊勢乃宮雪子)ちゃんの誕生日のお祝いも終わってひと段落した所でかねて
より構想していた、LPC2388用MCIアクセスプログラムのVCOM対応版の実装に
取り掛かりました。
以前はOLEDとVCOMの出力先を切り換える部分で死んでいたのですが、深く調べた
ところまだuart処理の部分が残っていたのが分かり、これもVCOMの処理に置き換え
ることでクリア。
んでVCOMを実装したことによりスーパーバイザモードでスタックオーバーフローしてた
のが分かったのでスタックをかなりおごってあげることにより不安定だったモニタの
動作も安定化しました。
あと、ほんとにいまさらですがMartinThomas氏のIRQ-wrapperの処理を穴のあくほど
見てLPC2388上ではどのようにして割り込みの動作がなされるかも再度確認…っと。(割り込みの解説は素直にHITOPのcookbook見た方が良いです)
…うｎ私まだARMの動作よくわかっていない部分があるんだ。
うむむUSB周りはほんとに難解ですね…やっていくうちに霧が晴れるようにわかるどこ
ろかますます視界がふさがっていくような感じです…(個人的に霧は大嫌いだし)。
それでも進んでいくしかない。次はUSB-MSCの実装で残っていた課題のMCIアクセスの
DMA化を目指しましょう。
といったところで今日のソースを…。ご使用は自己責任で…。
過去にリリースしたソースも改良すべき点や明らかな間違いを見つけた時は適宜修正
したりしてます。落として試されたことがある方はご留意ください。
LPC2388でUSB-MSC(MassStorageClass)を使う2
やっぱ難しいやUSBって…
前回はLPC2388でMCI経由で動く"だけ"の物をこしらえてました。ですのでつぎ
はぎだらけのがかなりいい加減でしたがここ1週間(1作業日)で自分なりに流れが
理解できる構成に変えました。これはUSB-CDCで行ったのと同じものです。
debug出力はフットプリントが少ないchan氏のxprintfに替え、かつ動作クロックを
48->72MHzに上げて、んでもってUSB接続で時折コケてた部分を修正してます。
肝心の機能の方は…MMC,SD,SDHC(4GBまで)対応で、LPCUSBが唱っている最大
250kb/sの読み書きもおこなえているようです。
SDカードをいくつか試してみると、容量の少ない物だと上記の速度で読み書きが
行えるのですがSDHCみたいな大容量のものだと半分以下の速度しか出ない事が
分かりmp3ファイルとか移動するときは速度が足らなくて不便に感じます。
あとMCIのドライバはESFLの物を流用させてもらっています。しかしこれはDMAを
使用していません。DMA使えたらSDHCとかでもう少し速度が改善できるんじゃ
ないかなと思っています。
すでに泥沼にはまっている気がしてますが違う事やろうとするとUSBはやっぱし
難しいですね…。まだまだW.I.P.なソースはこちらに。
ご使用は自己責任+ご意見無用でお願いします。
ついでにですが先に紹介したchan氏のLPC2388向けmciアクセスプログラムの
FatFsR0.07c+RTC適用版で相対パスのオプションを有効にしてコンパイルすると
正しく動作しなかったことが分かったので修正版をあげてます。
MCI_OLED
LPC2388でUSB-MSC(MassStorageClass)を使う1
"有益＝ソースコードそのまま流用できる"なんて根性でやってると痛い目にあいます。
ええ確実に。…そんな根性をしていた時期が…私にもありました(刃牙顔で)
重箱の隅までは理解しなくてもいいけど最低限どうやって桶屋が儲かってるのかくらい
は知っておいた方がいいとおもいますよマジで！CQ誌提供のGCCサンプルソースとかも
(ワザとじゃないだろうけど)明確な間違い仕込んでたりしてますんで遊びであっても
くだらないことで時間や金を消費しないように気をつけましょうというお話。
とくにLPC2388は…、
.org 0x1fc
__: .word 0x43218765
のたった二行をスタートアップに仕込まれただけで文字通りゴミ基板になるしでも
こんなあくどいことするやつさすがにいないだろけど…私はそんなことしないよ？…ふふふ
…さて本題、ここ最近はLPCUSBを使用してUSB Mass Storage Class(以下MSC)をLPC2388
で何とか実現できないかと模索しています。SPIアクセスのサンプルはすでにあるのですが、
せっかくSDIO(MCI)があるのでこれで使えるものにしていこうかな、と。
現状こんな感じです。
なんか微妙な…ディスク容量が…うまく表示されてない…
SDHCも認識できているようです。が…実際の動作は？？
このMSCをchan氏のmp3プレーヤーと結合させてSDカード取り外さずにデータ書き込め
たら手間が省けてうれしいのですがはてさて…
WorkInProgressですがソースも置いときます。検証段階ゆえに自己責任+ご意見無用で…。
次回に続く
現状USB関連の書籍を買ったり借りたりしておべんきょ進めてますが…私はぶっちゃけ
おべんきょとセンセイが大嫌いです…しかしUSBを必ず物にして恐怖症を克服したいです…
追：
OpenOCDのWindows用実行形式ファイルがftdiのライセンスがらみでダウンロードできなく
なってしまいましたが、ZUS氏がビルド方法の詳細な解説をされています。
私も氏のページを参考にビルドしたもので書き込み・デバッグ・メモリダンプができるのを
確認しました(OpenOCD ver 0.3.0 r2578)。また、JTAGkey互換デバイスを使っているのなら
ベステクさんところで配布してるバイナリを使わせてもらうという手もあります。
追2：
OpenOCDのソースはsvnではなくgitを使用して取得するようにしてください。
LPC2388に実装したFreeRTOS上でEthernet-PHYを使う(だけ)
どうしてもWinARMを使いたいのなら20060606版を使え！
20080331版は一部の標準ライブラリが無いから使っちゃらめぇ！
↑これはねむいさんの独り言です。ねむいさんはCodeSourcery G++を使用することを
強く強くお勧めします。
…さて本題、FreeRTOS配布パッケージにあるLPC2468のデモはMCB2300デモボード
上での使用を想定してオープンソースなTCP/IPプロトコルスタックであるuIPが使用できる
ように組み込まれています。前回は外付けEthernet-PHY(DP83848)の回路を持っていな
かったのでその機能は外してRTOSの動作を見ていましたが、Digi-keyで頼んだ部品が入
ったのでEthernet-PHY周りの回路を製作し、改めて動作の確認を行いました。
Ethernet-PHY周りの回路はMCB2300の回路の丸パクリです…。回路図引く手間が省けた
50MHzの高速なクロックを扱うので、"びびり"なねむいさんはメッシュアース基板で回路
を組みました。基板組むのにかかったお値段は2944円也。QTFP変換基板やメッシュアース
基板使わなかったらもっと安く作ることができるでしょう。動作は保障できませんが。
ChanさんみたくUEW線を活用してカッコよく引き回せられたらよいんですけどね〜…私の
腕ではこれが精一杯ですorz
基板上を走る黒いリードはAWG32・UL3417の超極細耐熱電子ワイヤー。少しかさははり
ますがUEWより扱いやすく、重宝してます。また、CQ-FRK-NXP-ARM基板上の3.3Vレギュ
レータの容量が心もとないので(他のデバイスぶら下げること考えて)Ethernet-PHY基板
用に別途3.3Vレギュレータを設けました。昔秋月で販売していたL1087を使用してます。
一応50MHzのクロックのラインは最短で這わせています。オシロで見る限りでは、
ちゃんと所定の50MHzの周波数で発振しているようなのでひと安心。
ここまでやって失敗してたら死ぬわ。
↑オシロのグランドリード伸び伸びのやっけつ測定。一応50MHzは出ているが…
後はソフトの方ですが公式のFreeRTOSソースはVerUpされてすでにV5.4.0になってます。
以前動かしたLPC2388用のデモソースもV5.4.0上で問題なくコンパイル・動作確認でき
ました。んで、以前はコメントアウトでオミットしていたuIPのタスクとLCDのタスクを
再び復活させるのですが、LCDのタスクは台湾BOLIMIN製のi2c液晶モジュー
ルのルーチンに差し替え、さらに48MHzで動作させていたFreeRTOSを72MHzで動かします。
オリジナルのLPC2468のデモは48MHzで動かしてたのに今気づいたorz
そんなこんなで無事にWebServerが動作しました。i2c液晶もオリジナルのLCDと遜色なく
表示ができています。printf系の関数もHeap_3.cを使うことによりうまく機能しました。
(printf系はOSから正しい手順で動かす方法あるはずなんで調査中です。)
元のLCDのソースには80段階でバーグラフ表示させるルーチンもあったので、ST7032iの
ライブラリに移植してます。初めて知ったけどこれ使って面白いのが作れそうですね〜。
↑てわけで早速使って組み込んでみた。
今同時に進めてるCortex-M3も将来的にはSTM32F107系に乗り換えるので、RMII接続できる
Ethernet-PHY基板はこれからも重宝しそうです。
本日のソースはこちらに…。先にも書いたけどEthernet-PHYの回路はここ参照のこと。
お約束ですが真似して試される場合は自己責任でどうぞ！
LPC2388からFMラジオモジュールを動かす
待ちきれないからお姉ちゃん先に作っちゃったよ
やっぱユニバーサルでも基板にちゃんと組むと見栄えがしますね〜。
ということで今度はスイッチサイエンスさんとこで購入したFMラジオモジュール
を試してみたいと思います（SPARKFUNのFMモジュールspk-fm-301と同じです)。
触ってみた人なら分かると思いますが、このモジュールにあるAR1010ていう
ICがかなり癖のあるデバイスでデータシート/アプリケーションノートの説明が
非常に不親切です…ていうか一番重要なレジスタマップ等の情報をデータシート上から
抹消して提供してやがっててなんというかとても中国くおりてぃーだと思いました。
今回の検証に先立ち、ゆきの研究室さんのレポート,マイコン工作実験日記さんの
使用記を参考にさせていただきました。
とても助かりました。…というか作例ないと無理ですわｺﾚ
冒頭に写真乗っけちゃったけど今回はLPC2388(CQ-FRK-NXPARM)上でi2c液晶と組み合わ
せてi2cデバイスとして動かしてみます。i2c液晶のときと同じくAVRで予習済みなので、
AR1010用のハイレベルアクセス層はすでに作ってあります(はしょるはしょる)。
後は"下駄"に当たるLPC2388でi2cデバイスを制御するローレベルアクセス層を
作れば即終了(のはず)です。
ありゃりゃ…ETHERNET-PHYの制御でi2cポート0はふさがっちゃってるようですね…。
将来ETHERNET-PHYは確実に使うからここを使うわけには行きません…。
仕方ないので他のあいてるi2cポーt…
…
おいおいポート1,2ってオープンドレインじゃないのかよ！
ってわけで今回もお手軽かつ汎用性が高いソフトウエアi2cマスタでいきたいと
思います！！！内蔵i2cレジスタ叩くのが面倒って理由じゃないよ！！
(どうせ内蔵で叩いても私がやるとポーリング入りまくるし…)。
ARMに限らずソースコードはできる限りトリッキーなことはしないでねむいさんの
つるつる脳みそでも分かりやすいようにモジュール化して汎用性を高めるように
心がけてます…。たとえ速度が犠牲になったとしても…。
…そんなこんなでLPC2388基板上でもi2c液晶とFMラジオが動きました。私は新潟精密
のFMモジュールは知らないので比較できませんが、音質は市販のFMラジオと遜色ない
十分実用に足るレベルだと思います。
なお、受信感度を取得できるレジスタとかもAR1010にはありますが、i2cで読みに行
くたびにﾎﾟﾂﾎﾟﾂノイズが入るので受信感度表示は現状では行ってません。
今回のおソース&配線図はこちらに
(バグ見っけたのでメニューの置場から新しいの落としてください)
ご利用は自己責任で…
おまけ
前回のOLEDの動作もベースボード上でもう一度やってみる。
みやはらみみかきさんが描かれた私の(ねむいさんの)線画を私が勝手に塗って仕上げ
させてもらったのを映してみましたが、ぶろぐを見にきたびぃぶろ君が欲情すると
困るのでものすごく小さく乗っけときます…
･･･画像押すなよ？絶対に押すなよ！？(ダチョウ倶楽部風に）
･･･
･･･ふ〜〜･･･さぁてつぎはAT91SAMでもやりましょかね･･･
ペ プ し そ
･･･これなぁ…
コツメちゃんが一日野原駆け廻ってきた後の匂いと同じ味がするわ…
キワモノ系はペプシブルーが一番ましかなと思うねむいさんでした。
いかん、日記がここで終わってしまうところだった。最初の画像右下にも少し見えて
ますが、少し前にまとめて買ったいくつかの玩具のうちの一つ、Sparkfunで販売している
OLEDモジュールに手をつけてみました。
OLEDモジュールはLPC2388基板で制御するわけですがプログラムはchanさんの
作例をそのまま使用します…。まぁいつもの追実験なわけですけど、とにかく動かす。
まず動かしてから理解するが私の学習方法ですから･･･。でもこれで動かせ
られなかったらア●みたいだ私。
キャリアボード上のジャンパ設定は以下写真のように。
ボード上のDCDCが3.3Vサポートなので+5Vは不要です。
とりあえず映りました。いなちゃんはどのプラットフォームでも美しいな…♥
話には聞いてましたが実際に動かしてみるとOLEDすごいですね〜。
発色や明るさはもちろんのこと視野角が素晴らしいです。
今回の実験のために行ったやっけつ配線…バスが高速で動いてるからヤバいかな私。
･･･と思ったけど全然大丈夫だったりしました。もちろんちゃんとユニバーサル基板に
コネクタつけて配線し直します。明日はi2c液晶とFMモジュール控えてるし！！
さりげなく映ってるえろすないないさんの絵は虹裏に投下しました･･･。
※びぃぶろぐはえろす禁止ですが多分これ位なら無害です
LPC2388上のFreeRTOSにUSB-CDC乗っけてみる(だけ)
いつもは最初の段落で本題どころか電気電子とは全っっったく関係ない
話をして検索で飛んできた人の見る気をゴリゴリに削いでいる私ですが
今日は違います。たまには頭っから真面目に工作ものの紹介しますよぅ！
↓デビューしてまだ一月も経ってないのに即レ●プされるi2c液晶の図
…
…ふ〜〜〜…最近全然会ってないけど赤ロリさん元気してるかな…
さて本題、FreeRTOSがLPC2388上でも動作したと以前の日記でふれましたが、
他の方はLANと組み合わせた作例を試されているので、私はUSBデバイスでやってみます。
丁度LPC2388のUSB-CDCを試してたところなのでこいつを組み込ませて動作するか
どうか試しました。
実装の際に懸念されるのは、割り込み周りの処理に関する部分でした。まず、
ビルドを通すために割り込みの処理の部分の記述をFreeRTOSの流儀に変え、サンプル
にあるLANのプログラムを頼りにOSレベルで必要な処理も見よう見まねで加えました。
また、基板もCP2102とLP2388のUSB-CDCが同時に使用できるように改造。同時挿しも
可能なようにしてあります。
結果は…ちゃんと動きました。USBの割り込みの動作も問題なかったようです。
まだ文字列吐かすだけの単純なのですけどね。
USB-CDCを組み込んだFreeRTOSのLPC2388版のソースはこちら。
試される場合は自己責任で…。
zipファイルにも注意書きがありますが、このソース単体ではビルドはできません。
別途FREERTOSのアーカイブを入手する必要があります。
調子に乗ってchanさんのSDカードのアクセスプログラムでもUARTをUSB-CDCに置き換えて
試してみましたがこっちは残念ながらNG。どうやらシリアルとOLEDの出力関数を切り替え
る部分？であっちの世界に逝っちゃってるぽいですが、現段階では調査中です。
USB-CDC版でもちゃんと動きました。
LPC2388のCDC(仮想COMポート)を使う
１週間前、臨時収入が入りましたので今まで購入したいと思っていた電子部品
や評価基板をいくつか注文しちゃいました。夏物の服は「茄子」が入って
バーゲンになって値段下がってからでいいや。それまでに売れてくれるなよ…！
…そのまえに今年茄子あるかな…。
少し前にLPC2388にあるUSBホストのサンプルの追実験をしましたが、USBターゲット
を含めたサンプルコード集もNXPのサイトで提供されてます。コード集にはUSB-CDC
(仮想COMポート)の作例もあってRTCやUARTは簡単にできたので次はこいつを
ポーティングしてやろうと画策しました。
…しかし、これのUSB-CDCのは割り込みや構造体の定義がGCCとの互換性が
全くと言っていいほど無くてコードをポーティングするのが一苦労。しかもコンパイル
無理やり通してバイナリ焼き込んでも案の定動作できねぇ！！１！
XPでUSBデバイスを認識したときのあの｢♪ﾃｺﾝ」が鳴ってくれない…
結局２〜３日格闘して私のぎじゅつ力じゃこれ以上は無理と白旗上げてしまいました。
(ネットの記事漁るとちゃんと出来てる人もいるみたいです…くやしい…でも…)
なんかよい情報はないものかと海外のLPC2000のフォーラム等をいろいろあたると
GCCでソースが公開されているLPCUSBなる物があることを知り、これを叩き台にして
LPC2388向けのUSB-CDCデバイスをこしらえることに。
もともとはLPC2143用だったみたいですが、数年前にLPC2378向けにも使えるようにアップ
デートされていて、大きな変更もなくLPC2388基板で無事｢♪ﾃｺﾝ」を聞くことができました。
その後はSTM32とおんなじようにprintf使えるようにリターゲットして、以前のRTCの
サンプルのCDC版が動くとこまで確認。
懸念してたUSBの動作と他の複数の割り込みの動作の干渉も特に問題ないみたいです。
とりあえずLPC2388上で"動く"とこまで持ってけましたが、"どのようにしてUSBデバイス
として動いてるか"の理解ができないとこっから先はやってけないと感じてます。
点と線だけで繋いでいた知識のリンクを面で囲っていけるようにしたいです。
私のおべんきょはさらにつづく…。
というわけで本日のおソース。試される場合は自己責任で…。
TFT−LCD表示プログラムのUART処理部に統合しました。
ねむいさん向けにかなりいじくり倒してるので、本格的にされる方は本家の
ソース当たった方がいいと思います。
いろいろ試す…
ブログ始めて1月ほど経とうとしています。書いてる記事はARM系が多いのですが、
このブログのヒットカウントの稼ぎ頭が以前少し触れたJTAGkey(の互換回路)の紹介と、
JTAGkeyとUrJTAGを使ってDDT誌のLattice基板へ書き込むの記事だったりします。
まぁ私がブログの記事をメモ帳代わりにして参照してるのでこのページカウント
だけ多いといったら当然なんですけど…そんな私のブログへの一番のリピーターさんは
googlebotさんだったりするorz
ううむ…もうちっと真面目に書くか…あーでも来週1週間は二次裏での活動に
集中したいしなぁ…困った…
話変わって、LPC2388の基板でできる事柄の追実験を私もいくつか行いましたの
で紹介します。まぁいわゆる他人のふんどしです。
●FreeRTOSを載せる
OS乗っけることによる恩恵って何なのでしょうかと自問自答する私。
そのまえにOSとはどういうものか、どのようにして動かすのか/動くのか等の
おべんきょが必要な段階です…山の頂上は遠い。
後閑氏のFreeRTOSの解説ページとFreeRTOSの公式サイトで配布されてるZIP中に
あるLPC2468用のデモを頼りにLPC2388の物に移植してみたところ、
先に作成したLPC2388用のファイルを組み込むだけであっさり動きました。
リンカスクリプトの修正もLPC2388用のアドレスに差し替え以外は特に大きな変更もなく
printf/sprintf等の標準関数が使えてます。
時間の空きを見てこのOSの仕組みやOS使用時の定石等を覚えていきたいと思います。
そういやLPC2388のエラッタでPLLが300MHz以上だったかは動かないとか言う記述が
ありますね。私が買ったのすべてチップrev.Bでエラッタの範囲外なので高めに設定してます。
雑誌の付録は多分みんなrev.Bだから大丈夫だとは思うけど…
(雑誌記事等のPLLてやけに低めに設定されてたのはここら辺の理由ね…)
ARM7_LPC2388_xxxxxxxx.zip 試される場合は自己責任でどうぞ。
●USBHostLiteを使ってみる
くんくん氏がGCC環境にてUSBHostLiteを使いやすくした形で公開されていましたので
こちらを使わせていただきました。前回の日記のをベースにUSBHostLiteのプロ
グラムを付け足す形で作成してます。ターミナルから「u」もしくは「U」を打つと接続
されたUSBメモリにアクセスを試みる形にしました。ちゃんと読み書きできていれば
適宜メッセージが表示されます。こんな感じでうまくいけてます。
現在の外観はこんな感じです。サクサク書き込み&デバッグができるJTAGkey大活躍です。
左下に見えるLatticeの基板はAVR_Core使ってSDカード読めるところまでいってますが…
まだまだ初歩の段階です。こっちはいまだ手探りです。
●ChanさんのMCIアクセスプログラムを試す。
LPC2388用の拡張子基板がボリ松若松通商から発売されていますがSDの読み書きを
試すだけに6000円ペイするのは(趣味であっても無駄な所に金を落とすのは)
できなかったので残り物かき集めてSDカードのインターフェースだけこしらえました。
自分で作ると200円。基板組むのに25分ほど。さほど負担にはなりません。
イーサネット用の回路も自作に頼ることになるでしょうね。
プログラムはchanさんのWinARM20060606用のコードをCodeSourceryでコンパイルできる
ようにmakefileを書き替えただけで後はコピペしただけで難なく動作してしまいました。
RTCの時刻情報を反映できるような付加機能とかができたら公開したいと思います。
今頃LPC2388基板(CQ-FRK-NXPARM)とかいぢってみる
2x歳も半ばを過ぎて、やっとクレジットカードを手にしました…
磁気カード式の定期使うためには半ば強制加入だったもんで仕方無く導入なん
ですけどね〜。案の定早速パスワード失念しかけて青くなる私。
CQ誌のインターフェース誌や今は亡きDWM誌は春になるとARM系のマイコン基板
が付録に付きます(ました)ね。フレッシャーズ向けとの触れ込みですが、これ系の
基板は通電前に回路図、部品データシートをよ〜〜〜〜く観て吟味した上で
遊ばないといけないのは周知の事実だと思います。
また、記事もゲーメスト並に豪快な誤植・間違いが多いので鵜呑みにしてしまうと、
マイコン初心者の方向けのEASYな難易度のはずがSUPERHARDのハマリ地獄に
直行したり知らぬうちに基板壊すなんてことも多々あります。
(｢ザンギュラのスーパーウリアッ上｣レベルなら笑って許せるけど+5Vと+3.3V
間違えるとかはヤバ過ぎだ)
幸いなことに現在はブログ等で情報の相互のやりとりができるのでホビーで楽しまれ
ている方でも出来るだけ損をしないように十分調査をした上で実験・製作等をする
のが良いと思います。ググるだけでも全然違いますからね。
ねむいさん的には危険と失敗のリスクを隣り合わせにするのも遊びの醍醐味と
思ってるので付録基板の企画はこれからも支持したいと思います(性的な意味で)。
また前振り長くなりましたが、私もARM7TDMIのアーキテクチャ学習用にこの基板を
いぢっています。雑誌記事のチュートリアルは全てガン無視でMartin THOMAS氏の
LPC2378のサンプルをベースにLPC2388(CQ-FRK-NXPARM)向けにコードを移植、また
リンカスクリプト、スタートアップコードもnewlibのprintf系の関数が使用できる
ように試行錯誤を繰りかえして徐々に付け足していきました。
以下にARMをGCCでコンパイルする際、newlib(標準Cライブラリ)のprintf系関数
をハングしないように使うための最低限のコツとかを。
注:CodeSourcery/RaisonanceRIDE7の環境下でのコンパイルを想定してます。
1.システムコール関数群を定義する。
syscalls.cというファイルにprintf系の関数を使用したときに呼び出される
関数群を定義するのが通例となっています。定義してないとリンク段階で
「sbrkr.c:(.text+0xc): undefined reference to `_sbrk'」とかのエラーが
出てきてしまいます。
20110912改変：
AVRやPICで慣れた人がSTM32やLPC2000/1000などのARMマイコンを初めて使用
する際に必ず引っかかるポイントですが、CodesourceryG++などのGNUなビルド環境
ではprintf等の関数の出力先を柔軟にするために_readや_write，_sbrk等のローレベ
ル関数が実装されていないので自前で作ってやる必要があります。
sourceware.orgにsyscallについての簡単な解説がありますので参照してください。
printfを出力を吐かす先はたいていはシリアル出力となるので_readや_write関数
については自前のシリアルの一文字入/出力関数をリターゲットしてやればよいです。
上記URLに則すならたとえば_write関数のoutbyte(･･･の部分を自前のUART出力関数
に置き換えればリターゲットは実現できることになります。
_sbrkについてはprintf系関数(書式に変数を含まない場合に限りmemcpyが呼び出さ
れるもようです)やmallocを使用する際にメモリアロケーターのローレベル部として
後述の外部変数_endと絡めて呼び出される極めて重要な関数です。
audin氏も(話がOSにも絡んでいますが)非常に深い考察をされていますので必読です！
2.リンカ・スクリプト内の_endの定義
newlibは_sbrkという関数で_endを参照してきますので、リンカスクリプト内で
外部変数_endを定義します。調べた限りではbss領域の直後でheap領域の初めに
(heap領域がリンカスクリプト内で明示されてないのもあるが…。)
定義されていますのでそう記述しておきます。
3.スタック領域の確保
printf系の関数はスタックをびしばし使って1kバイト近く消費しますので、
printf系の関数使う場合1kbyte以上+本来使用するスタックのバイト数を定義
しときます。確保してなくてもパッと見ちゃんと動く時もあるので結構見落とされ
がちです。動作が怪しい時は、スタックの確保量を疑ってみてください。
Martin THOMAS氏のサンプルとそれを真似した私のソースはスタートアップ
ルーチン内でスタック領域の確保を行っています。
また、可変引数に変数がない純粋な文字列のみの場合、printf関数はコンパイラ
側で自動的にputs関数に切り替えられます。
4.printfとか使うとリンクされる「.ARM.exidx」セクション
WINARM20060606にはこんなのなかったはずですが…、ググりまくって調べると
こことかここに詳しく説明がありました。
arm-(OS名)-eabiな処理系でnewlibとか使うと無理やり挿入されちゃうようです。
.ARM.exidxもリンカスクリプト内で適切に定義してやらないとリンク時エラー
になったり｢sh_link not set for section `.ARM.exidx'｣ってワーニング
吐かれたり、コードサイズが異様に膨れ上がったりしますのでやや注意です。
私の環境では上記の様に配置して無難におさまってもらってます。
以上の点を踏まえ、printf/sprintf使用してUARTにRTCの時刻情報を吐く
CQ-FRK-NXPARM向けのプログラムをこしらえました。32.768kHzの水晶必須です。
おまけで#defineでscanfを使用した簡易メモリダンプに切り替えられるようにしてます。
ダンプのルーチンはSYSLAB氏が公開されていた物を使用させていただきました。
ソースはこちらに。自己責任でどうぞ。
フラッシュの書き込みができるlpc2388用のopenocdバイナリもついでに。
RTC用のVbatは基板上でVccに直結されていますが切り離してやると本来の動作が
できるようになります。今、バックアップ電池でARM基板のRTCを動かすのが
流行ってるようなので私も真似して付けてみました。回路構成はこんな感じです。
今回使用したTAKACHIのCH7410-2032LFというボタン電池ボックスはコンパクトで
底が平らなため、CPUの上に両面テープでペタッと置けるので重宝してます。
明日絶対に筋肉痛になるな…
注！最悪PCまでつぶれるので真似しないでください
今回のお題
IF誌5月号付録LPC2388基板に品質の悪いUSBケーブルを使用して接続すると
接続した瞬間に発生する高電圧で基板上のレギュレータを壊してしまう件の検証。
また、発生する高電圧を抑制して壊れないようにする対策の効果の検証。
IF誌が同時に勧めているショットキダイオードは上記現象とはあんまし関係ない
ので今回は付けない。
追：
simさんちのコメントで関係がない割には妙に事情に詳しい人が弁解をされておりました。
dv/dtのコントロールが出来てない回路では突入電流で過電圧が発生して素子が
破損するリスクがあるなんてのは聖闘士にとってはもはや常識中の常識です。
それ以前に誤植や思い込みによる間違いが多過ぎでCQ出版はひどすぎです。
実験装備：
１．CQ-FRK-NXPARM(IF誌5月号付録LPC2388基板)。
２．品質の悪いUSBケーブルとやらがないので
USB2.0のA-B1mを一本,USB2.0の5m延長2本使って合計11mの規格オーバーの
ケーブルを用意。(ケーブル組成はすべてVCC&GND:AWG24、D+&D-:AWG26
っぽいです。)
３．2012サイズ、X5R,16V,10uFのチップ積層セラミックコンデンサ(MLCC)
USBの規格上VCCにぶら下げられるキャパシタ容量上限が10uFだから
これ選びました。
実験内容：
LPC2388基板とUSBコネクタをズボズボしたときの+5Vの電圧をオシロで観察する。
上記３．のコンデンサをうまく実装して同じことをする。
左下にコイン電池みたいな物体が見えるけど気にしないでください。
結果：(測定したのだいぶ前です)
コンデンサない時
コンデンサある時
考察：
It's groovy...
じゃなくて確かに電源の立ち上がりでオーバーシュートして一瞬ですが耐圧
オーバーしてますね。憶測ですが元からあるレギュレータの入力コンデンサの
CとUSBケーブルのLでちょうど共振しちゃっているのでしょうかね。
(電源立ち上がりの時定数が早すぎるとか??PID制御思い出した)
10uFぶら下げてやると水を打ったように電源の立ち上がりがなだらかになります。
対策は上手くいっているようです。
あと、わかっているとは思いますが、なだらかになるからと言ってむやみ
やたらに220uFとかでかいコンデンサ付けると今度は突入電流でUSBのホスト側が
過電流と認識してUSBデバイスを認識させなかったり最悪+5VUSBが大きく
ドロップしてマザボごと強制リセットとか憂き目にあいますのでUSBの規格に
従いましょうね。
ねむいさん的にはレギュレータの問題よりもVbatがVccに直けｔ(ry
EX:
私が出せる全力スピードでUSBコネクタを激しくズボズボする。
それはもう200回くらい。もちろんコンデンサは実装しない状態で。
結果:
レギュレータは全くの無傷。今日も元気に3.3Vを生成しています。
腕が攣った。
基板側の¥120で買ったUSBリセプタクルがｶﾞ●ｶﾞ●ﾏ●ｺｲになったので付け替えた。
考察:
(今日の日記のタイトル)
連絡・質問・免責は↑のリンクを
↓SNSもやってます↓
powered by まめわざ
- ARM/STM32 (104)
- OpenOCD (27)
- ARM/NxP (34)
- ARM/Cypress (5)
- ARM/Others (3)
- ARM/Raspi (1)
- AVR (11)
- FPGA (4)
- GPS/GNSS (18)
- MISC (75)
- STM8 (1)
- Wirelessなアレ (16)
- ブラウザベンチマーク (28)
- 日本の自然歩道 (23)
- 1Wire温度センサDS18B20の偽物を追え！
⇒ ねむい (04/26) - 1Wire温度センサDS18B20の偽物を追え！
⇒ (04/08) - 中国自然歩道を往く -北伐！県境を越えて鳥取県に侵入せよ！-
⇒ ねむい (12/23) - 中国自然歩道を往く -北伐！県境を越えて鳥取県に侵入せよ！-
⇒ ひかわ (12/18) - 中国自然歩道を往く -北伐！県境を越えて鳥取県に侵入せよ！-
⇒ ひかわ (12/18) - いろいろ試す51
⇒ ねむい (06/26) - いろいろ試す51
⇒ ひかわ (06/10) - STM32G0使ってみる4 -1wireデバイスをいろいろ使ってみる-
⇒ ねむい (12/14) - STM32G0使ってみる4 -1wireデバイスをいろいろ使ってみる-
⇒ ひかわ (12/05) - 大緊急事案！！！１！Raspberry Pi Picoはぢめました！！１！！１
⇒ 竹本浩 (08/14)
- May 2023 (3)
- April 2023 (1)
- March 2023 (1)
- February 2023 (1)
- January 2023 (1)
- December 2022 (2)
- November 2022 (1)
- October 2022 (1)
- September 2022 (1)
- August 2022 (1)
- July 2022 (1)
- June 2022 (1)
- May 2022 (1)
- April 2022 (1)
- March 2022 (1)
- February 2022 (1)
- January 2022 (1)
- December 2021 (2)
- November 2021 (2)
- October 2021 (1)
- September 2021 (1)
- August 2021 (1)
- July 2021 (1)
- June 2021 (1)
- May 2021 (1)
- April 2021 (1)
- March 2021 (1)
- February 2021 (1)
- January 2021 (1)
- December 2020 (3)
- November 2020 (1)
- October 2020 (1)
- September 2020 (1)
- August 2020 (1)
- July 2020 (1)
- June 2020 (2)
- May 2020 (1)
- April 2020 (1)
- March 2020 (1)
- February 2020 (1)
- January 2020 (1)
- December 2019 (3)
- November 2019 (1)
- October 2019 (1)
- September 2019 (2)
- August 2019 (1)
- July 2019 (1)
- June 2019 (1)
- May 2019 (1)
- April 2019 (1)
- March 2019 (1)
- February 2019 (1)
- January 2019 (1)
- December 2018 (3)
- November 2018 (2)
- October 2018 (1)
- September 2018 (1)
- August 2018 (1)
- July 2018 (1)
- June 2018 (1)
- May 2018 (1)
- April 2018 (2)
- March 2018 (1)
- February 2018 (1)
- January 2018 (1)
- December 2017 (2)
- November 2017 (2)
- October 2017 (1)
- September 2017 (1)
- August 2017 (1)
- July 2017 (1)
- June 2017 (1)
- May 2017 (1)
- April 2017 (1)
- March 2017 (2)
- February 2017 (2)
- January 2017 (2)
- December 2016 (7)
- November 2016 (2)
- October 2016 (2)
- September 2016 (1)
- August 2016 (1)
- July 2016 (1)
- June 2016 (1)
- May 2016 (2)
- April 2016 (1)
- March 2016 (2)
- February 2016 (1)
- January 2016 (1)
- December 2015 (3)
- November 2015 (1)
- October 2015 (3)
- September 2015 (2)
- August 2015 (2)
- July 2015 (3)
- June 2015 (3)
- May 2015 (4)
- April 2015 (2)
- March 2015 (4)
- February 2015 (1)
- January 2015 (3)
- December 2014 (3)
- November 2014 (2)
- October 2014 (1)
- September 2014 (2)
- August 2014 (2)
- July 2014 (3)
- June 2014 (2)
- May 2014 (1)
- April 2014 (1)
- March 2014 (4)
- February 2014 (4)
- January 2014 (3)
- December 2013 (5)
- November 2013 (4)
- October 2013 (3)
- September 2013 (2)
- August 2013 (2)
- July 2013 (2)
- June 2013 (3)
- May 2013 (2)
- April 2013 (2)
- March 2013 (2)
- February 2013 (2)
- January 2013 (3)
- December 2012 (4)
- November 2012 (2)
- October 2012 (2)
- September 2012 (4)
- August 2012 (1)
- July 2012 (3)
- June 2012 (2)
- May 2012 (3)
- April 2012 (3)
- March 2012 (2)
- February 2012 (3)
- January 2012 (3)
- December 2011 (5)
- November 2011 (3)
- October 2011 (2)
- September 2011 (2)
- August 2011 (2)
- July 2011 (2)
- June 2011 (2)
- May 2011 (2)
- April 2011 (2)
- March 2011 (2)
- February 2011 (2)
- January 2011 (3)
- December 2010 (7)
- November 2010 (1)
- October 2010 (1)
- September 2010 (1)
- August 2010 (3)
- July 2010 (4)
- May 2010 (1)
- April 2010 (2)
- March 2010 (2)
- February 2010 (2)
- January 2010 (3)
- December 2009 (3)
- November 2009 (8)
- October 2009 (7)
- September 2009 (5)
- August 2009 (4)
- July 2009 (6)
- June 2009 (7)
- May 2009 (14)
- January 1970 (1)
Copyright(C) B-Blog project All rights reserved.