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