STM32Cube系ライブラリ移植への道

と
いうわけでSTマイクロの苦情隔離場でbugという文字が乱舞するいわくつきのSTM32Cube系
ライブラリへの移行を順次開始しました！
NUCLEO-F030板
NUCLEO-F401板
NUCLEO-F334板
おしまい。ぁー憑かれた…












すみません冗談です冗談！春先にも少し触れてすでにこれちょっと微妙だと判断を下した
STM32CubeF4をはじめとするCube系ライブラリは今までの"標準ペリフェラルライブラリ"
とは互換性が全くなく、バグも多数報告されていたのでねむいさんも移植に難色を示して
いました。が、最近発売されたNucleo系のボードに搭載された新しいMCUはもはや過去の
ライブラリには未対応となっており、事態を重く見たねむいさんもようやく重い腰を上げた
わけでございます。早く座らせてくれ。
(※以下、縮めて"HALライブラリ"と呼称します)


実はここ数か月でHALライブラリへの移行準備自体は着々と進めていて、その第一歩と
して手持ちのNucleo板のプロジェクトのライブラリを一気に移行していました。
現在手持ちは写真のとおり(って見た目同じですが) F030,F401,そしてF334の3つです。
それらのプロジェクトはごくごく基本的な動作のみを網羅した小規模なプログラムに
とどめていたのでまだ難易度は低く、移植の感触をつかむのにはうってつけでした。
私の公開しているプロジェクトは全てこちらの手順に準拠しているので移行後も不自由
なく同じようにビルドできるものを目指しました。

移行にあたってねむいさん的ポリシーは以下の要素に。
1.プロジェクトのディレクトリ構造は従来の物から大きく崩さない
　まぁ鉄則ですね。ケアレスミス防止目的でもあります。
　互換性を重視しすぎて不便になるのも本末転倒なので変えるべきところは変えます。

2.HALライブラリに依存する箇所をなるべく作らない
　これも鉄則ですね〜。またライブラリ大変更されたら目にも当てられないですし。
　抽象化のためにサイズが激増する冗長なコードがやたらと多いので分解・簡略化して
　別途作ったほうがいいです。一方でHALライブラリ使った方が分かりやすい周辺機器
　の初期化の箇所は割り切って利用していきます。
　
　ぇ？それじゃHALライブラリ使ってる意味無いだろですって！？
　無いですよ。

3.STM32CubeMXで生成されたひな形は利用しない
　STM32CubeMXは各開発環境ごとにHCLK/PCLKの初期化コードを含むひな形を自動
　作成するJAVAで作成されたプログラムを指します。ねむいさんの環境はGCCのコマンド
　ラインビルドに属する極めて原始的なものなのでひな形をそのまま利用できません。

　CubeFxのアーカイブにサンプルコードが収録されてるのでCubeMX使わずともそれ見たら
　殆ど事が足ります。おまけに生成されたコードが現状バグだらけでまったく信用出来ない
　ので100000000000000000000歩譲ってHCLKやI2C/I2Sクロック周波数の初期設定に
　軽く参考にする程度です。

4.メモリリソースはなるべくていうか絶対に許さ浪費しない！
　HALライブラリでは抽象化を上げるためインスタンスという概念が追加されています。
　それに付随する構造体が馬鹿でかいサイズなのでF0系ではSRAM領域を圧迫されすごく
　苦しくなります…なるべくグローバル変数で確保はしないように心がけましょう。


上記の点を念頭に入れて再構成したプロジェクトと従来のプロジェクトでビルドした
バイナリファイルのサイズの比較してみました。比較対象基板はF030板のです。
*STM32 StdPeriphDriver(STM32F030R8T6_NUCLEO_20140326.7z)

Built Object Informations:

=== Total Binary Size ===

   text	   data	    bss	    dec	    hex	filename

      0	   7216	      0	   7216	   1c30	main.hex

=== Verbose ELF Size ===

   text	   data	    bss	    dec	    hex	filename

   7096	    120	    328	   7544	   1d78	main.elf


*STM32 HAL Driver(STM32F030R8T6_NUCLEO_20140702.7z)
Built Object Informations:

=== Total Binary Size ===

   text	   data	    bss	    dec	    hex	filename

      0	   7916	      0	   7916	   1eec	main.hex

=== Verbose ELF Size ===

   text	   data	    bss	    dec	    hex	filename

   7796	    120	    412	   8328	   2088	main.elf

orz
フラッシュもSRAMも使用領域ががっつり増えてやがるorz

HAL Driverのスタートアップは"__libc_init_array"のリンクがあるのでC++の対応を
すててこれを取っ払ってみました
Built Object Informations:

=== Total Binary Size ===

   text	   data	    bss	    dec	    hex	filename

      0	   7828	      0	   7828	   1e94	main.hex

=== Verbose ELF Size ===

   text	   data	    bss	    dec	    hex	filename

   7708	    120	    412	   8240	   2030	main.elf

焼け石に水orz
SRAMを減らさなければ…

HALのSysTick関数"HAL_GetTick"は_weakで切られていてオミットできるのでやってみた
Built Object Informations:

=== Total Binary Size ===

   text	   data	    bss	    dec	    hex	filename

      0	   7820	      0	   7820	   1e8c	main.hex

=== Verbose ELF Size ===

   text	   data	    bss	    dec	    hex	filename

   7700	    120	    408	   8228	   2024	main.elf

フラッシュメモリで8バイト、SRAMは4バイト減りましたが焼け石に(ry

bss領域がインスタンスの確保で100byteも増えやがるのはF0系でかなり痛いんですよね〜。
こいつを追い出してみました。
Built Object Informations:

=== Total Binary Size ===

   text	   data	    bss	    dec	    hex	filename

      0	   7776	      0	   7776	   1e60	main.hex

=== Verbose ELF Size ===

   text	   data	    bss	    dec	    hex	filename

   7656	    120	    300	   8076	   1f8c	main.elf

雄々ッッ！！BSS領域が元より減りましたよ♥
もぅいいわこれで…もちろんスリムになってもちゃんと動作してます♥
※最初に取り除いた"__libc_init_array"はC++な人のためにリンクを復活させてリリースしてます。

今回の検証に当ってHALライブラリを使用したexampleの中で構造体の一部の要素が
未設定により起こる不具合がみつかりましたがまぁライブラリ自身の不具合じゃない
のでスルーで…(ねむいさんのプロジェクトでは明示的に初期化してます！)
そして話が冒頭の文章に戻るわけです。



ひとまずNUCLEO系板はすべて移行して最適化完了ですが残るDiscovery系の板のは
どうしようか考え中です。特にSTM32F4のいつものは多数のペリフェラルを使用して
いるので移植は本当に腰据えて一気に攻め上げないとバグを生んでしまいますからね…
しかしいずれは通らなければならない道だと思います。FATFSのSDIOとDMAの処理の
移植が峠になりそうです。

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のボードとともにご紹介させていただきます。

Go to top of page