OpenOCD小ネタ7 -JTAGKey2でSWDできるじゃない！-

20140708追：
ついにSWDに正式対応しました！
20140708追：



ここ数日OpenOCDのgerritにVersaloonのSWDサポートの修正が盛んに
あげられていて、私もいろいろﾖｲｼｮしております。同時に汎用のSWDドライバも
見直されどんどん変化しております。
その矢先になんかすごいの来てました。FTDIデバイスのSWD対応です！
しかも結線がめっちゃ簡単でJTAGKey2(Compatible)系のバッファがついたもの
でも極めて簡単な回路の追加でSWDれます♥

本来FTDIデバイスのSWD対応については約一年前、libswdというのがコミットに
当たりかけていたのですが実装に関する思想をめぐりくだらない激論となり
スクラップ状態で放り投げられていました。今回の奴はそれとは別のアプローチ
で実装された物のようです。末端ユーザーの私たちとしましてはちゃんと
動作して恩恵が受けられるのかが大事です。


そんな訳で早速試してみました！コードレビューにはJTAGで言うTDIとTDOの
間にトライステートバッファをおいてnTRSTでOEを制御してターゲットの
SWDIOと接続すべしと書かれております。SWCLKに関してはそのまんまTCKに
つなげばOKです。さらに"トライステートバッファ噛ますのめどいんなら
220~470ohmくらいの抵抗でワイヤードORでもいけるかもね"とさえ書かれて
いました。


もちろん私はお気楽に510ohmのカーボン抵抗でワイヤードOR作戦です。
当たり前ですがTDIが直接ターゲットのSWDIOに来てショートしないように
抵抗を配置してください。
(私のJTAGKey2Compatibleの回路はそれでも素子の即死はしないように配慮してます)

今回の実験対象はSWDのみ接続可能なNuvotonのCortex-M0コアの
Nano130SE3です。このマイコンも以前からちらっとお見せしていますが
NuvotonネタはFM3の修正がコミットされたら一気に攻めるので今は
まだ脇役なのです。もう少しお待ちください。
JTAGkey2はVref必須故にVersaloonの+3.3Vを拝借してターゲットに
供給しております。使用するOpenOCDは現在の最新のコミットベースの
Versaloon-SWD対応版と、同じく最新のコミットベースで
上記のコードレビューからCheckoutしてきたFTDI-SWD対応版＋αの
OpenOCDバイナリをそれぞれビルドし、VersaloonとJTAGKey2で
同一のelfファイルの書き込みとベリファイ速度を比較します。

↓んでこんなん出ました。
*JTAGKey2-SWD



> "C:¥Devz¥Coreutils¥bin¥make.exe" program

openocd -s C:/Devz/ARM/OCD/tcl -f interface/ftdi/jtagkey2.cfg -c "transport select swd" -f target/nano130se_swd_flash.cfg -c "mt_flash main.elf"

Open On-Chip Debugger 0.8.0-dev-00358-g5b3885f-dirty (2014-02-19-17:22)

Licensed under GNU GPL v2

For bug reports, read

	http://openocd.sourceforge.net/doc/doxygen/bugs.html

Info : Init SWD

swd

none separate

Info : add flash_bank nuc1x nano130se3.flash

adapter speed: 1000 kHz

cortex_m reset_config sysresetreq

Info : JTAG->SWD

Info : clock speed 1000 kHz

Info : SWD IDCODE 0x0bb11477

Info : nano130se3.cpu: hardware has 4 breakpoints, 2 watchpoints

target state: halted

target halted due to debug-request, current mode: Thread 

xPSR: 0xc1000000 pc: 0x000006ec msp: 0x20004000

auto erase enabled

Info : DeviceID : 0x00113034

Info : Detect NANO130SE3AN!

Info : Nuvoton NUC: Sector Erase ... (0 to 39)

Info : Nuvoton NUC: FLASH Write ...

wrote 20480 bytes from file main.elf in 2.452780s (8.154 KiB/s)

verified 20240 bytes in 0.203096s (97.322 KiB/s)

target state: halted

target halted due to debug-request, current mode: Thread 

xPSR: 0xc1000000 pc: 0x000006ec msp: 0x20004000

shutdown command invoked



> Process Exit Code: 0

> Time Taken: 00:04



*Versaloon-SWD


> "C:¥Devz¥Coreutils¥bin¥make.exe" program

openocd -s C:/Devz/ARM/OCD/tcl -f interface/vsllink_swd.cfg -f target/nano130se_swd_flash.cfg -c "mt_flash main.elf"

