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対応になったら本腰入れて動作検証を重ねて
行こうと思います。

Comments

ねむいさん様、はじめましてとなります。

ねむいさん版 OpenOCD にはお世話になりました。

最近 Nuvoton NUC126 を使い始めまして、

numicro.c の NuMicroParts[] に以下を追加して頂けると助かります。
/* NUC126 */
{"NUC126VG4AE" , 0x00C05231, NUMICRO_BANKS_NUC100(256*1024)},
{"NUC126SG4AE" , 0x00C05212, NUMICRO_BANKS_NUC100(256*1024)},
{"NUC126SE4AE" , 0x00C05213, NUMICRO_BANKS_NUC100(128*1024)},
{"NUC126LG4AE" , 0x00C05204, NUMICRO_BANKS_NUC100(256*1024)},
{"NUC126LE4AE" , 0x00C05205, NUMICRO_BANKS_NUC100(128*1024)},


よろしくお願いします。

あぷろ様こんばんは、ねむいです。

ご存じとは思いますが数年前にNuvotonスタッフがgerritに
あげたパッチがあっさり却下されたまま宙ぶらりんとなり、
gitのアカウントのほうはコアが古いままパッチが進んで
しまっている状態で私も下手に身動きが取れません
(自分がgerritに上げたパッチも取り下げるつもりです)。
https://github.com/OpenNuvoton/OpenOCD-Nuvoton

申し訳ありませんがOpenOCD公式のmasterに反映されるまでは
当面の間は自己ビルドで凌いでくださいっ！

ねむいさま、ご回答ありがとうございます。

自己ビルドで頑張るしかない状況、了解しました。

出口が見えませんがどうすればいいんでしょうね。

あぷろ様こんばんは、ねむいです。

宙ぶらりんのNuvotonドライバを何とかしてみました。
20191220版に更新しましたので差し替えて動作確認をお願いします。
NUC4xxシリーズとNUC126シリーズまで対応してみました。
Cortex-M23系はコアにガッツリ絡みついてたので無理でした…。
nemuisan.blog.bai.ne.jp/?eid=192848#OPENOCD

ついでにデータフラッシュのアドレスが可変な品種で
GDBのデバッグがうまくいかななくなる問題も修正しております。
ぱっちも更新しましたので実機デバッグが必要になったら
それで頑張ってくださいZzz...

ご対応ありがとうございます！

簡単に書き込み、読み込み、デバッグを試しました。問題なさそうです。

大大大感謝！

Post a Comment








Go to top of page