OpenOCD小ネタ20 - V0.10.0正式リリースされる -

一年前、V0.9.0の次はついにV1.0.0かと思っておりましたが残念ながらV0.10.0に
バージョンアップしていまい、まるで5,4,3,2,1とカウントダウンしたあとに0.9,0.8,0.7
・・・・と続きドリフのコントみたいな展開になっていましたが先日にその
V0.10.0がようやく正式リリースとなりました

今回バージョンアップについて、私の貢献は以下の黄色で囲った部分となります。

NuvotonのNumicroというCortex-M0マイコンの同じドライバが二つもあったので、
それを統合しパワーアップさせました
それとごく一部だけですがKinetisKEシリーズのサポートの面倒も見ました。
私のOpenOCDバイナリにはKEシリーズ書き込み用のスペシャルcfgファイルがあり
ますので(kexx_swd_flash.cfg)ご利用ください★
KinetisKEはOpenOCD対応時の評価用にFRDM板を入手しているので何かの機会に
ご紹介できたらと思います。

その他目立った変更点はJ-Link操作用のライブラリ"libjaylink"がOpenOCDの中に
スタティックに取り込まれたことです。このlib"jay"については昨年からねむいさん
含めたJ-Linkマニアの有志がびしばし改良を重ねておりますが最初はdllの形にて
OpenOCDから呼び出す形式を取っておりましたがOpenOCDとは切っても切り離せ
ない関係のためとうとう内部ライブラリとしてJimTCLと同じように統合される運びと
なりました(オプションで従来通りのDLL化も可能)。
これもいずれは解説記事を書きたいと思います。

あと2015年初頭あたりから目立ってきましたが・・・gerritの使い方が分からなかったり
英文の意志疎通ができないのか私にパッチの提出を代理でしてほしいという不届き
な方の不届きな一方的な連絡を受けることがありちょっと困ってます。
OpenOCDが各種IDEに組み込まれたからでしょうか少しはソース弄れる方が日本人の
間でも徐々に増えてきてるのはうれしいのはやまやまですが…申し訳ありませんが
そういう不届きな方から頂いたパッチはうっかりねむいさんの手柄として提出させて
いただきますので覚悟して下さいね(いやらしい口元で)
んなもん自分でヤレコノヤロなんて心の綺麗なねむいさんは絶対に言えないものでウフフ♥


話は変わりますがこの一年でARMマイコンの情勢も大きく変わりました。FreeScaleが
NxPに喰われ、さらにそのNxPもQualcommに喰われる事態となりダイアログセミコンダ
クターがAtmelを喰うと思ったらなんとPICでおなじみMicroChipがAtmelを食う事態と
なってしまいました!とどめにARMそのものが禿に喰われてもはや上を下への大騒ぎです。

そんなわけで私のぶろぐのエントリメニューがちょっと変わったのにお気づきの
方もいると思いますがブログ記事も時勢に合わせてなるべく最新の状態に保とうと
努力は続けております。昔の記事も手を加えております。

その一方で企業が統合してもマイコンの特性はてんでバラバラなので私が配布して
いるOpenOCDバイナリ付属のすぺしゃるコンフィグファイルにつきましては従来と
同じような感覚で使用できるように整備を続けていく方針です。

V0.11.0以降の私の方針ですが基本的には他の人の提出したぱっちの評価に専念
しますが、新規品種のマイコンのフラッシュドライバを実装できる機会があれば
すぐにでも対応したいと考えております。

以上長々と前置きが長くなりましたが、OpenOCDのWindowsバイナリは逐次更新
してまいりますのでばしばし使ってください!

OpenOCD小ネタ19 -Nuvotonドライバの統合-

今をさかのぼること2年前、いろんな行き違いによって同じNuvotonのCortex-M0向け
フラッシュ書き込みドライバが同時にマージされる事態になってしまいました。

その間もいろいろあってなかなか更新できなかったのですが今秋に両者を統合する
ドライバがマージされたのでようやく報告できた次第です。

さて、この統合されnumicroと名前を変えたこのフラッシュ書き込みドライバは少し
トリッキーな動きをします。それを少し解説します。


●Undocumented Registerの存在
NuvotonのARMマイコンのフラッシュ領域はユーザプログラム用のAPROMとブート
ローダ専用のLDROMの二つがあり、書き換えをするためにはそれぞれ別のフラッシュ
ブートモードから再起動する必要があります。つまりAPROMを書き換えたい場合は
LDROMのブートモードに切り替えコアリセットを掛けるという手間がかかります。
これが公式のマニュアルに記載されている手順です。

しかし!このような煩雑な手順を踏まなくてもどのモードでもAPROM,LDROM,CONFIG
の書き換えそしてチップ全消去コマンドが実行できる方法が解析により見つかっています。
マニュアルに記載されていないレジスタ0x5000C01Cに1を書き込むとフラッシュに対する
全てのアクションが出来てしまうようです。Nu-Linkのツールではこれを自動で行っている
ことから気づき解析されたみたいですね。

そして上記の成果はOpenOCDに反映されましたがこのときはまだmini51シリーズのみ
だったため、私の手持ちの他のシリーズ(NUC120,NUC220,M051,NANOシリーズ等)でも
この技が効くかどうか確認し、OpenOCDの更新が落ち着いたタイミングを見計らって
今回の統合をおこない、無事マージされました。長かった…!


上記の修正を掛けたドライバでNANO130に書いた時のログはこんな感じです。

> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/vsllink_swd.cfg -f target/numicro_swd_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.10.0-dev-00036-g48787e1-dirty (2015-10-02-09:14)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : VSLLink SWD mode enabled
swd
adapter speed: 1000 kHz
none separate
cortex_m reset_config sysresetreq
Info : Versaloon(0x15)by Simon(compiled on Sep 16 2014)
Info : USB_TO_XXX abilities: 0x0000176E:0x010001EF:0xC0000007
Info : clock speed 1000 kHz
Info : SWD IDCODE 0x0bb11477
Info : NuMicro.cpu: hardware has 4 breakpoints, 2 watchpoints
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x21000000 pc: 0x000002d6 msp: 0x20003ff0
auto erase enabled
Info : Device ID: 0x00113034
Info : Device Name: NANO130SE3BN
Info : bank base = 0x00000000, size = 0x0001ec00
Info : Nuvoton NuMicro: Sector Erase ... (0 to 40)
Info : Nuvoton NuMicro: Flash Write ...
wrote 20992 bytes from file main.elf in 4.078360s (5.027 KiB/s)
verified 20800 bytes in 0.281266s (72.218 KiB/s)
shutdown command invoked

> Process Exit Code: 0
> Time Taken: 00:05




一応デバッグもできますが今回の統合に至るまでにnuvotonのドライバの他にadi_v5や
cortex-mのコードにかなりの修正が掛かっており、リセット直後の状態が特殊な
nuvoton系のARMマイコンでは正攻法が通じなくなっていました。
そこで上手くデバッグできるようにcfg側も仕込んでトリッキーなことをしています。
gdbが接続した瞬間にresetとhaltを連続してかけ("reset halt"だと駄目)、さらに
プログラムカウンタを強制的に0にしておきます。


当然割り込みベクタの一番頭で停止しますがここでcontinueすると・・・


無事main関数の頭でブレークしました★
ちなみにOpenOCD側だけでは不完全でプロジェクト側も多少の修正は必要でした。
おきぱNUC120,M0516のプロジェクトはすでに新しいOpenOCDに対応しています。





念のため他の品種も洗ってみたのですがnuvotonドライバだけではなくLPC4300系の
SPIFIの書き込みもおもいくそ影響を受けていて書き込みできてませんでしたorz

↑最後のほうでエラー出てますがコアリセットをソフト的に強制的に掛けてるので
 こうなります。動作としては問題ないです。

こちらも現行のOpenOCDで正しく動作するようにcfgファイルに修正をかけておきました
ので皆さん安心して使い倒すことができると思います。


根幹に近い文字通りコアな部分をひっそり変えられると思わぬところで上手く動か
なくなるのはよくある事なので私の目の黒いうちはしっかり注視していこうと思います。

OpenOCD小ネタ18 -v0.9.0正式リリース-

なんかすっかり一年周期になっちゃってますがOpenOCDのバージョンがようやく上がり、
v0.9.0の正式リリースとなりました!

v0.9.0では使いやすさと安定性がさらに向上し、新規に追加されたARM/MIPSの
各品種のフラッシュ書き込みドライバも追加されています。さらにSTM32-Nucleo
等のデバッガ付き評価ボードのコンフィグファイルたちも充実するようになり、益々
便利となっております。



今回の正式リリースに当たり、私も数多くの貢献をしてきました。


黄色で網掛けした部分が私が手を加えた箇所です。
フラッシュドライバはNxP系の新規品種に力入れてます。

kinetisも一部手を加えておりますがFreeScale公式でも独自にパッチをあてて
FreeScale自身がリリースしているIDEに取り込んでいるようで
これからの発展
が望まれます…がFreeScaleがNxPに吸収されたのでどうなることやら…

2015年現在は完全無料のIDEな開発環境が増えてOpenOCDの出番は全く無くなり
ましたが、私はOpenOCDをARMマイコンのフラッシュ書き込み&デバッグツールとして
これからもびしばしつかってびしばしパッチを上げていくつもりですのでご期待ください。


