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に関してはそのまんまTCLKにつなげば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で行うべきです。
20140213追：
なひたふさんも全く同じことを指摘していますね
↑一応記しておきますが…なひたふさんと偶然同時刻に偶然同じ事実を指摘しただけです。
　私は自分の記事を書くのに夢中でなひたふさんのブログエントリを全く見ておらず、
　一切パクってませんのであしからず！
↑ってしっかり念押ししとかないと斜め読みする人にtwitter上で有ること無いこと流されそうですので

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