Open On-Chip Debugger 0.8.0-dev-00350-g6c74255-dirty (2014-02-19-11:18)

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 nuc1x nano130se3.flash

adapter speed: 1000 kHz

cortex_m reset_config sysresetreq

Info : Versaloon(0x15)by Simon(compiled on Sep  5 2013)

Info : USB_TO_XXX abilities: 0x0000176E:0x010001EF:0xC0000007

Info : clock speed 1000 kHz

Info : SW-DP IDCODE: 0x0bb11477

Info : nano130se3.cpu: hardware has 4 breakpoints, 2 watchpoints

target state: halted

target halted due to debug-request, current mode: Thread 

xPSR: 0xc1000000 pc: 0x000006ec msp: 0x20004000

auto erase enabled

Info : DeviceID : 0x00113034

Info : Detect NANO130SE3AN!

Info : Nuvoton NUC: Sector Erase ... (0 to 39)

Info : Nuvoton NUC: FLASH Write ...

wrote 20480 bytes from file main.elf in 1.905981s (10.493 KiB/s)

verified 20240 bytes in 0.203097s (97.321 KiB/s)

target state: halted

target halted due to debug-request, current mode: Thread 

xPSR: 0xc1000000 pc: 0x000006ec msp: 0x20004000

shutdown command invoked



> Process Exit Code: 0

> Time Taken: 00:02


ログも微妙に違いますが書き込みベリファイの速度に注目すると…
JTAGKey2-SWDが
wrote 20480 bytes from file main.elf in 2.452780s (8.154 KiB/s)
verified 20240 bytes in 0.203096s (97.322 KiB/s)
Versaloon-SWDは
wrote 20480 bytes from file main.elf in 1.905981s (10.493 KiB/s)
verified 20240 bytes in 0.203097s (97.321 KiB/s)
となり、JTAGKey2-SWDの方は書き込みでは2割ほどパフォーマンスが
落ちますがまだコードが練られてない段階ながらも十分実用レベルで
使用可能なことが分かりました♥
ついでにトライステートバッファによる制御がなくても抵抗一本でお手軽に
既存のFT2232系のJTAGデバッガがSWDにも対応できるのでなんというか
CMSIS-DAPとは一体何だったのか感すらあります。

というわけでまだまだコードの手直しが必要な段階ですがFTDIデバイスの
SWD対応はシンプルかつ強力なポテンシャルを秘めていると言えるでしょう！

トラ技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!!!!!!

OpenOCD小ネタ6 -kinetisドライバの修正その他-

世間様ではトラ技ライタの話でもちきりですが私は毎年恒例の2/9のいないさんの
聖誕生日に向けたブツをずっとこもりっきりで作っていたのでOpenOCDの
ネタが溜りまくっております。
周りに流されず粛々と消化していきますよぅ〜







●エンバグようやく直る(誰も気づかんかったんかい！)
少し前の話ですがkinetisドライバに作りこまれてしまったバグの修正をgerritに投げ、
マージされております。私もgerritにだいぶ慣れてきました♥

Kinetis-Kシリーズは同じ号数(たとえばK20、K60等)でも動作周波数の
上限の違いでフラッシュのセクタ構成が大幅に違いますのでソフトに落とす
際は厳重な注意が必要ですね。私もユーザーマニュアルを首っ引きで現時点で
分かりうる範囲で全てのセクタ構成のパタンを書き倒してやりましたよ！

尤も私が去年Lシリーズへの対応を試みた時は元のコードはもう少しスマートに
セクタ構成を判別する仕組みをとっていました。"guranuarity"と呼ばれる
その値は上で述べたセクタ構成を示し、RDIDレジスタの特定のビットに反映されて
おりました。しかし、その明確な定義についてマニュアルには一切書かれて
おらず、いわゆる裏ワザ的コーディング扱いされていました。
そういうわけでマニュアルを斜め読みした別の人にこういうのよくないよー
(地獄のミサワみたいな顔で)と言わんばかりに中途半端にハードコードされた値が
いいかげんに設定されてしまいエンバグになってしまったわけです。

私もkinetisから離れて居たので気づかず別の外人さんの"K20で
書き込めない!1!1!!!"という質問メールで漸くエンバグされたのに
気づいて冒頭のとおりぱっちをgerritにブン投げたわけですよF**K!
私は悪くねぇ！
なお、上記問題はKL25等のKinetis-Lシリーズには全く影響がなかった
のでご安心を。
あなたがKL25Zに急に書き込め無くなったのは100%これが原因です。