OpenOCDの慣例として正式バージョンが上がったらgitにあるdev版はバージョンが
一つ上がることになります。私てっきり0.9.0の次は1.0.0になるのかと思ってい
ましたがまさかの0.10.0でしたのでおそらくver1.0.0になるのは90年後くらい
かなと見てます。

おきぱのOpenOCDバイナリは既に0.10.0になったものを上げています。野良ビルドは
信用ならんから使わん
と何度も指摘されてきましたので今回からようやくSHA-1
ハッシュ値を付けることにしました。私が独自に当てた有用なパッチも勿論全部
公開しております。

あとバイナリにはibusb-1.0やlibftdi1のDLLも最新のコミットを適用/修正された最新の
ものを収録しております。USB3.0がらみでトラブルを抱えていた人たちからもこれなら
動く!と取り上げられてて意外と国外の人たちにも好評です。

最後になりましたが、昨年も言及しましたがダブってコミットされてしまったNuvotonの
フラッシュドライバをようやく統一出来るめどが付きましたのでバージョン上がってからの
私の最初の仕事はNuvoton一色になりそうです。

OpenOCD小ネタ17 -CMSIS-DAPに本来の力を-



まずはこのぶろぐのアクセス数推移のグラフを見ていただきい。

東海自然歩道関連の記事の更新も一区切りが着き、OpenOCDの解説に力を入れはじめた
(中央矢印)とたんにアクセスがガタ落ちになっていますorz

"わかりやすい解説をしていただけるとありがたいです"との多数の要望を受け始めた
OpenOCD小ネタですが、ねむいさんがこちらでやったアドバイスが効き過ぎて皆CoIDEに
移ってしまった模様ですが、これはこれで(開発環境の整備ごときに)無駄な時間浪費
するような被害が減ってよかったのではないか、ねむいさんは安心して近畿自然歩道
とか東海自然歩道の記事更新をしまくればみんな幸せになれるんじゃないかなぁと思い
ましためでたしめでたし。





























で終わってもあまりめでたくないので2015年度はちょっと毛色を変えてくどい解説は極力
排除して面白おかしく斜め45度に傾いた記事を書いていくポリシーを取っております。

ていうわけで本題です!

●CMSIS-DAP(を制御する側)パワーアップ大作戦
現在ではCortex-Mxコアのデバッグに欠かせなくなったCMSIS-DAPですが昨年よりOpenOCD
からも使用可能となっています。しかしながらOpenOCD側の実装とCMSIS-DAPが使用して
いるUSBのHIDクラスの関係上フラッシュ書き込み速度がUSBハイスピード接続でもMAXで
2kByte/Sec程度しか出ない、LPC11U35版のファームにいたっては0.8kByte/Sec以下
まで書き込みスピードが落ちるという極めて不利な弱点がありました。

昨年の秋口からこのチマチマ書き込みしか利用できないOpenOCD側の実装を何とかしようと
あの手この手のアイデアが議論され、書き込み命令をキューイングしてCMSIS-DAPに
元から実装されていたが使用されていなかったブロック転送コマンドで一気にドカンと
転送する作戦が取られました。
CMSIS-DAPの元となるファームウエアは同じながらも各ベンダ間で独特の癖がある拡張に
苦戦しましたが、今春ようやく殆どの問題が解消され正式にマージされる運びとなりました


説明はこれくらいにして早速威力を見てもらいましょう。
テストで使用した基板はLPC1549Xpressoです。
これにはUSBハイスピードで繋がるLPCXpressoV2ハードウエアが載っています。

> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/cmsis-dap.cfg -f target/lpc1549_swd_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.9.0-dev-00314-g90ae846-dirty (2015-03-01-09:33)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'cmsis-dap'
none separate
cortex_m reset_config sysresetreq
adapter speed: 1000 kHz
Info : CMSIS-DAP: SWD Supported
Info : CMSIS-DAP: JTAG Supported
Info : CMSIS-DAP: Interface Initialised (SWD)
Info : CMSIS-DAP: FW Version = 1.0
Info : SWCLK/TCK = 1 SWDIO/TMS = 1 TDI = 1 TDO = 1 nTRST = 0 nRESET = 1
Info : DAP_SWJ Sequence (reset: 50+ '1' followed by 0)
Info : CMSIS-DAP: Interface ready
Info : clock speed 1000 kHz
Info : IDCODE 0x2ba01477
Info : lpc1549.cpu: hardware has 6 breakpoints, 4 watchpoints
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x030000b8 msp: 0x02001fe0
auto erase enabled
wrote 8192 bytes from file main.elf in 16.749893s (0.478 KiB/s)
verified 8172 bytes in 4.593720s (1.737 KiB/s)
shutdown command invoked
↑変更前
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/cmsis-dap.cfg -f target/lpc1549_swd_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.9.0-dev-00357-g09ca5af-dirty (2015-03-31-00:00)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'swd'
none separate
cortex_m reset_config sysresetreq
adapter speed: 1000 kHz
Info : CMSIS-DAP: SWD Supported
Info : CMSIS-DAP: JTAG Supported
Info : CMSIS-DAP: Interface Initialised (SWD)
Info : CMSIS-DAP: FW Version = 1.0
Info : SWCLK/TCK = 1 SWDIO/TMS = 1 TDI = 1 TDO = 1 nTRST = 0 nRESET = 1
Info : CMSIS-DAP: Interface ready
Info : clock speed 1000 kHz
Info : SWD IDCODE 0x2ba01477
Info : lpc1549.cpu: hardware has 6 breakpoints, 4 watchpoints
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x030000b8 msp: 0x02001fe0
auto erase enabled
wrote 8192 bytes from file main.elf in 0.578121s (13.838 KiB/s)
verified 8172 bytes in 0.140624s (56.750 KiB/s)
shutdown command invoked
↑変更後
同じUSB2.0ホストで試しましたがご覧のとおり約10倍以上速くなってますね♥
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/cmsis-dap.cfg -f target/lpc1549_swd_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.9.0-dev-00357-g09ca5af-dirty (2015-03-31-00:00)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'swd'
none separate
cortex_m reset_config sysresetreq
adapter speed: 1000 kHz
Info : CMSIS-DAP: SWD Supported
Info : CMSIS-DAP: JTAG Supported
Info : CMSIS-DAP: Interface Initialised (SWD)
Info : CMSIS-DAP: FW Version = 1.0
Info : SWCLK/TCK = 1 SWDIO/TMS = 1 TDI = 1 TDO = 1 nTRST = 0 nRESET = 1
Info : CMSIS-DAP: Interface ready
Info : clock speed 1000 kHz
Info : SWD IDCODE 0x2ba01477
Info : lpc1549.cpu: hardware has 6 breakpoints, 4 watchpoints
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x030000b8 msp: 0x02001fe0
auto erase enabled
wrote 8192 bytes from file main.elf in 0.468747s (17.067 KiB/s)
verified 8172 bytes in 0.124999s (63.844 KiB/s)
shutdown command invoked
ちなみにUSB3.0ホストだとさらに早くなります♥


LPC824MAXやトラ技ライタのCMSIS-DAPで使用されているLPC11U35はフルスピードまで
で、尚且つメモリリソースがかなり少ないながらもキューイングの恩恵に多少あやかる
ことができ、こちらもパフォーマンスの若干の向上が見られました。
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/cmsis-dap.cfg -f target/lpc82x_swd_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.9.0-dev-00314-g90ae846-dirty (2015-03-01-09:33)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'cmsis-dap'
none separate
cortex_m reset_config sysresetreq
adapter speed: 1000 kHz
Info : CMSIS-DAP: SWD Supported
Info : CMSIS-DAP: Interface Initialised (SWD)
Info : CMSIS-DAP: FW Version = 1.0
Info : SWCLK/TCK = 1 SWDIO/TMS = 1 TDI = 0 TDO = 0 nTRST = 0 nRESET = 1
Info : DAP_SWJ Sequence (reset: 50+ '1' followed by 0)
Info : CMSIS-DAP: Interface ready
Info : clock speed 1000 kHz
Info : IDCODE 0x0bc11477
Info : lpc82x.cpu: hardware has 4 breakpoints, 2 watchpoints
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0xf1000000 pc: 0x1fff0008 msp: 0x10000ffc
auto erase enabled
wrote 8192 bytes from file main.elf in 10.484308s (0.763 KiB/s)
verified 7948 bytes in 0.640621s (12.116 KiB/s)
shutdown command invoked
↑変更前
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/cmsis-dap.cfg -f target/lpc82x_swd_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.9.0-dev-00357-g09ca5af-dirty (2015-03-31-00:00)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'swd'
adapter speed: 10 kHz
adapter_nsrst_delay: 200
cortex_m reset_config sysresetreq
adapter speed: 1000 kHz
Info : CMSIS-DAP: SWD Supported
Info : CMSIS-DAP: Interface Initialised (SWD)
Info : CMSIS-DAP: FW Version = 1.0
Info : SWCLK/TCK = 1 SWDIO/TMS = 1 TDI = 0 TDO = 0 nTRST = 0 nRESET = 1
Info : CMSIS-DAP: Interface ready
Info : clock speed 1000 kHz
Info : SWD IDCODE 0x0bc11477
Info : lpc8xx.cpu: hardware has 4 breakpoints, 2 watchpoints
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0xf1000000 pc: 0x1fff0008 msp: 0x10000ffc
auto erase enabled
wrote 8192 bytes from file main.elf in 4.718719s (1.695 KiB/s)
verified 7948 bytes in 0.406248s (19.106 KiB/s)
shutdown command invoked
↑変更後

