Launchpad's gcc-arm-none-eabi 4.9-2015q2を使用してSTM32F0用にコンパイルしていますが、そのコレクションからarm-none-eabi-gdbを使用してデバッグしたいと思います。私のST-Link v2は、Nucleo F411REボードの一部であり、外部ハードウェア(STM32F0ターゲット)が接続されています。 F0のフラッシュは正常に機能するため、SWD接続は良好であると結論付けます。
今、私は OpenOCD を開始したいのですが、失敗します:
$ openocd -f interface/stlink-v2.cfg -f target/stm32f0x.cfg
Open On-Chip Debugger 0.9.0 (2015-07-26-16:02)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 1000 kHz
adapter_nsrst_delay: 100
none separate
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : clock speed 950 kHz
Error: open failed
in procedure 'init'
in procedure 'ocd_bouncer'
ここで何が悪いのでしょうか?
St-utilを使用して接続を確立することもできませんでした。タイムアウトが報告され、結局常に segmentation fault でクラッシュしました。
Nucleo F411REはstlink v2ではなくstlink v2-1を埋め込みました
次のようにスクリプトファイルを変更します。
source [find interface/stlink-v2-1.cfg]
transport select hla_swd
source [find target/stm32f4x.cfg]
reset_config srst_only
ファイル stlink-v2.cfg
は大丈夫かもしれません。おそらくstlink-v2-1.cfg
ファイル(そのファイルはhla_vid_pid 0x0483 0x3748
)。
私の場合、Error: open failed
ですが、設定はすべて問題ありませんでした。それから私はdmesg | grep usb
USB経由で接続できない理由を確認します(Ubuntu)。 dmesgは、電源の問題があり、おそらくケーブルに欠陥があると私に言った。同じケーブルを同じ日に使用していて、ボードの一部のLEDがまだ点滅しているので、最初にメッセージを無視しました。しかし、私は最終的に試してみることにしました、別のケーブルを購入して見ました!それは欠陥のあるケーブルでした-新しいものですべてが機能します。したがって、結局のところ、必ずしもソフトウェアの問題であるとは限りません。
lsusb
(またはWindowsでデバイスマネージャーを使用)を実行し、ボードが適切にリストされている場合は、ケーブルの問題ではない可能性があります。不足している場合は、不足している可能性があります。
修正を見つけました。 stlink-v2.cfgのVID/PIDペアが間違っていました。彼らはこれを持っていました:
hla_vid_pid 0x0483 0x3748
しかし、それはこれでなければなりません:
hla_vid_pid 0x0483 0x374 [〜#〜] b [〜#〜]
数字の「8」ではなく、文字「B」。