これから先は従来のFMCとはコマンド体系がガラッと変わったKinetis-Eシリーズ
等も控えていますのでさらに複雑化と混乱が予想されます…。それに入手が
容易で人気があるマイコンは修正が他の人とバッティングする状況が
よくありますので他のコントリビューターの人とも綿密に意思疎通を
行うことも非常に重要です。
疎通ができなかった場合nuvotonドライバが2つ出来てしまうことになりますorz
(↑nuvotonの件に関しては次回にでも詳しく…)



●libusbxがlibusb-1.0に
私はlibusb-1.0準拠のlibusbxを従来から使用しておりました。libusb-1.0の
オリジナルにはない機能や修正がたくさんあたっております。
ところが1月下旬にlibusbxが1.0.18でファイナルリリースになり、以後は
libusb-1.0の本流として修正が続けられることになりました。

そうなったいざこざがここにありました。もめごとの陰にはあの男ありです。
私も変な突っ込み喰らわないようにOpenOCDのパッチを投げる際は
細心の注意を払っています。

それはさておき現在私がぶろぐ上で配布しているlibusb-1.0を使用するバイナリ
は全てlibusbxから"x"が取れたlibusb-1.0.18の自前ビルドしたdllをバインド
しております。
もちろんAsmediaのxHCI対策のパッチも適用済ですのでUSB3.0でも問題なしです♥



●libftdiも1.1に
libftdiの1.x系もバージョンアップし、めでたくlibftdi1.1になりました。
こちらに関しては特に記すべきことはないのですが無理やり話題を作りますと…
libftdiは1.0に上がったころから(0系のファイナルは0.20)ライブラリや
プログラムのビルドにCMAKEとかいうのの使用を強制するようになっています。
従来のconfigure->makeのお手軽コンボとは全く違う概念だったのでブツを
作り出せるようになるまで苦労しました。

しかも1.0に切り替わった直後はMSYS向けにはコンフィグがまともに整備
されていなくてあーでもないこーでもないを繰り返してやっとlibftdi1.dllを
ビルドできた涙ぐましい記憶があります…(しみじみ。
現在ではMsys/MinGWのコンフィグ周りも見直されて手直し無しに一発ビルドアウト
出来るようになっております♥もちろんこちらもバインド済です♥



●OpenOCDにバインドされているDLLのまとめ
現在私が配布しているOpenOCDのバイナリは上記を含めた各種dllを
バインドしております。
どれ一つ欠けてもOpenOCDが起動しませんのでご注意ください。また、他の方が
ビルドしたOpenOCDバイナリに差し替えてもそのまま動かすことができますが、
一方でその逆の行為はおそらく一切できませんので理解したうえでご使用
願います！！

libusb0.dll
->libusb-win32-bin-1.2.6.0から抽出
libusb-1.0.dll
->libusb1.0.xxを自前ビルド(+AsmediaのUSB3.0(xHCI)対策済)
libftdi1.dll
->libftdi1.xを自前ビルド
(以前はlibftdi1.dllをlibftdi.dllにリネームしていました)
libhidapi-0.dll
->hidapiを自前ビルド

各ライブラリのライセンスもOpenOCDの"licenses"にありますのでご参考に。


libusb-1.0.dllはAsmedia対策をしてるのでOpenOCDと全く関係ない方からも
需要があるようです。おそらくUSB3.0ホストの問題、この先もわらわら出て
きそうです…



●罪なき人の平和な日曜日を破壊するねむいさん
ごめんなさいごめんなさい！！！…まさか使ってくれてる人がいたとは…
20140210現在はちゃんと内部RCから144MHzに上げるようにスクリプト変えてます
のでご安心を…あと128kByte以下のフラッシュ容量のFM3マイコンではクロックを
叩き上げるのはあんましうま味が無く逆にデメリットしかないので無理に
クロックは上げないでノーマルで書き込んだ方が効率がいいです。



●ついに日本人で私以外の犠牲者が…
oh...my...
これの問題ですが、MSC経由でKL25Zとかに書き込むときにsrecじゃなくてelfを
D&Dで放り込んじゃうとどうやらelfファイルをパースせずにそのままbinファイル扱い
で書き込みやがるからみたいですね…#
まさにクラウドの落とし穴です！

これelfファイルのFSEC番地が0xFFならまだ救済措置はありますが0xEFなら
完全終了
ですね…私からのアドバイスですがKL25Zをmbed版CMSIS-DAPにしてOpenOCDから
MDM-APのmass-eraseをやってみてください。
もしかしてまだ回復できる可能性があります。また、SRSTの操作がmass-eraseに
必須なので必ず繋げてくださいね(Kinetisのハード的な仕様です)。

Go to top of page