尤もLPC824でもフラッシュ容量は最大32kByte程度なので2kByte/Secでもそこまで
困らないかと思います。

トラ技で配布しているmbed版ではないほうのLPC11U35向けCMSIS-DAPファームウェア
使用すればマスストレージに使用していたメモリリソースが使用できるのでさらに
ちょっとだけ速度が上がります。


そんなわけで弱点だったCMSIS-DAPの書き込み速度は実用レベルにまで改善したので
OpenOCDからCMSIS-DAPをびしばし使い倒すことができるようになりました。
これでXPresso系のボードの開発もスムーズに進められると思います!

OpenOCD小ネタ16 -ついに浮動小数点レジスタ対応す-

かつてRemote'G'パケットうんちゃらかんちゃらのエラーが猛威を振るっておりましたが
たしかあれはダミーのFPUレジスタ分パケットが余分に送り込まれていたことが原因だっ
たとおもいます。懐かしいですね…
時は流れ、ついにOpenOCDでもFPUレジスタ(浮動小数点レジスタ)の値をちゃんと読める
ようになりました
のでご紹介します。

●FPUレジスタを読もう
ねむいさんの開発環境ではデバッガソフトウエアとしてInsightを使用しています。
こいつはクリック一発でレジスタウインドウが開き汎用レジスタとかを参照できる
便利な代物ですがFPUレジスタを見ようとする際はちょっとコツが要ります。
※言うまでもありませんがFPUを使用できるCortex-M4Fコアを持つSTM32F4,LPC4000系の
 マイコンをご用意ください。


先ずはOpenOCD側のcfgファイルの設定ですがかつては頑なにdisableにしていたtdesc
(target description)の設定をenableにしてください。
gdb_target_description disable

gdb_target_description enable

現在のおきぱにあるOpenOCDバイナリ及びねむいさん特製cfgはenableに変更してます。


とりあえずデバッグ手順通りに進め、attachする直前まで。
ここでattachする(runボタン押す)前より先にレジスタウインドウを開いておきます。


そんでattach。そして速攻レジスタウインドウを閉じる


もう一度開くとあら不思議!レジスタウインドウにFPUレジスタが追加されてます♥
注!当たり前ですがFPUを有効にした後に参照してください!
 タイミング的にはmain()の先頭に立った直後が良いでしょう。

FPUが使用された時はレジスタウインドウ内のFPUレジスタの欄もしっかりと更新され、
FPUレジスタの中身がしっかり読み取れていることが分かります。


ちなみにレジスタウインドウを前もって開かずにattach後に開こうとするとInsightが
高い確率でひでぶして落ちてしまいます。tdescの実装直後みたく何やっても落ちる
事は無くなりましたがInsight側の問題とは思いますが上記の確実に参照できる回避
策でお願いします。


FPUを持たないCortex-M3系もちゃんと判別してこんな風に汎用レジスタのみ表示となります。


同じくCortex-M4でもFPUが無いKinetis系ではしっかり判別して汎用レジスタのみ表示です。


実際のデバッグではRTOSとか使わない限りレジスタの参照する場面は正直言うとあまり
ないですが選択肢が増えることは頼もしいことだと思います。どしどし使っていきましょう。



●あと細かい修正とか注意事項
FPUレジスタの読み取りには関係ありませんがこちらの件もかなり重要なので私に
”エラーが出る!”っていう質問が殺到する前に前もって注意しときます。
こちらのコミットから"make program"でshutdownやexitコマンドを含むスクリプトを実行
するとOpenOCDがエラーを返すようになった為エラー終了するようになりました。

ねむいさんの公開しているバイナリではフラッシュ書き込みスクリプト付きのcfgに
影響があり、ちゃんと書きこめていてもエラーで終了しているように見えます。

↑こんな感じになります。

これは不具合ではなくこういう動作仕様になっちゃいましたのでご了承ください。
・・・と言いたいと こ ろ  が !!

20150313追:
なんとこの記事書いた直後にご了承できない方がgerritに修正を突っ込まれたようです。

やっぱし正常に書けてるのにエラーで終わるのは決まり悪いのでねむいさんも激支援します!
おきぱのopenOCDバイナリも早速反映をしてみましたので安心してお召し上がりください♥

OpenOCD小ネタ15 -LPC5410x,LPC82xシリーズの書き込み対応-

11月ごろに新規ラインナップリリースの報は小耳にはさんでいたのですがまだまだ先かと
思っていたLPC54102XPressoが秋月さんから唐突に発売されておりました。
同時にLPC824MAXも販売されましたので早速手に入れ評価してみましたのでご紹介します。


●LPC82xシリーズのフラッシュ書き込みに対応

LPC824MAX、正式名称はLPCXPresso824MAXです。

中心部のLPC824はCortex-M0+コアを持つLPC810シリーズの上位に位置し、フラッシュ
メモリとSRAM容量の増強に加えてDMAも追加されております。もはやLPC810シリーズと
は別品種(後述の部分も含め)とみて良いでしょう
付属のデバッガはおなじみMBED版CMSIS-DAPです。マスストレージからの書き込みも
サポートしております(が当ぶろぐでは全く使いません)

ん…?なんかコネクタのハンダが雑だ…

!!!!!!なんかコネクタうまくハマらないと思ったら…
とりあえず精密ラジオペンチで障害物取り除いて対処しました。
後で新しいのに取り換えておきましょ。


気を取り直してOpenOCDから書き込みしようとしてみました…
が、
LPC81x系と同じだろうと高をくくっていましたが正しく書き込めませんorz
もう少し突っ込んで調査してみると最初の1kBしか書き込めてない現象…これはまさか

UM10800rev1の386ページにはIAPのスタックはLPC810系と同じく148byte確保せよと
指示してあるのですがこれに従うと駄目でlpc4300系みたいに208byte確保しないと
ただしく書き込み動作、正確にはIAPコマンド51が連続で実行できませんでした。
マニュアルの整備がまだ行き届いてない感じですね。LPC82xはリリースして結構時間
経ってるので多分同じ指摘が来てるはずです。来月あたりにこっそり変わってると思い
ます。NxPさんはドキュメントの修正対応かなり早いので特に気にしてませんがあまり
高に言うとコワモテのくまさんに〆られるのd


そんなわけでLPC824にも書き込みデバッグが可能になりました。
ついでにLPC11xxとLPC17xxで対応しているフラッシュメモリサイズの自動認識についても
LPC800シリーズ向けに対応しておきましたのでcfgファイルの統一可能です♥



●LPC54102のフラッシュ書き込みにも対応


LPC54102XpressoはCortex-M4FとCortex-M0+が同居したLPC5410xシリーズとV3に
バージョンが上がったLPCXpressoのハードウエアで構成されています。

デバッガとしてはLPC-Link2同等品として動作します。CMSIS-DAPでデバッグが可能に
なっております。

またコネクタ構成もArduinoのシールド互換に構成になっており、mbedにも対応予定
だそうですがmbed公式にはまだ影も形も使ってる人すらもいません。つまりこの記事
投稿するのが早ければ私が国内第一号になるはずです!!!


と、その前に書き込みをできるようにしなければなりません。LPC824と同じくOpenOCD
にパッチを当てる必要がありました。ブートローダーの構成・エントリポイントはLPC1500
シリーズと同じですが当然ながらフラッシュメモリのセクタサイズとIAP消費スタック
容量が異なりますのでそれに合わせて作りこんでいきました。


作りこみ自体は慣れたものなのでLPC5410x系のフラッシュ書き込みは危なげなく完了
し、現状M4コア単独のみですが動作も確認できました。

但し書き込み時にはcfgサイドでちょっとコツが必要です。LPC5410xはLPC1000系には
存在しているベクタアドレスのリマップ機能がなく、電源投入時はもちろん各リセット
時にもブートローダー(0x03000000から開始)にまず飛び、ブートROMの先頭が0番地に
来ます。つまりリセット直後にhaltをかけた状態でベリファイを行うと、ユーザフラッシュ
ではなくブートROMの内容を読んでしまいベリファイに失敗します。

これを防ぐためにフラッシュにプログラムを書いた後は一旦リセットをかけてユーザ
プログラムを走らせ(reset run)てからhaltをかけてやる必要があります。
私が公開しているOpenOCDのプログラムと同梱のLPC54102向けcfgは一連の操作を
リブートコマンドとしてprocに定義してありますのでユーザサイドでは特に意識しないで
書き込み・デバッグが可能となっております。

おきぱにはGCCでビルドできるLPC54102XPresso向けのプロジェクトを置いてますので
秋月さんで購入された方は試してみてください。上で述べたとおりこのボードに仕込
まれてるものはLPC-Link2相当でHighSpeedで繋がるため、OpenOCDから書くと極めて
遅いと言われているCMSIS-DAPにも関わらずかなり早いです。


これらLPC2000向けパッチはgerritにもパッチをあげておりますので興味のある方は
ビルドして試してみてください。またWindows環境の方はおきぱのOpenOCDバイナリ
パッチ適用済みですのでご利用ください!

OpenOCD小ネタ14 -LPC1500シリーズの書き込み対応-

●LPc1500シリーズのフラッシュ書き込みに対応
長らく肥やしにされておりましたが先週あたりにようやくコミットされました

