ねむいさんのぶろぐ

OpenOCD小ネタ12 -HLA向けのcfgファイルの統合-

お盆前に行われたOpenOCDのHLA系コンフィグファイル大変更への対応を幾つかのター
ゲット向けの試用実例と交えて解説します。とその前に！
最近再び似た質問を多数いただくようになったので･･･

●STLinkがOpenOCDで動きません。
NxP系マイコンのCheckSumValidationと同じく何度も言ってますが何度でもおさらいです。
質問が続く限り何度でもなんどでも　な・ん・ど・で・も　説明します！
注:STLink/V1はもう持ってないのでサポート外です。STLink/V2とSTLink/V2-1系向けです。

20140902追：
2014年9月現在、Windows8.x系環境下でSTLink/V2-1がOpenOCDから
利用できません。これはlibusbがWin8.x環境下でUSBコンポジットデバイスを
正しく扱えてないことに起因するものだそうです。
libusbに修正かかるまで辛抱強く待つかXP/Win7に戻すのです！！
STLink/V2の方はコンポジットじゃないのでWin8でも問題なく使用可能です。

20141114追：
Windows8.x環境下でのOpenOCDサポート開始です

１．基本的な結線は本当に正しいか
STLink/V2系はSRST,Vtgt(ターゲットのVCC),SWCLK,SWDIO,GNDが必須です。
SWCLKとSWDIOを"てれこ"にしてたりGND繋げてなかったとか論外ですが(そういった
ケースもありました…私に直接返信はなく質問された方のtwitter上の発言でそれ知っ
たのですが…＃)まず第一にGND,SWCLK,SWDIOの結線がターゲットのMCUと正しくなさ
れているかを回路図を良く見てテスターで導通をしっかり確認してください。

