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の書き込みには成功してたり
しますが、こちらもアトミックに書き込みできるようになったら別枠でご報告と
させていただきます！

GPS/GNSSモジュールを試用する9

20230822追:
最強のGNSSモジュールSAM-M10Qをゲットせよ！
20230822追:



すでに静岡ステージにて実践投入開始しちゃっていますがGLONASS対応の
GNSSモジュールのGms-g9を入手し比較試験を行いましたのでご報告
させていただきます。


Gms-g9は前回紹介したGms-g6aのパッチアンテナ版です。中のチップは
MT3333なので基本的な操作に関しては前回とほぼ同一です。
ただ、感度の高いパッチアンテナが付いたモデルなので
森深い山中でも活躍しそうです。


恒例のモジュール性能比較です。後で写真をお見せしますがPA6Cと比べると
一回り大きく、かつてのUP-501と同じくらいの大きさです。あとGLONASS
(年末にはGALILEOも対応になるそうですが)の処理が追加されているので
消費電流が3~4mAほど増加してます。



Gms-g9のVCCの入力はご多忙にもれず極力綺麗な電圧を供給しなければなりません。
今回も秋月さんとこで入手できる三端子コンデンサを駆使し規定を見たしました。
この子は2.54mmピッチにうまく載り実装しやすいのでねむいさんのお勧めです★

ギガヘルツ帯レシーバーを作成する際は皆さんご存知の通り配線そのものも
極めて大きく影響してきます。先に紹介した三端子コンデンサもただぶっこめば
おｋと言う簡単な代物ではなく、グランドプレーンを流れる電流の経路、
デバイスの電流の吸い込み吐き出しを理解した配置を行わないと逆にノイズを
パワーアップさせてしまう事態になってしまいます。
ムラタ製作所さん他各社から三端子コンデンサやノイズ対策技術の使い方の
ノウハウが無償で公開されておりますのでそれらを熟読してしっかり作りこみ
ましょう！




今回は電流プローブで捕捉/追跡動作時の電流波形も採ってみました。
1mSecごとに重たい処理してる感じですね。GLONASSも捕まえてましたが
カタログ値より若干低めにでてました。



お次はフィールド試験です。まずPA6Cとの基本性能の比較を行いました。

大阪城公園のお濠の脇にある天守閣がちらっと見えるベンチ上でベンチを
とり補足時間やDOPの比較をおこないました…が当日はあいにくのくもりで
しかも上記画像の通りQZSS(みちびき)は天頂になく測位に使えないという
悪条件下！！

で、こんなん出ました。
御覧の通り明らかに捕捉/測位性能は上回ってますね(HOTでは負けてますが)。
GLONASSが取れるのとパッチアンテナの面積がでかいのが効いていると思われます。



フィールド試験第二弾はGPSロガーとして使用した時のランニングテストです。
比較対象のロガーとしてGP101を今回も使用しました。
軌跡表示はカシミール3Dを使い、国土地理院の1/4500地図上に表示しています。
GoogleEarthがGN系センテンスを解釈できずBSOD(←F**K!)てしまうのでこちらに
乗り換えました。


ルートは近鉄枚岡駅から暗峠を越えて南生駒駅に至る超メジャーなハイキングコース
です…がここは暗越奈良街道の一部で立派な国道であります。それではスタート！


最初に枚岡神社に寄ってから国道308号(暗越奈良街道)を進みます。
この辺りは住宅が多いですがまだ空があいてるのでどっこいどっこいですね。


道はやがて勾配が急になっていき森の中を縫い進むようになります。
Gms-g9の方はいい感じに道をとらえてますね。やはり深い森の中で真価を発揮して
きましたよ♥


暗峠近くになると勾配も収まり視界が開けます。ちなみにこの308号線は日中は
乗用車もびしばし通る道なので通行にはご注意を…。

ちょっとここで一休み…。

暗峠手前の道です。※ここは立派な国道です。