LPC1500シリーズはIAPのアドレスがLPC1000やLPC800シリーズとは別の場所に
ありますが、単純にLPC1500用のアドレスを追加するだけでOKでした。
上のリンクのやり取りの通り、LPC1500はCortex-M3シリーズであり常にthumbモード
なのでアドレスを奇数に設定してやる必要があります。ユーザーマニュアルは微妙に
取り違えやすい表現になっていて最初ちょっと混乱しましたが今はOpenOCD以外にも
オープソースなプログラムがあるのでそちらも参考にさせてもらっています。

LPCLink2ConfigurationTool もパワーアップ!

さて、書き込む対象はLPCXPressoV2が仕込まれたLPC1549XPressoです。
購入当初デバッガ側に書き込まれていたCMSIS-DAPのファームはFL1100のUSB3.0ホスト
コントローラから認識せず(F**K!)仕方なくmbed版のCMSIS-DAPを使用しました…
しかしVCP/MSDと折半になるのでただでさえ遅い速度が更に遅くなりしかも書き込み
後もターゲットのLPC1549をつかんだままになるので完了せずエラーになるという
ちょっと不便な代物でした。

しかし今年11月になってようやく大幅更新されてリニューアルしました。
こんどのものはmbed版じゃない通常のCMSIS-DAPでも仮想COMが実装され、MBED版
CMSIS-SAPに近い構成になっています。ちなみにLPC-Link2も同じように仮想COMが
使用可能となってます。

しかも書き込みスピードがちょっと早くなってます。今のHIDのチマチマ書き込みの制限だと
2kb/Secくらいの早さでしたがUSB3.0ポートだと5kB/Secくらいにアップしてます!
やったね!
…と言いたいところですがUSB2.0のポートだと逆にパワーダウンして0.48kB/Secに
落ち込んるのが判明orz
はやくOpenOCDにもCMSIS-DAPのブロック書き込みが実装されますように…


ちなみに新しいLPCLink2ConfigurationToolはJLinkのファームウェアもありますが残念
ながらこちらは何ら変更はなくSRSTの直接操作不能バグありのままです。
LPCLink2をJlinkとして使用されている方はSRSTのコントロールは省略してください。
Cortex系ではsysresetreqが代用できます。

OpenOCD小ネタ13 -ビルド環境のアップデートとWindows8.x一部対応-

20150106追:
現在おきぱにあるopenOCDバイナリはWindows8系にも完全対応してます。
20150106追:



OpenOCD等のWindows版バイナリをビルドする際は、私はMsys/MinGWを使用し、GCCの
バージョンは4.7.3でずっと使用してきておりました。しかしこれからのツールの趨勢に備え、
相変わらずの重い腰を上げてビルド環境のアップデートを試みました。

●msys-coreのアップデート
yamidori98氏のレポートによるとパラレルでmakeした時(-j2とかのスイッチかました時)に
ハングする可能性が指摘されていてパッチを当てたmsys-1.0.dllに差し替える必要がある
そうです。OpenOCDをビルドする際は最後のmakeが並列化してますのでこれは適用すべき
かと思います。(64bit版Win7ではまだハングに遭遇してませんが)

ビルドに関してはコマンド一発でdllその他諸々をアーカイブしてくれるスクリプトファイルが
提供されていたので非常に助かりました。ありがとうございます。

●makeを3.82に
同じくレポートを参考に現状最新v3.82のmakeをmakeしました。そうだね駄洒落だね。
こちらもスクリプトファイルを用意してくれていたのでありがたく利用させていただきました。

●GCCをアップデート

最初に述べたとおり、従来よりrubenvbさん所の個人ビルドのGCC4.7.3を使用していました。
実はGCC4.8系に上げてビルドすることを過去に何度か試してみたことがあったのですが、
libgcc_s_sjlj-1.dllが無いとかInterlockedCompareExchange@12が見つかりませんだとか
そういうエラーに阻まれてとりあえず動くの優先!ということでそれらのエラーが出ない
4.7.3を使ってきた次第です。

これらのエラーはバージョンが上がる際の一時的なものだろうとスルーしていましたが
アップデートを考えていた4.9.2でも同じようにlibgcc_s_sjlj-1.dllが無い問題が発生したので
仕方なくいろいろ調べているとlibstdcとlibgccを明示的にスタティックリンクにしてやれば
dllを求められることがなくなることがわかりました。
libusbでいうとCFLAGS,CPPFLAGS,CXXFLAGSに"-static-libgcc -static-libstdc++"
を付与すれば終わりです("-static"は特に付けなくても大丈夫でした)

しかしそれだけではうまくいかなくて得られたlibusb-1.0.dllを差し替えると今度はlibftdi1.dllで
InterlockedCompareExchange@12が見つからないとエラーを吐いてきました!
こちらに関してはdllとそれ呼び出すexeが異なるバージョンのGCCでビルドされていた
場合に発生することがわかりEXEもDLLも全て同じGCC4.9.2でビルドするようにして
解決しました。最終的にOpenOCDをはじめとしてUrJTAG,vsprog,Flashrom,avrdude
GCC4.9.2版のビルドで安定して動作せしめられるようになりました♥


●Windows8でSTLink/V2-1がOpenOCDから繋がらないこともなくはない
環境がGCC4.9.2化出来たので、今度は使用するユーザーが増えて多数報告を戴くように
なった"Windows8.x系でSTLink/V2-1が載ったNucleo板がOpenOCDから繋がらない問題"
に漸くまともに取り組みました。

といっても私はWin8機を所持しておらず副業先のPCたちも全部Windows7機だったので、
不具合を再現させるための環境が全くなく問題の切り分けも困難を極めておりました。
で、唯一Windows8.1を所持している知り合いの方に頼んで3〜4日オーダーのフィードバック
速度でああでもないこうでもないを繰り返し、ついにlibusb-1.0をビルドするときに当てて
いるAsmedia対策のパッチが原因だったことを突き止めました!
またAsmediaか!!

最初にAsmedia対策パッチを検証した際にXPと64bit版Win7では全く問題ないことを確認
していたのですがWin8ではUSBデバイスの取り扱いもさらに厳しくなった(?)ことからパッチを
適用した部分が仇になってデバイスをOpen出来なくなっていたようです。
幸いにも2014年11月現在は別の切り口でAsmedia対策のパッチが提供されていてそちらの
パッチに変更してビルドしたlibusb-1.0.dllではWindows8でもばっちり動作しました♥
長かった…

というわけでWindows8.1系OSでもOpenOCDが利用できるとっかかりが出来ました。現在
Win8環境下で私が動作保証できる組み合わせは以下のデバッガアダプタです。
1:STLink/V2-1(Nucleo板,STM32F053Discovery)
2:STLink/V2(Discovery系板たくさん)

何れもSTマイクロ配布の公式ドライバ(WinUSB)を適用したものです。

もしあなたの環境で上記の場合でもうまくいかない場合、Zadigを使用し以下の手順で
STLink/V2-1のUSB複合デバイスの親("composite parent") に無理やりWinUSBを適用
して単独の”STLink/V2”として使用する荒業もあります。ただしこれをやると仮想COMや
mbedのマスストレージ書き込みが一切使用できなくなりますのでご了承ください。

とりあえず通常のドライバを適用した後Zadigを起動し、
"List All Devices"にチェック入れる、
"Ignore Hubs or Composite Parents"のチェック外す

すると"STM32 STLink (Composite Parent)"が現れるのでこれをWinUSBに置き換える

入れ替えの際に間違えて違うデバイスにWinUSBを適用してしまうと復帰できなくなる
危険性がありますので細心の注意を払って作業してください。

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サポート開始です



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

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

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

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

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

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



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

OpenOCD小ネタ10 -VersaloonのSWD正式対応とKinetisドライバの小改修-

●祝!Versaloonが正式にSWD接続対応になった。
先日、JTAGkey2に代表されるFTDI系のデバイスがSWDに対応しました。それに続いて
Versaloon(OpenOCD内ではvsllinkと呼ばれています)のコードも大幅に見直しがされて
SWD周りのadi-v5の依存部分が完全に分離、再構成されて晴れて正式にSWDに対応
となりました。
それに伴い以前紹介していた導入手順と変更になる個所が幾つかありますので、皆さん
が迷わないように変更すべき個所を以下に述べます。

1.LibUSBが0.1系から1.0系になった(超重要!)
Versaloonは従来からUSBのドライバとしてLibUSB0.1系APIを使用していましたが、今回
のSWD対応で1.0系に切り替わっています。Zadig等の自動インストーラで0.1系ドライバ
を適用してる場合はLibUSBKかWinUSBに切り替えておきましょう。

2.Versaloon用cfgファイル
ねむいさんはVersaloonのswd対応用として特別なcfgファイルを提供しておりました。
その中でVersaloon用の固有コマンド"swd_delay"と"swd_trn"が設定されていましたが、
swd_trnは2に固定化されハードコード、swd_delayはイニシャライズ時のadapter_khzの
解釈に取り込まれそれぞれ廃止になっております。
自作のswd用のcfgを作成されている方はswd_delayとswd_trnの定義は削除してください。

ソースコードを見た限りではJTAGKey2を使う場合と違ってSWCLKのクロックの設定が
最初の定義以降は動的に変えられないように見受けられましたが(ソース上では変更で
きる余地がある)あえてそうした理由も含めてこれからさらに探ってみます。

私のOpenOCDのバイナリは既に正式にSWDに対応した版に切り替わっていますがまだ
Versaloonを現役で使用されている酔狂な方は上記2点を見直し各自対応願います!


