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