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

Comments

Post a Comment








Go to top of page