２．SRSTは繋がっているか
現在ではNucleo/Discovery等のメーカ製評価ボード向けの特製cfgはすべてSRSTを使用
するように設定されています。したがって私の特製cfgもそれに準じております。
stlink-v2.cfgを直接呼び出す使い方を中途半端に真似ると引っかかるのでご注意ください。
Nucleo/Discovery等のメーカ製評価ボードから自作のボードに環境を変えた際にSRSTの
接続を忘れ上手く動かないといった連絡を特に戴いています。
回路図を良く見てテスターで導(ry

３．Vtgtは繋がっているか
また、Vtgtの接続もほぼ必須です。これも"２．"と同様ですが特にNucleo/Discovery等の
メーカ製評価ボードからデバッグ線を引き出して自前のボードと繋げる際に発生します。
ネット上では情報が倒錯しOpenOCDではVtgt必要ないと断言している記述もあるので
ご注意ください。ねむいさんは一貫してVtgt繋げろです。

STLink/V2は接続の際にまずSWCLK,SWDIOの電圧を読みに行ってVtgtの電圧よりも
相対的に高い電圧とみなすとその後の一切を弾くのでコケて絶対先に進めません。これは
ファームウエアレベルでこういう動作をしますので特定のソフトに依存はしません。

メーカ製ボード上ではVDDがSBDで切られてVf分のドロップで3.0V前後と若干低くなった
状態で動作しているので気づきません。しかしながら自作のボードではほとんどが3.3V
で使用されるともいます。このときSWCLK/SWDIOの電圧はデバッガ側より必ず大きく
なるのでコケます。

また、以前も触れましたが一部のボードではコスト削減のためVtgtにつながる抵抗が実装
されていないものもあります。ケアレスミスで時間を浪費しないように回路図を良く見(ｒｙ

･･･
STLiink系ばっかりに力入れるわけにはいかないので本題に入ります。

●分かれていたコンフィグファイルが今一つに！
これです。目的はSTLink/V2やTI-ICDI等のHLA(HighLevelAdapter)も従来のFTDI/JLink等
と同じコンフィグファイルを使用できるようにする修正です。

もともとHLAは各メーカが提供する独自のデバッグ用APIをOpenOCDでも利用できるようにと
組み込まれた機構です。したがってターゲットMCUへのローレベルなアクセスができない、
クロック周波数の設定等のアダプタ側でも細かい制御もできないといった制約があります。
ですのでその挙動の違いから使用可能なコマンドも分けられており、従来は各MCU向けの
OpenOCDコンフィグファイルも通常のものとHLA系に分けなければなりませんでした。

しかし今回の修正でHLA系で使うとエラーになっていたadi_v5系のローレベルのコマンドが
エラーとならずオーバーライド(スルーとも言う)できるようになり、hla専用cfgは晴れて
お役御免となったわけです。

さて、変更されて箇所は分かりましたがそれを実際にどう反映させればよいかというと･･･
OpenOCDを呼び出す際の引数として、もしくはcfgファイル内に"transport select"コマンド
を追加で付与します。以前はHLA系アダプタを使用する場合はトランスポートが決め打ち
だったのでSTLink/V2やTI-ICDIのcfgファイルに直接記述されていた物が外に追いやられた
形になってます。EFM32TG822F32の例を取って新旧のOpenOCD引数比較をします。
下記の記述はこちらのデバッグ手順に準じますので事前に把握をお願いします。

旧：
OCD_ARG = -s $(OCDIR)/tcl ¥
-f interface/stlink-v2.cfg ¥
-f target/efm32tg822f32_hla_flash.cfg
新：
OCD_ARG = -s $(OCDIR)/tcl ¥
-f interface/stlink-v2.cfg ¥
-c "transport select hla_swd" ¥
-f target/efm32tg822f32_swd_flash.cfg

こんだけです。TI-ICDIの場合はJTAG接続専用なので"hla_jtag"になります。
STLink/V2,STLink/V2-1はSWD専用なので"hla_swd"です。

メーカ製出来合いのボードの場合、OpenOCDのボート向けcfgで対策されたのがほとんど
なのでこちらで修正する必要はないです。Nucleo-R334板(STLink/V2-1付)の例を示します。
旧：
OCD_ARG = -s $(OCDIR)/tcl ¥
-f target/nucleo-f3_flash.cfg
新(旧と全く同じ)：
OCD_ARG = -s $(OCDIR)/tcl ¥
-f target/nucleo-f3_flash.cfg

因みにcmsis-dapの場合も現状SWD専用なのでswdが自動で選択されるので特に変更は
不要です。トラ技ライタ(LPC11U35)にCMSIS-DAPで繋げる例を示します。
旧：
OCD_ARG = -s $(OCDIR)/tcl ¥
-f interface/cmsis-dap.cfg ¥
-f target/lpc11xxx_swd_flash.cfg
新(旧と全く同じ)：
OCD_ARG = -s $(OCDIR)/tcl ¥
-f interface/cmsis-dap.cfg ¥
-f target/lpc11xxx_swd_flash.cfg

さらにJTAGKey2等の汎用のJTAGの場合は何も指定しない時はデフォルトでJTAG接続
となるので余計な指定は不要です。STM32F407ZGT6にJTAGKey2で繋げる例を示します。
旧：
OCD_ARG = -s $(OCDIR)/tcl ¥
-f interface/ftdi/jtagkey2.cfg ¥
-f target/stm32f4x_flash.cfg
新(旧と全く同じ)：
OCD_ARG = -s $(OCDIR)/tcl ¥
-f interface/ftdi/jtagkey2.cfg ¥
-f target/stm32f4x_flash.cfg

JLINKやVersaloon,FT2232系でSWDしたい場合は宣言は必須ですがこの3つに関しては
私のcfgレベルで対策済なので私が提供するバイナリとcfgを使う限りは変更不要です。
STM32F407ZGT6にVersaloonで繋げる例を示します。
旧：
OCD_ARG = -s $(OCDIR)/tcl ¥
-f interface/vsllink_swd.cfg ¥
-f target/stm32f4x_flash.cfg
新(旧と全く同じ)：
OCD_ARG = -s $(OCDIR)/tcl ¥
-f interface/vsllink_swd.cfg ¥
-f target/stm32f4x_flash.cfg

現在のOpenOCDでは以下の4つのtransportが存在していますが、hla系は上記の要領で
多少の変更を追加するだけで対応可能となっています。
transport select jtag (transportを何も指定しないときのデフォルト)
->FT2232系,JLINK系,Versaloon,その他多くのJTAGデバイス
transport select swd
->FT2232系,JLINK系,Versaloon,CMSIS-DAP
transport select hla_swd
->STLink/V2,STLink/V2-1
transport select hla_jtag
->TI-ICDI

なお、今回の統合でSWD接続においてレグレッション・テストを行っていなかったようで
SWDでエラーが発生してしまいました。私はお盆前に自作のパッチを適用したバイナリを
公開していましたが現在はこの問題に気付いた方が別のアプローチからパッチを提出し
マージされております。LPC17xx系でDAPIDの問題が残ってますがマイナーな問題なので
時期に修正されると思います。

現在はすべてのtransportでスムーズにOpenOCDが利用できます。あとは微妙に残ってる
JTAG依存な処理の完全切り離しとSWDのSRSTコントロールの最適化が達成できたら
OpenOCD導入のハードルは下がると思います。

というわけでおきぱにあるOpenOCDバイナリもどしどしご利用ください！

OpenOCD小ネタ11 -EFM32 ZeroGeckoとJLinkのSWD接続正式対応-

以前ちらっとお見せしましたがEFM32のZeroGeckoシリーズの評価ボードをだいぶ前に
手に入れて、評価しております。

MCUにはおなじみトカゲのマークがあります。Cortex-M0+コアを持つEFM32ZG222F32が
搭載されています。

ボードは低消費電力のアプリ作成を意識したものになっていて搭載されている液晶も
メモリ液晶と呼ばれる超低消費電力なものとなっています。

最初に書き込まれているプログラムは、メモリ液晶を利用したインベーダーもどきなゲームを
遊ぶことができます。なおこのゲーム、一機死んだら即ゲームオーバーなかなりシビアな
代物です！！！

今回の記事に合わせ、私が基本としているLED&UARTなEFM32評価ボード向けのGCC
プロジェクトも作成しております。低消費電力モードは使わず極めてシンプルな代物です。

また、以前もふれましたがOpenOCDからもEFM32ZGシリーズも書き込みができるように対応
しております。EFM32自身はSW-DPしか持たないので書き込み/デバッグするためにはSWD
接続可能なアダプタが必要となりますが現在ではSTLink/V2,JTAGKey2,Versaloon、そして
後で述べるJLinkがSWD接続対応のデバッガアダプタとしてOpenOCDから使用可能になって
おりますので不自由はしないでしょう。

こちらは素組みのEFM32ZG板をSWD接続版のJTAGKey2でデバッグしてるところです。
もうおなじみの画面ですね。

話は評価ボードに戻しますがこちらにはJLink-OBと呼ばれる他社向けのMCU評価ボード専用
のJLinkが搭載されております。LPC-Link2等でもほぼ同じ仕組みでオンボードでJLinkをエミュ
レーションしていますが従来、OpenOCDからはJTAG接続だけが可能でした。
したがってSW-DPしか存在しないEFM32ではOpenOCDで書き込みデバッグする際はオンボの
JLinkは無効にしてSTLink/V2やVersaloonのSWD版で使用せざるを得なかったのですが、少し
前にJLinkも正式にSWD接続に対応し、単体でフル活用できるようになっております♥

オンボJLinkでOpenOCDです。JLink純正のドライバじゃないと外部にデバッグプローブを
引き出すことはできませんが私の場合はJLinkエミュが可能なLPc-Link2を所持してるので
通常はlibusb-1.0のみで十分だと思ってます。

ここでOpenOCDでEFM32シリーズを操作するためのコツですが…EFM32はリセット直後の
短い時間の間だけSWDの信号線が別の独自のデバッグプロトコルとして挙動するのでSRST
と組み合わせて操作することができません。したがって"connect under reset"は使用不可
能になります。
誤って低消費電力モードにしてしまうとOpenOCDからの操作ではもう元に戻せなくなり
ますので、くれぐれもご注意ください。

しかしながらEFM32板のオンボJLinkはsegger純正ドライバとEFM32が提供するデバッグ
ツール"energyAware Commander"から独自プロトコルの操作が可能なため、初期状態に
戻すことができるので心配はいりません。

ここまではEFM32とオンボJLinkについて述べてきました。私はJLink化が可能なLPC-Link2
を持っていますのでLPC-Link2にJLinkのファームウエアを再び書き込みこちらも同じように
SWDで接続出来るか試してみたいと思います。

↑ターゲットはトラ技ARMライタという名のLPC11U35板です。
ライセンスの関係上NxP以外の製品で使うところはお見せできませんがOpenOCDでは
ほぼすべてのARMマイコンを書き込みデバッグできる攻守ともに非常にバランスの良い
デバッガアダプタとなりました。

20kBほどの同一のバイナリを同一のUSBポートから書き込んだときのCMSIS-DAPとJlink
エミュとの速度の比較です。
*CMSIS-DAP on LPC-Link2
wrote 20480 bytes from file main.elf in 10.265428s (1.948 KiB/s)
verified 20204 bytes in 0.437491s (45.099 KiB/s)
*JLink on LPC-Link2
wrote 20480 bytes from file main.elf in 2.624950s (7.619 KiB/s)
verified 20204 bytes in 0.265620s (74.281 KiB/s)

CMSIS-DAPファームの時はOpenOCDの実装がせっかくのブロック転送機能をフルに利用
していない残念仕様のためやたらと遅いのですがJlinkエミュならバルク転送がびしばし
使えるので超早いです♥但しSRST/TRSTの操作がちょっと怪しい所があります。
~~seggerの純正のツールではちゃんと操作できるので~~時間を見て両者の挙動の違いを詰め
て行きたいと思います。現状SRSTを必ず要する場面は限られていますのでJLinkエミュ
にしっぱなしの方がサクサク作業を進められると思います。ねむいさんのおすすめです。
(※ただしNxP製品以外の書き込み/デバッグに使っちゃ駄目ですよ！)
20140820追:
F**K

今回は数日前のOpenOCDのコミットでHLA(HighLayerAdapter)系デバッガアダプタのcfgが
一般の物に統合されたというかなり重要なことについてもお伝えしたかったのですが、
JlinkのSWD対応の紹介で長くなりすぎましたので次回じっくりと解説させていただきます。