暗峠です。歩行者にとってはどうってことないですが乗物乗ってる人はこの石畳が
曲者だと思います。また奈良側の勾配がかなりあり、ボディの長い車は体が
引っかかって峠を越えられません(実際に注意書きがあります)。


奈良側に回って大阪側を見ます。暗峠の昔の石碑も残ってます。
画像の左から電磁波が出てる気がするしますがたぶん気のせいでしょう…たぶん


GPSの軌跡や上の画像見たらお分かりでしょうけどもここは生駒山への
縦走路にもなっています。
…ねむいさんおそらくここに再び来るかも…。



ちょうどお昼時なので峠にある茶屋でかき氷を食べてきました。
もう夏ですね〜…トレランの時はいつも時間に追われていたので久しぶりに
山(ていうか峠か)でゆっくりできました。


この後一気に峠を下るのでお土産は見送りました…しくしく。


たっぷり休憩を取った後は奈良(生駒)側を駆け下ります。
奈良側は見事な棚田が広がっていますね。


GPSレシーバーは取得る電波の周波数の特性上山の斜面にある道では電波の
反射により非常に捕捉精度が悪くなる傾向があります。
残念ながらGms-g9の性能を持ってもちょっときついようですね。


※ここは車は通行不可になってますが立派な国道です。
それと見慣れた伊勢参りの札がありますがここも伊勢本街道なの…？


道の勾配も収まりやがて住宅街に混ざります。こういう場所もGPSは非常に
苦手です。それでもGms-g9さんは仕事をしっかりしていた！！


龍田川を越えたあと奈良街道と別れ南生駒駅に到着してゴールとしました。
奈良街道はこの先もまだ続きます。



というわけでGms-g9の威力を存分に味わって今回のテスト終了〜ってことで
京都に帰ろうと思いましたが、思いのほか早く終わってしまったために
もうちょっと散策してみました。まずは電車で王寺にむかって…



王寺駅から新王寺駅に…何故かこの区間は同じ近鉄なのに駅がつながってなくて
歩いて移動する羽目になる場所です…。



電車でゆられて西田原本駅につきそこから歩いて田原本駅に…何故かこの区間は
同じ近鉄なのに駅(ry



桜井駅まできました。
向かうは2年前の真夏に激闘した山の辺の道(東海自然歩道)です。



初瀬川(大和川)にかかる橋を渡り仏教伝来の地の碑がある左側が山の辺の
道の起点/終点です。



2年前に通過した道をさかのぼります。
"→コば市"も健在！


曇ってて良く分からない…



三輪山平等寺の横手から境内に入ります。



ふと見るとベンチに猫ちゃんが寝ていました。
もふもふしても起きず無防備すぎる…。



聖徳太子像の側にも…。
同じく隙だらけすぎる…。


大神神社です。
ねむいさんもしっかりお参りしました。


このあとさらに北上して狭井神社へ。目的は‥。



御神水です。
しかも妙にハイテクでボタン押すと出てくる御神水供給ディバイスに
なってます！！



そしてこれが実物です！
新古一体となった美しささえありますね…。


さて、ペットボトルにたんまり詰め込んで帰ろうか〜
と思ったのですが今さらですが桜井駅以後のGPSロガーの電源を入れるの
忘れてたのでこっから比較再試験開始!


まぁすぐに三輪駅に着いちゃうんですけどね。



誘惑に負けて買ってしまった…
日本酒アイスはクリームと相性悪くてどうしてもパサパサした見た目に
なっちゃいますね〜…これで色が茶色系だったら…ｹﾞﾌﾝｹﾞﾌﾌﾝ
あ あ 美 味 し か っ た ♥


…

Gms-g9は立ち上がりの再捕捉性能がすごくいいんですよね〜。
そんなわけでこれからGPSモジュールを購入される方はGms-g9をお勧めします。

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は余計な
プロテクトは全くないので失敗を恐れずいろいろ試すことが出来るので、
なかなかいじりがいがあるボードだと思います！

Go to top of page