STM32の開発環境を見直したメモ

STM32の開発環境を最適化したい話

Sat, 30 Dec 2017

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で同じ悩みを持ってる人の参考になれば何よりです。

 

© anbalab 2019