●VersaloonのConnetUnderResetとkinetisドライバと
"今まで正常に書き込めてたのに急にうまく動かなくなった"問題をほぼ解決してくれる
心強いConnectUnderReset機構はSTLink/V2で絶賛活躍中です!
…と言いたいところですがSWD接続の場合、STLink/V2以外の殆どのデバッガアダプタ
でマトモに機能していないことが判明しましたorz

それが判明した経緯は私がOpenOCDのgerritにkinetisドライバのちょっとした修正
送ったことにあります。他のユーザさんから"Kシリーズでセキュリティ状態の有効/解除
上手く出来てるのか?"と問われ、SWD接続の方のVersaloonで試してみると確かにセキュ
リティ状態が解除できませんでした。手でリセットボタンを連打すると解除できたのを不
審に感じ、(Kinetis-Kシリーズはセキュリティ状態の解除に外部SRSTの操作が必須。3月
初めにkinetisのフラッシュドライバに大幅変更がかまされたときKL25とかのKLシリーズ
でしか試してない人がリファレンスマニュアルをよく読まずKLシリーズに特化して機能
を再実装してしまった…!そのせいでK40とかの古いシリーズではうまくいかなくなると
いう憂き目にっていうか前々々回のguranualityがらみでエンバグ直した時もそうだけど

お前らちゃんとリファレンスマニュアル読めやぁあああああああああああああ!!)

…ッ…はぁはぁすみません取り乱しました…ぇっとオシロスコープでSRSTの動きを観測
するとまったくConnectUnderResetしておりませんでしたorz

↑全くダメですこれ
ねむいさんてっきりハイレベルなレイヤでこの機構が入ってると思ってたのですが・・・・
なんとSWDの場合だけローレベルのデバッガアダプタ依存処理なのでしたorz
というわけでvsllink.cのイニシャライズの所にConnectUnderReset機構ぶち込んで
あっさり終了です#

↑これですよこれ!


まさかと思ってJTAGKey2でSWD接続で試してみると同じ結果でしたorz

↑SWD接続orz

↑JTAG接続だとちゃんとConnectUnderResetしている…
 手前にresetがHレベルにあるのにTCKが動いてますがこれはSWD-JTAGの移行シーケンス
 なので電源投入直後なら特に問題はないです(正直これもちょっと???ですが)

おきぱにあるバイナリは現状VersaloonにだけConnectUnderResetのぱっちを当てて
いますが、FTDI系は一筋縄ではいかずかなり手ごわいので慎重に対応していきます。

OpenOCD小ネタ9 -STM32F33xシリーズとFTDI系のSWD対応-


6月中旬に唐突に秋月さんちのラインナップに追加された詳細一切不明の謎Nucleo基板
Nucleo-F334R8にはこれまた詳細不明のSTM32F334R8T6が搭載されておりました。

↑今回から撮影用でぢかめを接写に超強いTG-3に買い換えました♥
6月中旬の時点ではF3シリーズであるというほかには詳細が一切不明だったので会社で
試作部品発注したついでに購入してしまいました。(注:Nucleo板は自費で購入です!)

ひとまずOpenOCDで引っ掛けると、デバイスIDが0x10016438というまだOpenOCDのフラッ
シュドライバには存在しない物だっため最初は書き込みエラーではじかれてしまいましたが
ソースコードにそのデバイスID追加して即書き込むことが出来ました。
因みにSTM32F3系はCortex-M4系ですがフラッシュ書き込みドライバはF1系です。もう少
しでF2系ドライバに実装しそうになってしまいましたよ。実は最初に私がパッチを書いた
当初はユーザマニュアルどころかデータシートすらも無かったため、フラッシュのセクタサイズ
は0系からのコピペの飛ばしでした・・・。が、その後にリリースされたReferenceManual
には2048バイトと書かれていたのでセフセフです。

話は前後しますが一週間以上前に提出したパッチはすでに公式にマージされています
おきぱにあるOpenOCDのバイナリもF334R8版Nucleo対応のcfgを作っていますのでお持ちの
方はすぐに試すことができます。便利な書き込みスクリプト付きで対応です☆


というわけでせっかく買ったのでLチカだけじゃなくNucleo版のいつものに相当する
I2Cデバイスを動かすサンプルを移植しました。
長らくの間ねむいさんたった一人しかこのi2c液晶動かして無かったですがごく最近
ついに他の方も動作に成功したようです。私間違ってなかったですよね…!
注:7月1日現在、STM32のライブラリをPeriphDriverからHALDriver(STM32CubeF3)
 に変更しております。CubeFx系のライブラリ対応につきましては後日みっっっっちりと
 解説させていただきましたので覚悟なさい!





お次は長らくの悲願であったFTDI系デバイスのSWD接続正式対応です!
以前から私はぶろぐ上にてレビュー段階のコミットを評価しておりました。その時点で既に
かなりの完成度に達しておりましたがその後adi_v5とswd関連のソースも見直されて
満を持しての今回のマージです♥
…と同時にVersaloonのSWDパッチは完全に使用不可になってしまいましたが実は他の
方が別の手段でSWDに対応させたパッチがレビュー中でして7/1現在おきぱにあるバイナリ
はそちらの物を取り込んでおります。Versaloonも以前と全く変わらない使用感になって
いますのでこちらのマージも時間の問題であると言えます☆

さて、ねむいさんのぶろぐではJTAGKey2(とその互換回路)を使用してSWDせしめる
方法をお伝えします。以前も述べていますが原理は簡単で抵抗一本でSWD化可能です。


たったこれだけの追加回路で完了です。一見強引な方法に見えますが出力同士がぶつ
かっても(私の回路図通りに作りこんでいれば)出力バッファの定格内なので全く問題
がありません。

上記の方法、JTAGKey2に代表されるハード的にSWD未対応な物ではresister-hack
という形でOpenOCDのcfgファイルでサポートされています。それを利用してswdで接続しに
行くJTAGKey2専用のcfgファイル"jtagkey2_swd.cfg"もこちらでこさえております。

おきぱにあるプロジェクトではEFM32とSTM32F4のいつものがすでにJTAGKey2のSWD接続に
makefileレベルで対応しております。現在はまだ3つだけですが順次対応して行きます。
あとついでのついでですがEFM32のZEROGECKOのフラッシュ書き込みも対応させました
こちらも機会があればEFM32のボードとともにご紹介させていただきます。

OpenOCD小ネタ8 -STM32-Nucleo(Nucleo F030R8)で楽しむベアメタルプログラミング-



…おっと、すみません。今回はSTM32-Nucleoボードのお話でしたね〜



一か月ほど前購入したSTM32-NucleoのF0バージョンですが、これには新しいSTLink
であるSTLink/V2-1という間際らしい名前のデバッガアダプタが搭載されていることに言及
しました。これはmbedサポートを謳っていてD&Dによるフラッシュ書き込みはもちろん仮想
COM(VCP)や通常のデバッグも同時に可能です。
STLink/V2-1はCMSIS-DAPとしては機能しないものの現在のOpenOCDはCMSIS-DAPは
不利になる
ので従来のSTLinkとほとんど変わらず使えるほうがありがたいのです。

しかしながら新たに追加されたMSDとVCPのおかげでエンドポイントの定義が若干違うため、
OpenOCDにV2-1用のパッチを当てないと使用ができませんでした。以前も少し触れました
こちらのサイトの情報を基にパッチをgerritに投げてマージされることを待ったのですが、
後出しじゃんけんされまくってボコボコSTLink/V2-1のパッチ投げられる事態となって
しまいました。

で、詳細は省きますが同じぱっちを投げた人同士で相談し、結局この人のコミットをベースに
私の思想を反映した形で落ち着きました。ついでにF0,F4,L1の各シリーズのNucleoボード
にも対応したcfgも作成されました



というわけで20140324現在では既にNucleo(STLink/V2-1)に対応したデバッグアダプタ
もOpenOCDから利用可能となっております。STLink/V2-1では仮想COM機能もあり、F0の
NucleoボードではUARTのTx,Rxが直結されているので本当にmbed感覚で利用が可能です。
20140903追
Windows8.x系OSをお使いの方はこちらを必ずお読みください。


おきぱには既にNucleoF0版向けのGCCプロジェクトを公開しておりますがLチカに飽き足らず
勿論UARTの文字列送信も盛り込んでいますのでご参考までに。

ところでNucleoボードは拡張性を狙った各シリーズ共通のMorphoなるピン配置が外部に
出ております。Morphoとかニョガン思い出して非常に縁起の悪い名称ですが。
さらに現在のプロトタイプボードでは必須となったArduinoのシールド向けのポートも用意
されております。mbedではNucleo用のライブラリや作例などが充実し始めております。
ソフトウエアやハードウエアの技術に明るくない人でも先人が残した成果を余すことなく利用
でき、熟練度に関係なく楽しめる仕組みになっていてなかなか考えられていると感じます。


てわけでついでなので私ももうちょっと遊んでみました。これは知る人ぞ知るTFT-LCD
シールド
です!今回はFONTXドライバとからめで文字列の表示をしてみます。

TFT-LCDシールドとNucleo上のLEDはSCLKにあたるポートがぶつかります(PA5/D13の所)。
ですがArduino系シールドを上から挿した時点で横から覗きこまない限りLEDは全く見え
なくなるので無視して先に進みます!(ハードウエアSPIの場合SCKは必ずぶつかる)

