シャツ一枚

Twitter: @Usugi_not_Usagi 間違っている部分等あれば連絡頂けますと幸いです

usbipd-winを使ってVSCode + WSL2 Ubuntu上でOpenOCD + Cortex-Debugを使う


VSCode関連の手順すっ飛ばせばもちろんOpenOCD単体でも使えます

環境

ホスト

Win10 21H1
WSL2 kernel 5.10.60.1
Ubuntu 20.04
VSCodeでWSLの設定済

ターゲット

  1. NUCLEO-L073RZ <-今回はこっちメインで話し進めます
  2. FT232H + STM32F103(Bluepill) <-ほぼ同様の手順で試して動きました

準備

ターゲットソースコード

私の場合はSTM32CubeMXでMakefileプロジェクトを作成して、WSL Ubuntu上でmakeしておきました

VSCode

WSL側にCortex-Debug拡張を入れる
Cortex-Debug - Visual Studio Marketplace

OpenOCD

Ubuntu 20.04の場合aptを使うと少し古いバージョンがインストールされてしまうのでソースからインストールします

git clone + ビルド

とりあえず今の最新メジャーバージョンのv0.11.0を使います

$ sudo apt install automake autoconf build-essential texinfo libtool libftdi-dev libusb-1.0-0-dev
$ git clone https://github.com/openocd-org/openocd.git
$ cd openocd
$ git checkout -b v0.11.0 refs/tags/v0.11.0
$ ./bootstrap
$ ./configure --enable-ftdi
$ make -j4
$ sudo make install

configureのオプション確認方法

$ ./configure --help

usbipd-win

Win側 usbipd-winをインストール
github.com WSL側 ツールをインストール
github.com

/usr/local/share/openocd/contrib/60-openocd.rulesを/etc/udev/rules.dにコピー

udevを再起動してルール再読み込み

$ sudo service udev restart
$ sudo udevadm control --reload

USBデバッガをWSLへ接続

管理人権限付きでPowershellを起動する

> usbipd wsl list
BUSID  VID:PID    DEVICE                                                        STATE
2-10   0b05:1960  USB 入力デバイス                                              Not attached
2-14   0483:374b  ST-Link Debug, USB 大容量記憶装置, STMicroelectronics STL...  Not attached

今回はST-Linkを接続したいのでBUSIDである2-14を使うとこうなります
接続されたかはもう一度listコマンドを実行すると確認できます

> usbipd wsl attach -b 2-14
usbipd: info: Using default distribution 'Ubuntu-20.04'.
> usbipd wsl list
BUSID  VID:PID    DEVICE                                                        STATE
2-10   0b05:1960  USB 入力デバイス                                              Not attached
2-14   0483:374b  ST-Link Debug, USB 大容量記憶装置, STMicroelectronics STL...  Attached - Ubuntu-20.04

WSL側でも接続されているかはlsusbで確認できます

$ lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 005: ID 0483:374b STMicroelectronics ST-LINK/V2.1
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

接続確認

ここまで来たらopenocdがちゃんとデバッガと通信できるか確認します

$ openocd -f "board/st_nucleo_l073rz.cfg"
Open On-Chip Debugger 0.11.0-dirty (2022-05-15-19:48)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
srst_only separate srst_nogate srst_open_drain connect_deassert_srst

Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : clock speed 300 kHz
Info : STLINK V2J34M25 (API v2) VID:PID 0483:374B
Info : Target voltage: 3.227803
Info : stm32l0.cpu: hardware has 4 breakpoints, 2 watchpoints
Info : starting gdb server for stm32l0.cpu on 3333
Info : Listening on port 3333 for gdb connections

gdbのポートがListeningになればOK

レッツデバッグ

VSCodeの実行->構成の追加を押してlaunch.jsonを作成

自分の環境に合うように設定

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Cortex Debug",
            "cwd": "${workspaceFolder}",
            "executable": "./build/L073RZ_blink.elf",
            "request": "launch",
            "type": "cortex-debug",
            "servertype": "openocd",
            "configFiles": ["board/st_nucleo_l073rz.cfg"]
        }
    ]
}

