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に関してはそのまんまTCKに
つなげば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の中の人にこのぶろぐ焼き討ちされちゃいますのでこの辺に
しておいてあげます…








…さて戯言はこの辺にしといて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の牙城を崩すことができるのか？
それは時間が経てばおのずとわかると思います。

20230903追：
LPC810は無かったことになり、202309現在ではSTM32G0,STM32C0が攻勢を
強めております。特にSTM32C0は8マイコンを駆逐する勢いです！
20230903追：




おまけ

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が求められるので
　登録したパスワードを入力します。

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

"C:¥Users¥(ユーザー名)¥.ssh"

　".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