STM32F0/F3系のSPIはちょっと特殊で8~16bitまで自由に送受信するビット数が変えられ
ます。従来のF1/F2/F4系とは若干データレジスタの取り扱いが違い、FIFOの設定を正しく
行いビット数に合わせてDRレジスタのアクセス方法も変えないとデータの送受信が
できないのでご注意ください。
私はdisplay_if_basis.cの頭に8bitアクセス用のマクロを作って互換性を保ちました。


動かしてみたところです。さすがにフラッシュの容量が少ないのでひらがなとかの表示は
無理ですがこの規模ならANKで十分だと思います。

実は上記TFT-LCDシールドを動かすためのコードもおきぱにあるサンプルには導入して
おります。8bit-SPIで動く奴ならピン配置さえ合わせたらほとんどのTFT-LCDモジュール
も動作せしめることができるのでTFT-LCDシールドをお持ちでない方も少しmakefileの
設定を変更するだけで手持ちの手頃でSPIなTFT-LCDで動作可能だと思います。


忘れるところでした、今回の修正を反映したOpenOCDバイナリもすでに公開中です!

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対応は
シンプルかつ強力なポテンシャルを秘めていると言えるでしょう!

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のハード的な仕様です)。

OpenOCD小ネタ5 -CMSIS-DAP、来る!-

あけましておめでとうございます。
今年もわたくしねむいさんと虹裏メイドたちをどうぞごひいきに。



さて、早速本題に入りましょう。正月明けから少し経ったころ、以前から少しずつ
修正が加えられていたCMSIS-DAP対応がついに公式にマージされました!

CMSIS-DAPとは以前から述べてきましたがARM謹製のオープンソースのデバッガ・
ハードウエアの名称です。大きな特徴としてPCからはUSB-HIDデバイスとして認識
されるので(mbed版はVCPドライバが必要)ドライバいらずで面倒な設定がほとんど
無く手軽に使用できます。

OpenOCDから使用する際にはOS間の差異を吸収するためhidapiというHIDデバイスの
ライブラリを経由してアクセスされます。つまり、OpenOCDからCMSIS-DAPを利用可
能にするためにはhidapiも使用可能にしておく必要があります。

私のおきぱにあるOpenOCDのバイナリはすでにhidapiが使えるように自前でビルド
したlibhidapi-0.dllをバインドしていますのですぐに使用が可能です。

↑ていうわけでCMSIS-DAP対応のOpenOCDを使ってLPC812-MAX上で
 書き込み/デバッグしてるところです♥

なお、CMSIS-DAPはSTLink/v2やTI-ICDIのようないわゆるHLAには属さず、JTAGデバイス
やSWD版Versaloonのようにローレベルまで直接ぶっ叩くことが可能なアダプタのため、
Kinetis系のような雄度の高いマイコン相手でもバリバリ使用可能です。

特にFRDM系の評価ボードに特化したMBED版CMSIS-DAPのバイナリが用意され始めてい
るので利用しない手はありません!急げ!
…とその前に…
※MBED版CMSIS-DAP使用上の注意※
MBED版CMSIS-DAPは実際はUSB-MSC,USB-VCP,USB-HIDの3つのUSBコンポジット・
デバイスとして構成されています。しかし最初はMSCしか認識してくれず、CMSIS-DAP(HID)
が使えません。こちらにあるVCPドライバをインストールすることによってCMSIS-DAPも
認識されますのでご注意を。



ところでずっとフン詰まり状態だったCMSIS-DAP対応がOpenOCDに急にマージされた
背景にはVersaloonの今後に関するちょっとした議論がありました。
かいつまんで言うとVersaloon終了です。もうこれ以上ハードもファームも更新はされる
ことはないでしょう。SWDプロトコル対応のパッチはOpenOCD0.6.0以降は全く更新され
ていません。しかも今回のCMSIS-DAP対応により完全に適用不可能となります。

しかし、もうご存知の方もいますがねむいさんはCMSIS-DAPとSWD版Versaloonを統合
して使用可能なパッチを作成しています
。ねむいさんのぶろぐを知ってる方は私の目が
黒いうちはVersaloonの恩恵が受けられますのでご安心ください。
最近はOpenOCDの自前ビルドが必須のLinux系&マカーな環境の方からも続々と成功の
報告をいただくようになりました。ありがとうございます。ありがとうございます。

20140715追:
Versaloon復ッ活ッッ!


私もCMSIS-DAP対応を決起に未提出のパッチをgerritにどんどん吐いていく予定でした
のでOpenOCDがオワコンどころか一気にボルテージが上がって今年はさらに深い部分
まで切り込んでいくことになりそうです。


20150406追:
CMSIS-DAPが本来の力を取り戻しました。
遅かったOpenOCDからの書き込みも快適に行えます☆

OpenOCD小ネタ4 -LPC810に書き込みできないの-

>8PinDIPのARMマイコンLPC810、ようやく一般市場に出回る!

あのさぁ…私がLPC812を最初に手に入れてからもう約1年たったんですよぅ約1年!
それを今更…


こんなのこうしてやる!
STM32F0Discoveryが放つprobeに捕えられDiscloseされる哀れなLPC810の姿。

ぐへへ32bitマイコンのくせにこんなにいやらしく足(間隔:2.54mm)広げやがって♥


はぁ…はぁ…でもあんまし攻めると某ウイルスバスターのweb広告に出てくる
コワモテ893
に似たNxPの中の人にこのぶろぐ焼き討ちされちゃいますのでこの辺に
しておいてあげます…

20131205追:
上尾の亞妃威(あげおのあっぴぃ)様がLPC810について猛ってらっしゃる…
↑そいえばChaNさんのレポートの序盤のCMSISペリフェラルライブラリの下りの文章が
 "お前らはこの程度で充分だろ"から"タダなんだからこの程度の品質でいいだろ!"
 というややマイルドな表現にさりげなく差し替わってますね…。

↑CMSISが厭だ、嫌いって人たち話を注意深く聞くとARM提供のCMSIS
 ヘッダライブラリに対してではなく各チップベンダ提供のCMSIS準拠
 ペリフェラルライブラリの出来の悪さにひどい目にあわされた方が異口
 同音におっしゃっているのを実感します。私もそれについては非常に同意します。
 KinetisLシリーズとかのシリアルライブラリはなんとK40シリーズからの
 適当なこぴぺでまともに動いてない代物でした。

↑そんなわけでCMSISべったり派なねむいさんもペリフェラルのレジスタ
 定義だけ拝借してSD/MMC等の下回りのドライバなどは手書きが多いです。

↑CMSISのイディオムは"シムシス"だそうです。わたしは"しゐえむしす"を
 貫き通しています。McDonaldsはマドです。









…さて戯言はこの辺にしといてOpenOCDにおいては既にねむいさんがLPC800シリーズ向けの
ぱっちを提供し、STLink/V2,Versaloon(※要パッチ),CMSIS-DAP(※要パッチ)の各デバッガ
ハードウエアからSWDで書き込みが可能です。一応購入したからせっかくだから上記
写真のようにちょっと通電してSTLink/V2で書き込んでやろうかなと思ったのですが…


> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/stlink-v2.cfg -f target/lpc810_hla_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.8.0-dev-00269-g30fb9dd-dirty (2013-11-19-20:50)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
none separate
Info : This adapter doesn't support configurable speed
Info : STLINK v2 JTAG v17 API v2 SWIM v0 VID 0x0483 PID 0x3748
Info : Target voltage: 2.891327
Info : lpc810.cpu: hardware has 4 breakpoints, 2 watchpoints
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0xf1000000 pc: 0x1fff0008 msp: 0x10000ffc
auto erase enabled
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x10000004 msp: 0x100000c8
Warn : not enough working area available(requested 512)
Error: no working area specified, can't write LPC2000 internal flash
Error: error writing to flash at address 0x00000000 at offset 0x00000000
Runtime Error: C:/Devz/ARM/OCD/tcl/target/lpc810_hla_flash.cfg:112:
in procedure 'mt_flash'
in procedure 'flash' called at file "C:/Devz/ARM/OCD/tcl/target/lpc810_hla_flash.cfg", line 112
make: *** [program] エラー 1

> Process Exit Code: 2
> Time Taken: 00:01

↑あれれ…書けない…だめじゃん(LPC812は問題なし)
 まさか…


lpc2000.c中でIAPコマンド51番を実行する時にバッファサイズを指定するのですがLPC800
シリーズは一律1024Byteに減少させていました(LPC2000.cのデフォルトは4096Byte)。
LPC810のSRAMサイズは1024Byteなのでこれでも足らないみたいです。いろいろ試した
結果、実サイズの4分1の256Byteまで落として成功しました。

> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/stlink-v2.cfg -f target/lpc810_hla_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.8.0-dev-00269-g30fb9dd-dirty (2013-11-19-20:50)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
none separate
Info : This adapter doesn't support configurable speed
Info : STLINK v2 JTAG v17 API v2 SWIM v0 VID 0x0483 PID 0x3748
Info : Target voltage: 2.872920
Info : lpc810.cpu: hardware has 4 breakpoints, 2 watchpoints
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0xf1000000 pc: 0x1fff0008 msp: 0x10000ffc
auto erase enabled
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x10000004 msp: 0x100000c8
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x10000004 msp: 0x100000c8
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x10000004 msp: 0x100000c8
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x10000004 msp: 0x100000c8
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x10000004 msp: 0x100000c8
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x10000004 msp: 0x100000c8
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x10000004 msp: 0x100000c8
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x10000004 msp: 0x100000c8
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x10000004 msp: 0x100000c8
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x10000004 msp: 0x100000c8
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x10000004 msp: 0x100000c8
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x10000004 msp: 0x100000c8
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x10000004 msp: 0x100000c8
wrote 3072 bytes from file main.elf in 0.749995s (4.000 KiB/s)
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x1000002e msp: 0x10000ffc
verified 2400 bytes in 0.062500s (37.500 KiB/s)
shutdown command invoked

