devcontainerによるCortexデバッグ環境構築（①gdb-serverのみホスト）

はじめに

仕事で色々な開発環境を触る必要があると，ホストのWindows環境に色々ソフトを入れたくない... という気持ちが強くなってきます。

• プロファイルフォルダとか独自フォルダにBSPのソースコードが大量にダウンロードされてしまう
• IDEのバージョンが変わるたびにダウンロード・インストールをすることが面倒

vscode をエディタとして使うと一部ましですが，面倒なことが残ります

• ツールチェインへのパスを設定しないとコンパイル・デバッグができない
• ツールチェインのバージョンが上がるとパス設定を変えないといけないが，古い設定を消していいか迷う...

仕事で開発環境が必要なのは数ヶ月だけですが毎年必要になるので，記憶もあやふやです。

この記事は， vscode + devcontainer 環境を windows 上に作り，devcontainer を消せばホスト環境には影響がない... という環境を作るための記録です。
想定しているデバイスはSTM32F405RGT6ですが，他のデバイスでも同じ流れで環境構築ができるはずです。

なお，記事の中では devcontainer にソフトウェアをインストールしていますが，これは本来devcontainer側で吸収（カスタムイメージをつくるなど）する事柄です。

方針

Cortexのデバッグは，gdb が gdb-server に接続して行われることが多いと思います。
gdbがELFやデバッグシンボルの読みこみを行い，gdb-serverがハードウェアの制御を行います。この2つは，TCP/IPで通信します。

この記事では，以下の構成でデバッグ環境を作ります：

1. gdbは，Arm GNU Toolchainを使い，devcontainer に配置する
2. gdb-serverは，OpenOCDを使い，ホストに配置する

マイコンごとにgdb-serverを変えれば，他のマイコンでも同じことができるはずです。

• STが提供しているST-Link用のgdb-server
• Renesasが提供しているE2 Lite用のgdb-server（ArmじゃないRXでもデバッグできるかも）
• Segger J-Link用のgdb-server

環境作成

devcontainer 設定

本来はちゃんとイメージを作りますが，スクリプトで環境を作ることにして素のdebianを元にします。

.devcontainer/devcontainer.json

{
    "name": "Cortex Development",
    "image": "mcr.microsoft.com/devcontainers/base:bookworm",
    "features": {
    }
}

Arm GNU Toolchainをインストールします。これで，Cortex用のgdbとして arm-none-eabi-gdb が使えるようになります。
合わせて，ビルドツールとしてcmake / ninja を入れます。eclipseベースのIDEはcmakeベースのプロジェクトを生成できるので，これでビルドしてデバッグできるツールチェインがそろいます。

wget https://developer.arm.com/-/media/Files/downloads/gnu/14.3.rel1/binrel/arm-gnu-toolchain-14.3.rel1-x86_64-arm-none-eabi.tar.xz
tar xvJf arm-gnu-toolchain-14.3.rel1-x86_64-arm-none-eabi.tar.xz -C /tmp
sudo cp -r /tmp/arm-gnu-toolchain-14.3.rel1-x86_64-arm-none-eabi/* /usr/local
rm -rf /tmp/arm-gnu-toolchain-14.3.rel1-x86_64-arm-none-eabi
sudo apt install -y cmake ninja-build

vscode 拡張として，Cortex-Debug を入れます。
その後，Cortex-Debug が gdbとしてarm-none-eabi-gdb を使うように設定します。

.vscode/settings.json

{
    "cortex-debug.gdbPath": "arm-none-eabi-gdb", 
}

Cortex-Debugが，外部のgdb-server に接続するように設定します。

• servertype を external にすることで，外部 gdb-server に接続するようになります
• gdbTarget を接続先のgdb-serverにします。 host.docker.internal はWSLホスト（= Windows PC），3333はOpenOCDの既定の待ち受けポートです
• executable はビルド成果物を指定します

.vscode/launch.json

{
    "version": "0.2.0",
    "configurations": [
        {
            "type": "cortex-debug",
            "servertype": "external",
            "gdbTarget": "host.docker.internal:3333",
            "request": "launch",
            "name": "Debug (OpenOCD)",
            "runToEntryPoint": "main",
            "executable": "./build/stm32f4-c.elf",
            "cwd": "${workspaceRoot}",
        }
    ]
}

ホスト設定

OpenOCDからWindowsバイナリをダウンロードし，任意のディレクトリに展開します。

デバッグ

ホストでの準備

gdb-serverとしてOpenOCDを起動します。

openocd -f interface/stlink.cfg -f target/stm32f4x.cfg

vscode

devcontainer に入り，デバッガを開始します。
上手くいけば，main関数の最初で停止するはずです。また，ホスト側OpenOCDに接続されたことが表示されるはずです。