OpenOCD小ネタ28 -もうすぐ0.12.0になりそう-

8月の終わりに入ってから残業規制出向規制すべて解禁となったおかげで
鬼シフtじゃなくてガンガン仕事入れまくったおかげでぶろぐのネタが全く
すすんでません…

特にCodeLiteを使ったGDBデバッグ手順の公開を待ってる方もいるかも
しれませんが今やってる副業(本業は二次裏メイド)の案件がもう少しで
片付くので10月中くらいには何とかしますので耐えてください…

ということでOpenOCDが0.12.0になったなりそうなのでちょっとめぼしい点を
2，3点かいつまんでお茶を濁します…



●SWDマルチドロップのサポート…がまだできてねぇ！
RaspberryPiPicoの復旧でOpenOCDでPicoをデバッグしたいという需要も増え、
つい最近SWDマルチドロップのサポートが強化されておりました！私もさっそく
手持ちのRaspiPicoで試してみました！


…
ファ〇ック！！！！！１１１！１


だめだぁ〜〜ぜんぜんまともに動いてないじゃん…


皆様ご存じとは思いますがRaspi公式のgithubで公開されているRaspiPico用の
ブランチはすでに昨年初めの時点でSWDマルチドロップられるし普通にデバッグ
できるしフラッシュも余裕で書き込み出来ちゃいます・・
OpenOCDの本家さん頑張ってくださいよ〜ねむいさん多忙すぎて最近OpenOCDの
ソースから離れちゃったからねむいさん以外の人ががむばってほしい
(☝他人任せ)


しかもRaspi公式のブランチは一昔前の0.11系のやつで最悪なことにftdiなどの
interfaceの設定に使用するcfgファイルが現在の0.12系の奴と互換性がありません
かつてはPi用のOpenOCDも同梱してたのですが現在は分離しております。
ねむいさんが公開しているOpenOCDは現在本家最新のコミットとRaspiPico専用
SWDマルチドロップ対応の物の二つを紹介しております。

・本家最新コミットのビルド
・RaspiPico専用ブランチのビルド