実行->デバッグの開始を選択して正しくプログラムが動作したらOK
今回使用したNUCLEOボードに載っているST-LinkはVCP機能があり、こちらもWSL上で使えます

$ ls -l /dev/ | grep ttyACM
lrwxrwxrwx 1 root root           7 May 22 01:08 stlinkv2-1_0 -> ttyACM0
crw-rw-rw- 1 root plugdev 166,   0 May 22 01:08 ttyACM0

ターゲットMCUと接続されているので、minicomなどで開けばデバッグ等に便利です

$ minicom -b 115200 -D /dev/ttyACM0

トラブルシューティング(ハマったポイント)

OpenOCD GDBサーバ起動に失敗

状況:
OpenOCD起動時に
Error: libusb_open() failed with LIBUSB_ERROR_ACCESS
等のエラーがでてGDBサーバ起動に失敗

解決法

usbipd-winセットアップ時にしたudev設定の再読み込みをWSLディストリビューション起動毎に実行する必要があるようです。

$ sudo service udev restart
$ sudo udevadm control --reload

この時、既にデバッガがWSLディストリビューション向けに接続されていた場合はdetach->attachが必要です。
参考
https://github.com/dorssel/usbipd-win/discussions/347

ST-LinkのVCPが動かない

状況:

$ minicom -b 115200 -D /dev/ttyACM0

MCUから出力してるはずなのに何も出ない

解決法

usbipd-winでデバッガ接続->attach->detach->attach
等の際に発生するようです
よってデバッガ接続->attach->detach->デバッガ取り外し->デバッガ接続->attach
のように物理的にデバッガの再接続をしたところ問題なく動作しました

以上

DevTerm A06が来たのでやったこと Manjaro + sway編

Manjaro LinuxのDevterm A06向け対応が有志によってされていました。
github.com

フォーラムでManjaro + swayの組み合わせで使っている方が居てカッコよかったので真似してインストールしてみました。

画面回転設定

画面が90°回転していたので設定変更
これを追記
/etc/sway/outputs/default-screen

output DSI-1 transform 90

それぞれ下記で呼び出されるっぽい
/etc/greetd/sway

include /etc/sway/outputs/*

/home/username/.config/sway/config

include /etc/sway/outputs/*

出力デバイス名(今回でいうとこのDSI-1)の確認

$ swaymsg -t get_outputs

SSH設定

/etc/ssh/sshd_configをいい感じにする

$ sudo systemctl enable sshd
$ sudo systemctl start sshd

参考
Sway - ArchWiki

DevTerm A06が来たのでやったこと Armbian編

とどきました
こいつは18650が2本入るバッテリーケースが付いています。動作に必須なのかわからなくて届くまで不安でしたが、バッテリーなし + USB電源オンリーで問題なく動作しました

Armbianイメージ書き込み

OSイメージ書き込み済みのSDが付属してたけど容量が32GBで若干不安だったので128GBのものに変更
あんまり遅いSDだとダメかも(SanDisk SDSQUNS-128G Class10)で確認
自分でビルドする方法もあるみたいだけど結構手間なのでビルド済みのイメージを使った

自力ビルド
https://github.com/clockworkpi/DevTerm/wiki/Create-DevTerm-A06-OS-image-from-scratch
ビルド済みイメージ
https://forum.clockworkpi.com/t/devterm-os-a06-image-files/7178

SDへの書き込みはEtcherでOK
github.com

SSH設定

Applications欄からSettings -> Armbian configを選択する
もしくはターミナルで

$ sudo armbian-config

System -> SSH 好みの設定に変える
/etc/ssh/sshd_config の設定を直接変更でもOKそう

$ sudo systemctl enable ssh
$ sudo systemctl start ssh

画面解像度変更

Applications欄からSettings -> Display
Scaleを1.5くらいで大体のウィンドウが画面に収まるようになった