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ピッチにうまく載り実装しやすいのでねむいさんのお勧めです★
ギガヘルツ帯レシーバーを作成する際は皆さんご存知の通り配線そのものも
極めて大きく影響してきます。先に紹介した三端子コンデンサもただぶっこめば
おkと言う簡単な代物ではなく、グランドプレーンを流れる電流の経路、
デバイスの電流の吸い込み吐き出しを理解した配置を行わないと逆にノイズを
パワーアップさせてしまう事態になってしまいます。
ムラタ製作所さん他各社から三端子コンデンサやノイズ対策技術の使い方の
ノウハウが無償で公開されておりますのでそれらを熟読してしっかり作りこみ
ましょう!
今回は電流プローブで捕捉/追跡動作時の電流波形も採ってみました。
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からバリバリ書き込み/デバッグが出来てます。
のチップしか使ってはならない"っていう規約的に使用不可であることを示す文面は
どこにも見当たらないのでねむいさんみたいな使い方しても全く問題ないでしょう。
問題あったら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は余計な
プロテクトは全くないので失敗を恐れずいろいろ試すことが出来るので、
なかなかいじりがいがあるボードだと思います!
-
免責・連絡先は↑のリンクを
↓SNSもやってます↓
powered by まめわざ- ARM/STM32 (117)
- OpenOCD (27)
- ARM/NxP (34)
- ARM/Cypress (5)
- ARM/Others (3)
- ARM/Raspi (1)
- AVR (13)
- FPGA (4)
- GPS/GNSS (19)
- MISC (80)
- 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)
- 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 (7)
- May 2009 (14)
- January 1970 (1)
Copyright(C) B-Blog project All rights reserved.