何とか両者が統合してくれることを願うばかりですね〜…ほかにもnuvotonや
ESP32などのブランチも宙ぶらりんになってるのでESP32のほうはだいぶシンクロ
してきてるようですが頑張っていただきたいですね…(他人任せ



●OSなしでデバッグ時にエラーメッセージが延々と流れるのが治ってた
読んで字のごとくです

デバッグ続行自体は可能な動作に致命的なもはないのですがステップ実行のたび
延々と"No RTOS could be auto-detected!"とエラーが垂れ流され続けるので、
ねむいさんも業を煮やして結構苦しい修正をしてました。

diff -urN b/src/rtos/rtos.c a/src/rtos/rtos.c

--- b/src/rtos/rtos.c	2018-09-09 21:28:02 +0900

+++ a/src/rtos/rtos.c	2018-09-09 21:19:18 +0900

@@ -245,6 +245,7 @@

 			/* Autodetecting RTOS - try next RTOS */

 			if (!rtos_try_next(target)) {

 				LOG_WARNING("No RTOS could be auto-detected!");

+				os->symbols = NULL;

 				goto done;

 			}


公式の修正はもうちょっとスマートですがもちろん問題も修正されスムーズに
デバッグできたので満足しております。9月末までの修正を盛り込んだOpenOCD
バイナリは上でも紹介しましたがおきぱにて公開しておりますので皆さまガンガン
お使いください！





OpenOCD小ネタ27-GDBInsightを2022年になっても使い続ける奴-

皆様あけましておめでとうございます。
今年もいきなりこんな感じでダラダラ続けさせていただきます…！



さて私のARMマイコンの開発環境は軽さをモットーとしたmake一発のコマンドライン
ビルドをベースとしたものを10年以上前のXP時代のころから一貫して続けております。

さてWindows11の時代になり、その環境も過去のOSではできていたことができなくな
ったりしてその都度回避策を講じながら使用してきておりましたが…


GDBのGUI版のInsightデバッガがだいぶガタピシになってまいりました。何かする
度にフリーズしたり落ちたりでもはやだましだまし状態ですが
今の懸念はレジスタウインドウを開いたら速攻落ちる現象ですが何とか対処法を
見つけましたのでご紹介します。

先にこちらとこちらのARMマイコン環境構築手順を軽く見ておいて下さい。
InsightのインストールディレクトリはC:¥Devz¥ARM¥insightとします。

レジスタウインドウはTCLスクリプトregwin.ithで構成されており、以下に示す
ディレクトリに存在します。
./insight/share/insight1.0/regwin.ith


そして、上記要領で49行目の_layout_tableをコメントアウトします。
これだけでデバッグ動作に入ったらレジスタウインドウ開いただけで落ちる現象は
ひとまずなくなります。


上記措置を行うとレジスタウインドウを開いた際にまずこんな感じの見た目が変な
ウインドウが開く…もともとの動作としてはallのタブがまず開くがこれがまずいらしく、
OpenOCD側のtarget_get_gdb_reg_list_noread実行時にInsightが落ちてしまうのです。
_layout_tableのコメントアウトでそれを停止?させます。


"General"を選択すると一般レジスタウインドウが開きます。


とりあえずレジスタを見ながらデバッグが再びできるようになりました。
まぁこれでwin10以降でもごまかしごまかししながらInsightをつかいつづけr


あああああアアァーーーー！！！！１！1！


ううむ絶対安定とはいえず40回に一回くらいはひでぶしてしまいますね…




…



と、いうわけでそろそろInaightから脱却して別のGDBデバッガUIを使用したいと
思っており、現在CodeLiteというIDEを評価中です。Windowsのアプリケーション
開発向けのIDEですが細かい設定ができ、ARM-GDBとOpenOCDと連携してデバッグが
できそうなのを確認しております。
全部入りのIDEですがどっかのEclipseと違って起動も動作Insight並みに軽いです。

こちらの再現性が十分取れたらInsightを使ったデバッガとともにCodeLiteを使った
デバッグ方法も紹介していきたいと思います。

OpenOCD小ネタ26 -とうとうXPともお別れ-

とうとうこの時が来てしまいました…
ねむいさんのぶろぐ創設時より長年サポートし続けてきたWindowsXPともお別れ…！


どういうことかというとOpenOCDがリンクしているlibusbのWindowsXPのサポートが
コードからオミットされて終了してしまったのです…もうXPで動かせません。

Oh...my...ｺﾝﾌﾞ


XPのマイクロソフトのサポートが終わってもう6年、Windows7のサポートすら終わった
のでXPはこれで完全にお役御免と相成ったわけです。
まぁ実際の開発の現場じゃ昔のソフト動かすためにバリバリの現役だったりするのです
けどもそれは特殊な状況ですから今日日の普段使いのWindows系OSはすでに使いづらい
Win10に切り替わっていると思います。


というわけでOpenOCDバイナリのダウンロードページのリンク先の奴はすでにXPサポート
はオミットされた最新のlibusb1.dllが梱包されたものに変わっております。
まだXPで踏ん張ってる人はこちらの最終verをご利用ください。


同じくして他ツールも今回のlibusbがらみで更新を適用し、最新化をしました。
UrJTAG、FlashROM、そしてavrdudeが影響を受けてwindows7以降専用となって
おりますのでご注意願います。
また、64bitOS下でも32bitバイナリで不都合はないため、利便性を重視して
x86版でもx64版でもどちらのOSでも使用できるようにOpenOCDも含めてすべて
32bitバイナリのみの提供とさせていただいております。

OpenOCD小ネタ24 -ビルドするときの小ネタとかも-

もうすぐ2月ですが
あけましておめでとうございますした！

今年も皆様に役に立つ情報を提供していきますのでどうぞご贔屓に☆
なお、新しい副業先(本業は虹裏メイド)ではこのぶろぐの事は完全に隠匿している
ため｢あ、こんにちはネムイさん(ﾌﾟｰｸｽ｣とかおちょくられることはないのでねむい
さんもいないさんのぱんつがみえてるｲﾗｽﾂとか安心して公開
…とかは多分しませんので他の方が学校や職場から見ても問題ないような
記事の充実をしていこうと思います。あとdropboxの画像の復旧がむばります…。



本題に入りますが2019年最初のOpenOCDバイナリ最新版も公開しております。
皆様どしどし使ってください☆




●OpenOCDビルドするときにJIM-TCLの所でコケる対策
昨年10月くらいのアップデートからMSYS環境下でOpenOCDをビルドする際に下記の
変なメッセージを出してJIM-TCLのコードがclone出来ずOpenOCDのビルドが先に進ま
ないという問題にぶち当たりました。

fatal: unable to access 'https://repo.or.cz/r/jimtcl.git/': SSL certificate problem: unable to get local issuer certificate


なんでや…これでOpenOCDのgerritにもパッチあげられてるのに…
仕方ないのでいろいろ調べていると回避方法が見つかりました！
git config --global http.sslVerify false

"http.sslVerify false"でぐぐるとメジャーな問題だったようでねむいさんのアンテナ
の低さに自分自身で情けなくなってしまいましたorz
ねむいさんのOpenOCDぱっち詰め合わせの中にあるビルドスクリプトにも上記の対策と
ついでに64ビットOS環境下でMSYSを動かしたときに動きが鈍くなる対策も突っ込んで
降りますのでご参考に(openocd_update_s_libftdi参照)。

●libusbもアップデートしてるが…
1.0系が完全に定着したlibusbですが現在も時々刻々と機能追加や修正がくわえられて
アップデートし続けております。linux系OSでもWin系OSでもビルドできるようにgitで
ソースコートが管理しておりますがたまに特定のOS環境下でしか確認せずにエンバグ
された状態でマージしやがるやつがいます####(OpenOCDでも度々見られますが…)
これの修正は強烈でした。この修正が入った以降のコミットでビルドされたdllを使用
したら問答無用で落ちますorz
追加されたlibusb_wrap_sys_device関数のおかげでdll召喚した瞬間にお陀仏ですorz

仕方がないのでlibusb_wrap_sys_deviceのファンクションコール(Windows系OSでは
使用されていない模様)をまるまる削ったdllで事なきを得ております。
ねむいさんの公開しているOpenOCDバイナリにもこの修正がかかったlibusbのdllを
使用しておりますので安心してご使用できます☆

20190131追:
やっと直りました…F++K!


●壺の件
LPC800系のOpenOCDのパッチは、先にねむいさんが提出したnumicroのパッチがマージ
されたら提出しますのでそれまではねむいさんのOpenOCDバイナリを使用して頂きたく
思います。でもNxPのマイコンをわざわざSTLinkで使う物好きな人とかあんまりいな
いので殆どの人はこのバグに気づいていないでしょう〜

全部こいつのせいだ〜！ねむいさんはわるくないぞ〜！

●ブレークポイントで止まらねぇ！
OpenOCDのCPUコアに近い場所にパッチが当たった場合その影響がたいぶ後になって
気づくことが多々あります。
ねむいさんの提供しているSTM32F7向けのOpenOCD用cfgファイルはQSPIフラッシュが
ついてない基板でも動作できるように"gdb_memory_map disable"というオプションを
着けておりました。しかしながらそれのせいでコアにパッチがあてられたあたりから
ブレークポイントで止まらず特にmainの先頭とかで止まらずまともにデバッグが
できなくなってしまいましたorzまたですか…☠

ねむいさんの提供しているcfgは内蔵フラッシュからの起動/デバッグを想定している
ので対策は一応あります。cfg内で"gdb_memory_map disable"を記述した直後に下記の
一文を追加するとブレークポイントを貼った場所に止まることができるようになります。
"gdb_breakpoint_override hard"

多分RAM起動だと副作用でまくると思いますがフラッシュの書き込み耐用回数が増加
した現在ではそういう運用することはあんまりないので大丈夫とは思います。
また、正式には未だマージされていないQSPIのフラッシュ対応(XIP:直接実行)も配慮
した今回の修正なので、もし正式にQSPI対応になったら本腰入れて動作検証を重ねて
行こうと思います。

OpenOCD小ネタ23 -新機能続々更新-

夏が終わったと思ったらもう冬かよ…秋はどこだ…


さて、そうこうしているうちにOpenOCDも着々とバグフィクスや新機能が追加されて
おります。そろそろV0.10からV0.11になっても良いと思いますがgerritで管理され
てる全員参加型のフリーウエアにそれを求めるのはあまりにも野暮ですがそれはおい
説いて紹介させてもらいます。


●CMSIS-DAPの速度がアップ！
CMSIS-DAPはARM肝入りのフリーなデバッガアダプタで最近販売されている安価な
Cortex-Mx系の評価キットでは欠かせないものとなっております。

ねむいさんのぶろぐでも2014年にいち早く紹介させてもらっています。当初はマイコンへの
書き込み速度が非常に遅く使い物にならなかったのですがその後機能強化されようやく
実用レベルに、そして今回の修正ではさらにスピードアップとなっております☆
もっとも2017年春にはすでにパッチが上がっていてねむいさんが提供するバイナリには
そのパッチが適用されておりましたので皆さん実は気づかず使用されていたことになります！


それではさっそく比較してみましょう。
今回CMSIS-DAPを仕込んだLPC1549Xpressoを引っ張りだしてきて32kByteの
バイナリを書き込み、ベリファイを行いそれぞれの経過時間を比較しました。
●修正適用前

> "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 32768 bytes from file main.elf in 2.525144s (12.673 KiB/s)

verified 29400 bytes in 0.426025s (67.393 KiB/s)

shutdown command invoked



> Process Exit Code: 0

> Time Taken: 00:04

●修正適用後
> "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.10.0+dev-00563-gda4b2d5-dirty (2018-10-29-08:10)

Licensed under GNU GPL v2

For bug reports, read

	http://openocd.org/doc/doxygen/bugs.html

Info : auto-selecting first available session transport "swd". To override use 'transport select '.

none separate

cortex_m reset_config sysresetreq

adapter speed: 1000 kHz

Info : CMSIS-DAP: SWD  Supported

Info : CMSIS-DAP: JTAG Supported

Info : CMSIS-DAP: FW Version = 1.0

Info : CMSIS-DAP: Interface Initialised (SWD)

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 DPIDR 0x2ba01477

Info : lpc1549.cpu: hardware has 6 breakpoints, 4 watchpoints

Info : Listening on port 3333 for gdb connections

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

xPSR: 0x01000000 pc: 0x030000b8 msp: 0x02001fe0

auto erase enabled

wrote 32768 bytes from file main.elf in 2.477142s (12.918 KiB/s)

verified 29400 bytes in 0.425024s (67.551 KiB/s)

shutdown command invoked



> Process Exit Code: 0

> Time Taken: 00:03


書き込み速度だけ抜き出して比較
前 :wrote 32768 bytes from file main.elf in 2.525144s (12.673 KiB/s)
後 :wrote 32768 bytes from file main.elf in 2.477142s (12.918 KiB/s)
…
あらら…140%早くなるんじゃないの‥？？
…まぁちょっと早くなったしまぁいっか！


●NuvotonのNuLinkに対応！
台湾NuvotonのCprtex-M系マイコンNumicroシリーズ、数年前にねむいさんがフラッシュ
書き込み対応させて以来即効飽きて放置してましたが…なななんと！
Nuvotonの開発チームの人が直々にNuvotonのCortex-Mx向けのデバッガNuLinkを
OpenOCDに対応してくれました！！！！１１！！！


ちなみに秋月で購入できるNuvotonのキット付属のNulinkはUSBコンポジットデバイスで
制御対象マイコンとつながるのはUSB-HIDとなっており、これだけで動作させるならば
ドライバすら不要です☆

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

openocd  -s C:/Devz/ARM/OCD/tcl -f interface/nulink.cfg -c "transport select hla_swd" -f target/numicro_swd_flash.cfg -c "mt_flash main.elf"

Open On-Chip Debugger 0.10.0+dev-00563-gda4b2d5-dirty (2018-10-29-08:10)

Licensed under GNU GPL v2

For bug reports, read

	http://openocd.org/doc/doxygen/bugs.html

hla_swd

Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD

adapter speed: 1000 kHz

none separate

Info : clock speed 1000 kHz

Info : NULINK is Nu-Link1

Info : NULINK firmware_version(6386), product_id(0x00012009)

Info : IDCODE: 0x0BB11477

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

Info : Listening on port 3333 for gdb connections

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

xPSR: 0x01000000 pc: 0x0000035e msp: 0x20003fd0

auto erase enabled

Info : Device ID: 0x00012000

Info : Device Name: NUC120LE3AN

Info : bank base = 0x00000000, size = 0x00020000

Info : Nuvoton NuMicro: Sector Erase ... (0 to 41)

Info : Nuvoton NuMicro: Flash Write ...

target halted due to breakpoint, current mode: Thread 

xPSR: 0x61000000 pc: 0x2000002e msp: 0x20003fd0

target halted due to breakpoint, current mode: Thread 

xPSR: 0x61000000 pc: 0x2000002e msp: 0x20003fd0

target halted due to breakpoint, current mode: Thread 

xPSR: 0x61000000 pc: 0x2000002e msp: 0x20003fd0

target halted due to breakpoint, current mode: Thread 

xPSR: 0x61000000 pc: 0x2000002e msp: 0x20003fd0

target halted due to breakpoint, current mode: Thread 

xPSR: 0x61000000 pc: 0x2000002e msp: 0x20003fd0

target halted due to breakpoint, current mode: Thread 

xPSR: 0x61000000 pc: 0x2000002e msp: 0x20003fd0

target halted due to breakpoint, current mode: Thread 

xPSR: 0x61000000 pc: 0x2000002e msp: 0x20003fd0

target halted due to breakpoint, current mode: Thread 

xPSR: 0x61000000 pc: 0x2000002e msp: 0x20003fd0

target halted due to breakpoint, current mode: Thread 

xPSR: 0x61000000 pc: 0x2000002e msp: 0x20003fd0

target halted due to breakpoint, current mode: Thread 

xPSR: 0x61000000 pc: 0x2000002e msp: 0x20003fd0

target halted due to breakpoint, current mode: Thread 

xPSR: 0x61000000 pc: 0x2000002e msp: 0x20003fd0

target halted due to breakpoint, current mode: Thread 

xPSR: 0x61000000 pc: 0x2000002e msp: 0x20003fd0

target halted due to breakpoint, current mode: Thread 

xPSR: 0x61000000 pc: 0x2000002e msp: 0x20003fd0

target halted due to breakpoint, current mode: Thread 

xPSR: 0x61000000 pc: 0x2000002e msp: 0x20003fd0

target halted due to breakpoint, current mode: Thread 

xPSR: 0x61000000 pc: 0x2000002e msp: 0x20003fd0

target halted due to breakpoint, current mode: Thread 

xPSR: 0x61000000 pc: 0x2000002e msp: 0x20003fd0

target halted due to breakpoint, current mode: Thread 

xPSR: 0x61000000 pc: 0x2000002e msp: 0x20003fd0

target halted due to breakpoint, current mode: Thread 

xPSR: 0x61000000 pc: 0x2000002e msp: 0x20003fd0

target halted due to breakpoint, current mode: Thread 

xPSR: 0x61000000 pc: 0x2000002e msp: 0x20003fd0

target halted due to breakpoint, current mode: Thread 

xPSR: 0x61000000 pc: 0x2000002e msp: 0x20003fd0

target halted due to breakpoint, current mode: Thread 

xPSR: 0x61000000 pc: 0x2000002e msp: 0x20003fd0

wrote 21504 bytes from file main.elf in 6.905395s (3.041 KiB/s)

target halted due to breakpoint, current mode: Thread 

xPSR: 0x61000000 pc: 0x2000002e msp: 0x20003fd0

target halted due to breakpoint, current mode: Thread 

xPSR: 0x61000000 pc: 0x2000002e msp: 0x20003fd0

verified 21288 bytes in 0.324018s (64.160 KiB/s)

shutdown command invoked



> Process Exit Code: 0

> Time Taken: 00:13

パッチを適用したOpenOCD書き込んだログはこんな感じです。
仕様上ちょっと癖があり接続しに行くと他のデバッガと違ってワンテンポ間が開く
感じで繋がります。そして立ち位置としてはTI-ICDIやSTLink系と同じHLA扱いと
なっております。ですのでAPの直叩きはできないので注意が必要です。

それとCMSIS-DAPのようには最適化されていないのかVersaloonの1/2くらいの書き込み
速度となってますね…今後の改良はNuvotonチームに期待ですね。


SW-DPの直叩き等の低レベルの操作はできないですが通常デバッグで行える操作、
レジスタ、メモリ参照などは問題なく可能です。
これでNuvotonマイコンもフリー環境で使い勝手が大幅に上昇した感じがしますね！




今回の修正を反映したOpenOCDのバイナリはすでにおきぱにありますのでどしどし
使ってください！NuLink対応はまだ公式採用ではありませんがねむいさんバイナリには
すでに適用しております！

また、今回のNuLinkの対応に当たり私がかつて統合したnuvotonドライバでデバッグ時に
一部動作がおかしくなる品種があることも突き止め、それの修正も加味しております。
これについては次回詳しく説明させていただきます！

OpenOCD小ネタ22 -STM32F7系CFG変更の件-

まだ6月ですがもう梅雨が終わりそうなくらい暑いですね〜
子供の頃の季節感覚だと6月に梅雨が終わり7月から夏！
て感覚なので実際の季節がそれに近くなってるのかも…


さて、OpenOCDのSTM32F7系向けのcfgファイルが更新されていますので
お知らせします。


内容はリセット時のクロック設定を内部高速クロックに変えて、さらにPLLを
経てコアクロック周波数160MHzにブーストしたものが反映されております。
スクリプトはオリジナルは…

$_TARGETNAME configure -event reset-init {

	# Configure PLL to boost clock to HSI x 10 (160 MHz)

	mww 0x40023804 0x08002808   ;# RCC_PLLCFGR 16 Mhz /10 (M) * 128 (N) /2(P)

	mww 0x40023C00 0x00000107   ;# FLASH_ACR = PRFTBE | 7(Latency)

	mmw 0x40023800 0x01000000 0 ;# RCC_CR |= PLLON

	sleep 10                    ;# Wait for PLL to lock

	mww 0x40023808 0x00009400   ;# RCC_CFGR_PPRE1 = 5(div 4), PPRE2 = 4(div 2)

	mmw 0x40023808 0x00000002 0 ;# RCC_CFGR |= RCC_CFGR_SW_PLL



	# Boost SWD frequency

	# Do not boost JTAG frequency and slow down JTAG memory access or flash write algo

	# suffers from DAP WAITs

	if {[using_jtag]} {

		[[target current] cget -dap] memaccess 16

	} {

		adapter_khz 8000

	}

}



$_TARGETNAME configure -event reset-start {

	# Reduce speed since CPU speed will slow down to 16MHz with the reset

	adapter_khz 2000

}

となっていますがねむいさん提供のOpenOCDバイナリはオリジナルから若干違います。


$_TARGETNAME configure -event reset-init {

	mww 0x40023C00 0x00000102   ;# FLASH_ACR = PRFTBE | 2(Latency)

	# Configure PLL to boost clock to HSI x 4 (64 MHz)

	mww 0x40023804 0x03001008   ;# RCC_PLLCFGR 16 Mhz / 8(M) * 64(N) / 2(P)

	mmw 0x40023800 0x01000001 0 ;# RCC_CR |= PLLON | HSION

	sleep 10                    ;# Wait for PLL to lock

	mmw 0x40023808 0x00001000 0 ;# RCC_CFGR |= RCC_CFGR_PPRE1_DIV2

	mmw 0x40023808 0x00000002 0 ;# RCC_CFGR |= RCC_CFGR_SW_PLL



	# Boost JTAG frequency

	adapter_khz 4000

}

コアクロックを上げた後クロックを上げていますが安全のためオリジナルと違って
4000kHzまでとしております(JLINKがこの周波数以上ではなぜか不安定)。

いずれにせよ使用感は変更前とまったく変わらない感覚ですので皆さま安心して
お使いいただけると思います！

OpenOCD小ネタ21 -Cortex-M系のcfgファイル大変更の件-

一か月経ってしまいましたが先月末OpenOCDに結構デカめの変更がマージされました。

内容はSWDのインターフェース(DAP)を持つコア、つまりCortex-M0,M3,M4,M7に対して
"dap create"というコマンドが付与され、OpenOCDを動作させるためのcfgファイルの
定義も一新されています。

2018年現在はCortex-M系のデバッグはもはやSWDが主流になっているのでTAPではなく
DAPがよりふさわしいという判断からこの変更が加わったと考えられます。


さて、具体的なcfgの変更内容は以下のようになっています。

swj_newdapの定義の下の行にdap createコマンドが追加され、さらにtarget_create
コマンドで先ほどdap createコマンドで指定した値を"-dap"の引数で付与する形に
変えられています。

使い勝手に関しては依然とまったく変わらずそのままの感覚で使用可能なので特に
注意することはありません。

ですがねむいさんが公開しているOpenOCDのバイナリはねむいさん特製のcfgファイルが
存在しているのでこちらの定義は手作業ですべて修正しておきました。
cfgごとに結構表記ブレがあり地味につらかったです。特にデュアルコアの奴はめどい。
一応できる限り実機確認は行い安全を確認したうえで公開しており、ぶろぐトップでも
注意喚起はしておりましたが冒頭で述べたとおり一か月経過して特に使用された方から
の不具合連絡もなかったので問題なく移行できたと思います。
バイナリとは別に単独で公開しているcfgも同様に更新しております。

そんなわけで地道に変更や改良が続けられているOpenOCDをこれからもよろしくお願い
します！いつの間にかOpenOCDももう12周年ですよぅ。
ああそうだこのぶろぐも来年で10周年だ。

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さんはドキュメントの修正対応かなり早いので特に気にしてませんがあまり
声高に言うとコワモテのくまさんに〆られるのｄ


そんなわけで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を所持している知り合いの方に頼んで３〜４日オーダーのフィードバック
速度でああでもないこうでもないを繰り返し、ついに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サポート開始です


１．基本的な結線は本当に正しいか
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対応の紹介で長くなりすぎましたので次回じっくりと解説させていただきます。

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月上旬現在では日本のホビーユーザー間コミュニティではもはや見向きも
されなくなり、ほぼ壊滅状態になってしまいました。
限定解除したmbedとCooCoxが強すぎです。

思うに私のぶろぐを含めた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