> Process Exit Code: 0
> Time Taken: 00:02

↑cmd51のバッファサイズを下げると書き込みパフォーマンスが下がってしまうのですが
 LPC810はフラッシュのサイズも4096バイトしかないので問題ないです。


なおLPC810は8PinDIPですがお外に出てない足がある模様です。ないはずのピンにアク
セスするとちゃんと出力が変化しました。上画像のデバッグではLPC812のプロジェクト
をスタックとチェックサムだけLPC810用に書き換えたやっけつVerです。


そんなわけで今回の修正分を盛り込んだOpenOCDバイナリはおきぱに反映しました。
珍しくメールやコメントでバグのご指摘もらう前に自分で気づきましたよ!OpenOCD
のgerritにも今レビュー中のSTM32F4のパッチがマージされたら反映させます。
20140109追:
ぱっち提出しました。
20140112追:
マージされました♥


LPC810は同じ8ピンDIPマイコンのAVRの牙城を崩すことができるのか?それは時間が
経てばおのずとわかると思います。





おまけ

STM32F429I-Discoveryいじりは基本のいつものが実装できるとこまで進みました。
あと数日くらいでファイル公開予定です。実物持ってる人はmakefileの定義を429IDiscoveryに
変えててためしてみてください。ファイルの読み書きはSPI接続のMMCなので別途sdカード
スロット取付等の配線作業が必要です。

SPIの4つの信号線は22〜47kohmでプルアップを忘れずに!
また429I-Dsicoveryはオンボの+3.3Vレギュレーターが550mAまで出せるのでSDカード
一枚程度なら別途3.3Vの電源を用意する必要もないです。


↑しかし液晶載せたおかげでSTM32F4Discoveryよりでかい…
 その液晶がIPSやMVAじゃなく普通の視野角が狭い液晶なのは減点ポインツです#

なにはともあれこれをたたき台にしてSTM32F429I-Discovery専用に改造
しまくっていきましょう!

OpenOCD小ネタ3 -ぱっちを提出したお話-

前回OpenOCDは急速に廃れつつある…とお話しましたが、この記事を書いている
2013年の11月上旬現在では日本のホビーユーザー間コミュニティではもはや見向きも
されなくなり、ほぼ壊滅状態になってしまいました。
限定解除したmbedCooCoxが強すぎです。

思うに私のぶろぐを含めたwebにあまたに点在する"丁寧な環境構築の解説"は作成
したそばからすぐに陳腐化してしまい役に立たなくなり新規参入の方々にとっては
それが逆に導入における重大な障壁となったからなのでしょう。しかも導入における
アプローチの仕方は人それぞれ千差万別で何通りもあります。多過ぎる選択肢という
のは相手の興味を確実に喪失させます。無償といえどもその恩恵を得るために時間
という貴重な対価を結局払うことになります。しかもたくさん時間をかけて頑張ってもうまく
できないかもしれません。得られたものが疲労だけということにもなりかねません。

良かれと思って行ったことが逆に仇になった結果ですが、それもまた運命…
結局タダより高くつく物は無いねといったお話でしためでたしめでたし(完)















…すみませんうっかり今日の記事を〆るところでしたね。


今回はねむいさんがOpenOCDのパッチを提出して公式のコミットにマージされるまで
の経緯をお伝えします。

2013年現在、OpenOCDはgitというバージョン管理システムにて開発がすすめられてい
ます。以前はソースコードの世代管理にsvn(Subversion)が使われていましたが、git
にはgerritという非常に効率的なレビューシステムをドッキングさせることができます。
これによりエンバグされた極悪パッチやコンパイルすら通らないf**kなパッチが開発者
に送られまくるような事が無くなりよりスマートな開発スタイルに成れたらしいです。

OpenOCDのサイトでは、ガイドラインとして作ったパッチをマージさせるための手順
も記されてはおりますが、ねむいさんはそれすら理解できる知能がありませんでした。
のでまず"どういう知識が必要か"の調査からはぢめました。

※当記事では作業を進めるうえで引っ掛かった部分の言及にとどめ、詳しい手順の
 紹介は致しません。ていうかできません。


●先ずgerritにアカウント登録を行う必要がある。
 真っ先にやるべきことはまずgerritに自分を登録することです。既にyahooのアカ
 ウントを持ってたら登録不要でyahooのアカウントでサインインできるようです。
 ねむいさんはVersaloonのBBS投稿用にyahooのアカウントがあったので、すんなり
 入れました。

 この時点で出来ることは他人のコードレビューにコメントつけたりスコアをつけたり
 ユーザネームの登録のみです。まだパッチの提出は不可能です。

●sshパブリック・キーをアカウントに登録する。
 sshとはこういうものだそうです。gerritにおいてはなりすましや非公開リポジトリ
 への通信傍受を防ぐために役に立ちそうです。
 
 こちらも手順が示されていますので特に難しいことではないはず…でしたが、使用
 していたMsys環境がsimonquianさん提供のものすごく古いやつだったので最初は全く
 駄目でした。結局Msys/MinGWのサイトから落とすことができるインストーラーを使って
 一切合切インストールして新しいMsysの環境を作成してパブリックキーの登録に成功
 しました。2009年の時点ではこんなのなかったはずなのでいい時代になりましたね‥
 Msysでは主にOpenSSHというのでSSHプロトコルを実現しているようです。

●リモートリポジトリのクローンを作成してローカルで作業開始
 この作業自身はOpenOCDのビルドで当たり前にやってることなので特に問題は
 無いはずです。
 今では有志の方が作成された猿でもできるGIT入門という非常に分かりやすいgit
 指南があります。これはありがたい…
 cloneし終わったらopenOCDのディレクトリに入ります。ここもOpenOCDビルド時と
 同じですね。

●新しいリモートリポジトリの追加
 ここでアカウントを取得/登録した意味が効いてきます。また、事前にwebブラウザ
 からgerritにsigninをしてないと失敗するのでご注意を。
 "git remote add review"でrsaパブリックキーのpassphraseが求められるので登録
 したパスワードを入力します。

●フックのインストール
 ねむいさんここでず〜〜〜っと詰まってました。"Permission denied (publickey)"
 というエラーで先に進めなかったのですが詰まってた時はまだsimonquianさんのMSYS
 ベースで頑張ってた頃で、まっさらのMSYS環境にしてからやり直すとあっさり通り
 ました…今までの苦労はなんだったんだ…。また、rsaパブリックキーが置いてある
 フォルダが正しく参照されてるかも重要で、私の64bit版Win7では以下のURLに置くこ
 とで成功しました。".ssh"というディレクトリがどこに出来ているか把握すべきです。
 "C:¥Users¥(ユーザー名)¥.ssh"

●名前とe-mailアドレスの登録
 フックのインストールを超えたらあとはトントン拍子です。
 ここも難なくクリア

●パッチの適用
 ここで初めてローカルリポジトリにパッチを適用します。ここも通常のOpenOCDと
 手順は同じです。

●変更をコミット


while(!done) {
work - edit files using your favorite editor.
run "git commit -s -a" to commit all changes.
run tools/checkpatch.sh to verify your patch style is ok.
}
 
 ねむいさんこの部分が何かのスクリプトと思い込んでて必死にshell上で実行しよう
 としてました…あほだ…。この一文の意味するところはパッチを適用するたびにこの
 一連のコマンドを施行せよという意味です。
 "git commit -s -a" を実行するとvimが起動してコミット内容の編集画面になります。
 つまりvi(vim)をインストールしてないとエラーで失敗します。
 vimで編集する気がない人は"./git/COMMIT_EDITMSG"の内容を直接メモ帳等で
 編集してもいいです。ここの文章構成は下記のテンプレートに沿って書かないと
 チェックで撥ねられたりレビューサーバに上げた後に怒られたりします。

topic: summary text
(一行あける)
preliminary text
(一行あける)
Signed-off-by: "user name"

 ねむいさんが行ったコミットを例にとるとこんな感じにします。

fm3: fix Fujitsu MB9Ax family support

Some MB9Ax (especially few internal SRAM model) fails programming
because of wrong SRAM basic-address on running algorithm.
Default SRAM basic-address must be 0x20000000.
This patch is fixing default SRAM basic-address and ramcode offset.
Tested on a MB9BF618T and MB9AF112K.

Signed-off-by: Nemui Trinomius


●衝突してないかチェック
"git pull --rebase origin master"で他の人と衝突してないかチェックできます。
OpenOCDの場合はそこまで活発ではないのでぶつかることはまずないでしょう。

●gerritサーバーに登録
"git push review"で上で編集した要約とともにパッチが提出されます。
送られたパッチはまずOpenの場所に上がります。そしてjenkinsという自動ビルド検証
プログラムにて最低限ビルドができるかどうかの審査が機械的に行われます。そして
他の人にコードレビューを受けて間違いやもっといい提案を受けてさらに修正します。
修正はローカルリポジトリにパッチを適用したソースコードからさらに修正を行います。
必要ならばメーリングリストにてさらに議論を進めたりもします。修正が完了したら、
"git commit --amend"
"git push review"
の二つのコマンドでgerritレビューサーバのPatchSetナンバーを上げて更新されます。

