ねむいさんのぶろぐ

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" program

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

OpenOCDでフラッシュ書き込みした時のログはこんな感じです。

かつて幾つかの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で行うべきです。

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-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に喰われました！

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の通信を介さず
ターゲット上で書き込みプログラムが実行されます。通信のオーバーヘッドが
無いのでもちろん書き込み動作はとしては非常に早くなります♥

同じelfファイルの書き込み速度だけ抽出しましたが、書き込みスピードは
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に喰われました！

え？これは何って！？
さぁ…あ、あたしの弟がぁ…かってにぃエントリしちゃって～
ま、まぁねむいさんセフィロス派ですが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に喰われました！
"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を使ってプログラムを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の
バイナリはこのパッチを適用しています。(下述の書き込みスクリプトも同梱してます)

今回使用するデバッガハードウエアは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-ROMが使えるインターフェース"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についての記事です。

前回述べたとおり秋月さんよりDIP版LPC1114が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のままでも
ふつーに動きました…STM32F107VBTみたく隠しで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を使いこなすのだッ！

↑接写できるコンデジに買い替えたのでむやみに接写
　…駄目だ上手く撮れない

追：おきぱを改修しました。
　　それに伴いSTM32,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の記述入れて
たりChecksumValitdateを直打ちな人は不整合が起こらないようにしなければ
なりません。あと見落としづらいのが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互換なミニボードだそうです。周辺が全くない代わりに
　ほぼすべてのI/Oが外部に引き出されています。

↑即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 ata 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リセプタクルがｶﾞ●ｶﾞ●ﾏ●ｺｲになったので付け替えた。

考察:
(今日の日記のタイトル)

<< November 2024 >>

Sun Mon Tue Wed Thu Fri Sat

1 2

3 4 5 6 7 8 9

10 11 12 13 14 15 16

17 18 19 20 21 22 23

24 25 26 27 28 29 30
- ネムイ・トリノミアス
Foreign Visitors,See This First

免責・連絡先は↑のリンクを

ChaN's FatFs Projects and
OpenOCD Binary are Here.
おきぱはここ！

↓SNSもやってます↓
powered by まめわざ

- ARM/STM32 (116)
- OpenOCD (27)
- ARM/NxP (34)
- ARM/Cypress (5)
- ARM/Others (3)
- ARM/Raspi (1)
- AVR (13)
- FPGA (4)
- GPS/GNSS (19)
- MISC (81)
- STM8 (2)
- Wirelessなアレ (16)
- おきぱ (1)
- ブラウザベンチマーク (28)
- 日本の自然歩道 (25)
- STM32U0はぢめました
  ⇒ ねむい (08/07)
- STM32U0はぢめました
  ⇒ ひかわ (07/28)
- STM32H5を使ってみる3 -待ち受ける初見殺しの罠たち-
  ⇒ ねむい (05/17)
- STM32H5を使ってみる3 -待ち受ける初見殺しの罠たち-
  ⇒ どじょりん (05/16)
- STM32H5を使ってみる3 -待ち受ける初見殺しの罠たち-
  ⇒ どじょりん (05/16)
- いろいろ試す61(と今年の反省会)
  ⇒ ねむい (01/02)
- いろいろ試す61(と今年の反省会)
  ⇒ ひかわ (01/02)
- いろいろ試す61(と今年の反省会)
  ⇒ ひかわ (01/01)
- STM32H5を使ってみる3 -待ち受ける初見殺しの罠たち-
  ⇒ ねむい (12/31)
- STM32H5を使ってみる3 -待ち受ける初見殺しの罠たち-
  ⇒ ひかわ (12/31)
- October 2024 (1)
- September 2024 (1)
- August 2024 (1)
- July 2024 (1)
- June 2024 (1)
- May 2024 (1)
- April 2024 (1)
- March 2024 (1)
- February 2024 (2)
- January 2024 (1)
- December 2023 (4)
- November 2023 (2)
- October 2023 (2)
- September 2023 (1)
- August 2023 (2)
- July 2023 (1)
- June 2023 (2)
- 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 (6)
- May 2009 (14)
- January 1970 (1)

<< November 2024 >>
Sun	Mon	Tue	Wed	Thu	Fri	Sat
					1	2
3	4	5	6	7	8	9
10	11	12	13	14	15	16
17	18	19	20	21	22	23
24	25	26	27	28	29	30