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対応の紹介で長くなりすぎましたので
次回じっくりと解説させていただきます。

Go to top of page