こうしてレビューを繰り返してプラススコアがついてきたころにgerritレビューサーバー
を仕切っているntfreakさんによって"cherry-picked"されてマージされます。
マージされたパッチはこんな感じに履歴に残り、ねむいさんがOpenOCDのプロジェクト
に貢献したことがわかる仕組みとなっています。かぁーっ!(地獄のミサワみたいな顔で)
↑そいえばjenkinsのジジイのミサワverがすでにネタ絵であったりしますね…
ちなみにntfreakリンサンのGitHubから見るとこんな感じです。


参考にさせてもらった日本語のサイト
jugyo様:僕が Gerrit について理解している数少ないこと
 基本的な概念・操作について。
mkouhei様: git stashでハマる。
 OpenOCDのパッチ提出手順では競合時の解決が書いてませんのでこちらを参考に
 させていただきました。

こんな感じで実作業を通じてgitやgerritの仕組みを学んできました。でも私自身も
まだごくごく一部しか理解してませんので他の人に教えられるようになるまで勉強
していきます。

OpenOCD小ネタ2

2013年に入ってホビー向けARMマイコンを取り巻く情勢も大幅に変わりました。
導入に結構な金銭的コストが必要だったmbedが、ハードウエア&メーカーの枠が取り外
され、非常に低コストでいろんなメーカのARMマイコンに利用できるようになりました。
さらにARM社も、CMSIS-DAPというCortex系マイコンに特化したオープンソースの
デバッガハードウエアを公開したことにより同じようにGNUのツールに頼らずとも低コスト
で専用のデバッグ環境をそろえることができるようになりました。
導入の敷居を低くすることによりARMマイコン利用者のすそ野を大きく広げる作戦に
出ているようです。

んでもってCooCox等(のEclipseベースですが面倒な初期設定がすべて準備されかつ
無料で全機能が利用できるデバッグサーバ込)のIDEも使い勝手が飛躍的に向上し環境
構築のために時間を費やす
orデバッガのデバッグをすると言った無意味で無駄な
行為をする必要もなくなりました。

そういうわけで使いこなせるまでに多くの時間と手間がかかるOpenOCDは最早無料で
利用できる
といった唯一のアドバンテージも急速に失いつつあります。しかしながら、
私を含めた手段が目的になっちゃった人向けに細々とOpenOCDの解説記事を書いて
いく所存でございます(以上泣き言終わり)。




●STLink系のアダプタ使うとSPANSIONのFM3マイコンでeraseができない
私がFM3ドライバのエンバグをしていたちょうどその頃、jujurouさんが自身のブログ
上にてSTLink/V2を使用したFM3マイコンの書き込みについて質問者の方とやり取り
されていました。私は"単なる結線ミスでしょう"と思ってましたが丁度MB9AF112Kの
テストをしてたのでこちらでもSTLink/V2でやってみるとなんとeraseだけできなかった…。
Versaloon(SWD版)やJTAGKey2では問題ないのにSTLink系は駄目。

書き込み動作だけはSTLink系でも可能だったのでOpenOCD側のフラッシュドライバを
調べてみるとeraseの操作はtarget_write_u16を使用しレジスタに16bitのデータを送る
ことにより行われていました。分かりづらいユーザマニュアルを見るとたしかにフラッシュ
操作のコマンドは真の16bitアクセスを行う必要があると記述されていました。

一方STLinkやTI-ICDI等のHLAなアダプタはターゲットのメモリの読み書きは32bitか
8bitかのどちらかしかサポートされておらず真の16bitアクセスが不可能でした。
つまりeraseしようとしてtarget_write_u16で必死に送っても32bitか8bitかの転送コマンド
APIに置き換えられてしまい失敗していたということになります。

書き込みの時は問題なかったのは書き込み時は書き込みアルゴリズムを転送してFM3
上で実行してるのでこの制約に関係なくwriteコマンドが成功していたからでしょう。

というわけでeraseの際もアルゴリズムをFM3上で実行するようにしてSTLink/V2でも
無事FM3マイコンに書き込みができるようになりました。ついでにjujurouさんの所で
質問されていた方も上記のパッチを当てたバイナリを使用し無事に解決されたようです!
めでたしめでたし。

20140227追:
公式にマージされました♥



●USB3.0のホスト(xHCI)でOpenOCDが繋がらない問題は決着か

以前いいところまで原因を追い詰めましたがUSB周りの事は全く分からずドライバを
以前のものに戻してworkaroundとしていました。しかし同様の問題を抱えた方がいた
ようで、その方は自力で解説策を見出したようです
。結局ASM1042のドライバのバグが
濃厚で正直libusbx(libusb-1.0も同様)は全く悪くはないのですがlibusbx側で回避
可能なので何時になるともわからないメーカサイドの修正を待つより自分でちゃっ
ちゃとlibusbx側に対策を講じた方がよいのは私も賛同します。

というわけでパッチを当てたlibusb-1.0.dllを作成しねむいさんの環境では動作OK
かつ副作用も全くなし!以前質問を頂いた方々にも協力していただき問題は全て解消
されたとの報告をいただいたので、おきぱで公開しているOpenOCD・UrJTAG・Avrdude
そしてFlashROMはすべてこのパッチを適用したdllとスタティックライブラリを反映
しております…っていうか差し替えたのもうだいぶ前ですが何も不具合報告は頂いて
ませんので便りがないのはよい便りということで〜(それでいいのか)

また、USB3.0のホストのドライバ/ファームウエアも最新のものにアップデートしてお
かないと不具合につながるケースがあります。libusbxのwikiにはそのことに対する
注意書きも記載されています
。USB3.0ホストが搭載されたここ最近のPCで上手くいか
ない方はstation-driversで最新のものに変更してから試みることも忘れずに。


"Remote 'g' packet reply is too long"問題も決着か
長かった…ねむいさんのぶろぐに来た質問でかつて一番数が多かったこの問題も漸く
解決の日の目を見ることになったようです。
"とりあえずFPレジスタ無しをデフォルトにするから弄りたい人はtdescコマンドでxmlを指定
してレジスタ設定してね"という流れになるようです。さすがに昔のGDB使ってる人も少なく
なりましたからこの変更は必須だとおもいます。

OpenOCD小ネタ1

今回からOpenOCD一般に関わる事はOpenOCD小ネタとして個別に書くようにしました。
正直いうとgerritにパッチがびしばし届いていてぶろぐでちんたら解説してる暇あったら
新しいパッチの検証すべきとかそんなレベルですが、いくつか致命的な事柄を取り上
げて行きたいと思います。ぇっと私は悪くないんです!!
ねむいさんの言ってることがよくわからないって人はOpenOCD0.9.0で以下の機能が
追加されますよ〜という程度に捉えてください…。
完全に自前でOpenOCDビルドしてるようなマゾな人たちのための記事です…



●LPC800シリーズのフラッシュ書き込みに対応
このコミットから巷で噂のLPC800シリーズのフラッシュ書き込みに対応しました!
mbedやLPCXPressoなどのお仕着せ開発環境は一足お先に対応してたようですが、こちら
も一転攻勢で巻き返しを図りたいところです。しかし…このコミットの変更はまだ
不完全で、竹澤さんに指摘された通り構造体の未初期化が発生してセグメンテーション
フォールトになる危険性をはらんでいます。

ねむいさん側ではすでに不具合修正版のパッチを作成しておりますのでこれを適用して
ビルドしてもらえばOpenOCDごと落ちる不具合は解消します。さらに少し前にlpcforum
の書き込み
から気づいたLPC43xxシリーズのフラッシュありモデルでISPモードで起動
しないと正しく書き込めないという不具合もばっちり修正済です♥
LPC43xxのIAPは49番(IAP初期化コマンド)が追加されてるのですね…エラッタ回避かしら?
とにもかくにも結果オーライですよぅ☆
20131009追:
構造体初期化の不具合は修正されました。


●FM3シリーズの対応機種増加
このコミットではSPANSIONのFM3マイコンの新しく追加された機種、MB9A系のフラッ
シュ書き込みに対応しました…が、jujurouさんのパッチを基に自分路線でパッチを
作ったのが災いしてやはりバグった状態でマージされる最悪の事態に!!
現在販売中のTなんたらが動くMB9AF312Kボードで書き込もうとすると100%失敗するので
不具合修正版のパッチを適用してビルドして使用してください…すみませんすみません

Windows使いの人はビルド済バイナリ
なんかもありますのでご活用ください…
20131129追:
この不具合は完全に修正しました!


●NuvotonのNUC120/M051の書き込みに対応
こちらのコミットはNuvotonのNUC120やM051などのフラッシュ書き込みに対応してます。
ベースはこちらの方のwikiです。kinetis-Lシリーズのときと同じくIAPコマンドでちまちまと
低速に書き込みを行う物です。ねむいさん側ではすでにバイトコードを流しこみ高速化する
パッチ
を作成済です。しかし最悪なことにねむいさんのドライバがこれと丸かぶり
なのです…マージする前に気づけYO!


とりあえず9月末はこんな感じです。
とにかくあとからあとからやってくるのでもう大変です…
あとねむいさんの英語力が試されまくりです…もちろんぜんぜんだめ 
orz

Go to top of page