STM32の開発環境を見直したメモ
STM32の開発環境を最適化したい話
STM32を久しぶりにいじったときに、デバッグできないぞってなったので開発環境を見直しました。忘れそうなので備忘録として残します。
正直ここらへんは弱者なので不安です。指摘していただけるとうれしいです。
(???「弱者じゃない分野あるんですか?」とツイートされること間違いなし✌)
問題点
ある一定のシリーズだけデバッグできない。CubeMXからSW4STM32もだめ。makefileだしてVSCodeでもだめです。(同じ条件でF446はデバッグ確認できました)
またSTLINK-Utilityでの書き込みなら書き込めます。
このことから問題点はopenOCD+arm-none-eabi-gdbの設定にあると思われます。(周りの人が使ってないマイコンだから設定間違ってるけどopenOCDのcfg変えるくらいしかわからないから死んだ)
VSCodeの構築はゆにきのブログを参考にしました。
http://yuqlid.sakura.ne.jp/wp/2017/12/01/stm32devenvvscode/
解決策1: デバッグしない(書き込みのみ)
STLINK-Utilityで書き込めるならデバッグしないで書き込もうという話です。ブレークポイントやレジスタの表示はできませんが、elfは問題なく生成させるのでSTMstudioで変数の監視ならできます。
書き込めないよりはいいかと思って、Atom上のショートカットで動作するmake+stlinkutilityの環境を作りました。これならIDEぽく高速なビルド&書き込みができます。
< この前の記事 >
解決策2: AtollicのTrueSTUDIOを使う
これを使えば100点はなまるです。
TrueSTUDIOはeclipseベースですが、最初に問題提起していたopenOCD+arm-none-eabi-gdbでデバッグを行わないので問題なくデバッグできます。(ここはAtollicオリジナル?)
しかもeclipseベースなのでSW4STM32と使用感やエディタの設定が一緒なので大変助かります。
以上、ここ2日大掃除とかしながら悩んでた解決策になります。
安定性とか再現性とか検証してなくてすいません。STMで同じ悩みを持ってる人の参考になれば何よりです。