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バイナリは逐次更新
してまいりますのでばしばし使ってください！

STM32F7を使ってみる14 -HS ULPIでUSB-MSCを使ってみる-

みなさまあけましておめでとうございます

今年もねむいさんほか虹裏メイドたちをごひいきにm( )m
今年はねむいさんのイラストが100枚くらい増えますように
↑本音



さて新年早々ですがHALライブラリにバグを見つけたので解説しようと思います。

遡る事約一ヶ月前、ねむいさんはSTM32F7で新しい事をやろうとCubeF7に同梱されて
いるUSBライブラリとそのExamplesたちに手をつけ始めていました。
STM32F746G-DiscoveryにはULPIとかついているのでUSB-MSC(MassStorageClass)の
実装を試みました。もちろんUSBのバス速度はHighSpeed(480Mbps)です。

幸いにもSTM32F746G-Discovery向けのサンプルコードもあったのでそれを
ねむいさん謹製のいつものをベースに実装しようとしましたがUSBライブラリが
DMA使ってるくせにキャッシュの事全然考えてない作りでそれにブチ切れながら
GCC向けに移植していましたが最終的にL1キャッシュがないと足を引っ張る
SRAM1,SRAM2を使わずにノーウエイトでアクセス出来るDTCM領域だけでがんばる
ことにしました･･･orz

Ac6STM32用のプロジェクトファイルのリンカスクリプトもそうなってますし
･･･フォーラムでも奇跡の積み重ねで動いてると情けない指摘を
されています。HALライブラリみたいなバグだらけの変なものリリースしっ放し
にしてないできっちりバグつぶせYO!
☝って言ったらたくさん非難されていっぱい哀しい…


と言いつつも何とか動いて認識しました♥


もちろんeMMCとかもしっかり認識しちゃいます★


とおもったらまだ問題がありました…幾つかのカードでデータが正常に
読み込めない事がありました。


64GBのカードでも容量はしっかり見えてるんですけどね…なんか4GB以上
データを詰めてるカードで動作がへんなのです…
…
…4GB…？これって…

かつてUSB付きのARMマイコンでMSCのサンプルではカード容量を示す変数が
uint32_tで現わされていて4GB以上の容量を正しく表示できないという
4GB問題がありました。対策は単純に容量を示す変数をuint32_tから
uint64_tへ変えるだけのものなのですがUSBライブラリを見る限りでは
それはちゃんと64ビット変数になっており問題がありませんでした。


しかしブロックアドレスにブロック容量を掛け算し代入してやがる式を
見つけました。指定するブロックアドレスによってはuint32_tで扱える
範囲を超えてしまう可能性があります。このscsi_blk_addrって奴なのですが
まさか…まさか…


ﾃﾞﾃﾞｰﾝ
…
思いっきりuint32_tじゃん…
…
ば　っ　か　じ　ゃ　ね　ぇ　の　！　？
ねむいさんのむなしい叫び越えが夜の闇にこだまする。


ていうわけでscsi_blk_addrをuint64_t化すると4GB以上データ詰めている奴でも
正常に読み書きすることができるようになりました…なんちゅう初歩的な。

一応フォーラムにも報告しておきましたがSTM32フォーラムのguruと呼ばれている
clive師より｢ブロックアドレスをいれた変数にバイトアドレスに変換した値を放り
込むSTの昔っからのコーディング姿勢自体が愚。scsi_blk_addrの安易な64bit化は
不必要」と指摘されましたがねむいさんもごもっともだと思いました。



そんなわけで漸く正常に繋がるようになったので読み込み比較です。今回は
USBの転送用に確保していると思われるバッファの容量を増やすことで転送
スピードがどこまで変わるか見てみました。


条件STM32F746G-Diacovery,USB-HS ULPI,最適化オプションは"-s"
132MBのmp3ファイルをFastcopyを使ってPCのRAMDISKへコピーする時の平均転送速度を記録。
SDのクロックはNS(24MHz)とHS(48MHz)で比較。

ある程度分かっていたことですがやはり容量を増やしていくと転送スピードは
上がっていきましたがある程度(16kb以上)以上で転送スピードは横ばいになる
ことが分かりました。これはNSとHSもほぼ同様の傾向なので16384byte以上
パケット容量確保してもそれ以上は余り効果がないことが分かります。
まぁこれだけ速度出せたら御の字でしょう。とにかく16384byte分確保して
おけば何の問題もないですね。


ちなみに今回はお仕着せEclipse環境のAC6STM32で一旦プロジェクトをビルドして
ねむいさん環境に移植しましたが(単にリンカスクリプトをDTCMしか使わない
ようにしただけですけど)もっと性能の高いF769I-Discoveryで何で
試さなかったの？と言う話になるでしょうけど理由が…


CPUが対応してない･･･このせいでボード対応しててもビルドが通らないorz



やっぱ自分でmakefile書いてコマンドラインビルドが最強ですって☆

Go to top of page