はい、承知いたしました。VS CodeでSTM32開発を行うための環境構築から使い方までを詳細に解説する記事を作成します。約5000語を目指し、必要な手順、ツール、設定について網羅的に説明します。

---

VS CodeでSTM32開発！環境構築と使い方徹底解説

はじめに：なぜVS CodeでSTM32開発なのか？

組み込み開発、特にSTマイクロエレクトロニクス社の提供するSTM32マイクロコントローラーを用いた開発では、統合開発環境（IDE）としてSTM32CubeIDEが広く使われています。CubeIDEは強力で高機能なツールですが、その一方で、やや動作が重い、特定の機能に特化しすぎている、といった声も聞かれます。

そこで近年注目されているのが、軽量かつカスタマイズ性に優れたテキストエディタ/IDEであるVisual Studio Code (VS Code) を用いた開発環境です。VS Codeは、強力なエディタ機能、豊富な拡張機能エコシステム、統合ターミナルなどを備えており、適切に設定することで、STM32CubeIDEに匹敵、あるいはそれを超える開発体験を提供することができます。

VS Code環境の最大のメリットは、柔軟性とカスタマイズ性です。お気に入りのテーマ、キーバインド、Gitクライアント、リンターなどを自由に組み合わせ、自分にとって最適な開発環境を構築できます。また、STM32開発だけでなく、様々な言語やプラットフォームの開発にも同じツールを使い慣れた環境で行えるため、開発効率の向上にも繋がります。

この記事では、VS Codeを使ってSTM32開発を行うための環境構築方法から、実際のプロジェクトの作成、ビルド、デバッグまでを徹底的に解説します。CubeIDEからVS Code環境へ移行したい方、VS Codeの柔軟性を組み込み開発にも活用したい方にとって、役立つ情報となることを目指します。

この記事で解説すること:

1. VS Code環境でSTM32開発を行うために必要なツール群
2. 各種ツールのインストールと設定方法
3. VS Codeに必要な拡張機能のインストールと設定
4. Makeを用いたビルドシステムの構築
5. tasks.jsonとlaunch.jsonの設定によるビルドとデバッグの連携
6. STM32CubeMXを使ったプロジェクト生成とVS Codeでの利用方法
7. 実際のコード編集、ビルド、デバッグの手順
8. VS Code環境での開発をより快適にするためのヒント

必要なもの (前提条件)

環境構築を始める前に、以下のものを準備してください。

1. STM32開発ボード: NucleoやDiscoveryボード、あるいは自作ボードなど、実際に開発を行うターゲットとなるSTM32ボードが必要です。ST-Linkなどのデバッグプローブがオンボードされているものが、追加のデバッガを用意する必要がなく便利です。
2. デバッグプローブ: STM32ボードとPCを接続し、プログラムの書き込みやデバッグを行うためのプローブです。NucleoやDiscoveryボードにはST-Linkがオンボードされています。別途、J-Linkや市販のST-Link v2/v3などを使用することも可能です。
3. PC: Windows, macOS, Linuxなど、VS Codeが動作するオペレーティングシステムを搭載したPCが必要です。
4. インターネット接続: 必要なツールのダウンロードにインターネット接続が必要です。

ステップ1：必要なツールチェーンのインストール

VS Code自体はエディタであり、コンパイラやデバッガの機能は持っていません。STM32のプログラムをビルド（コンパイル・リンク）し、ターゲットへ書き込み、デバッグを行うためには、別途ツールチェーンをインストールする必要があります。

1.1. ARM GCC Embedded Toolchain

STM32はARM Cortex-Mコアを搭載しているため、ARM Embedded向けのGCCコンパイラが必要です。

• ダウンロード: ARM社のウェブサイトから、GCC Toolchain for ARM Embedded Processors をダウンロードします。
  • https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm
  • ご使用のOS (Windows, macOS, Linux) に合った最新版のインストーラーまたはアーカイブをダウンロードしてください。Windowsの場合はexeインストーラー、macOS/Linuxの場合はtar.bz2アーカイブが一般的です。
• インストール:
  • Windows: ダウンロードしたexeファイルを実行し、インストーラーの指示に従います。インストール先はデフォルトでも構いませんが、パスに日本語や空白が含まれない場所（例: C:\ツール\gcc-arm-none-eabi-XXXX.XX）にインストールすることをお勧めします。インストーラーの最後に「Add path to environment variable」のようなチェックボックスがあれば、必ずチェックを入れてください。これにより、コマンドプロンプトやPowerShellからarm-none-eabi-gccなどのコマンドが直接実行できるようになります。もしチェックボックスがない場合や、後からパスを通したい場合は、手動でシステム環境変数のPathにGCCのbinディレクトリ（例: C:\ツール\gcc-arm-none-eabi-XXXX.XX\bin）を追加してください。
  • macOS/Linux: ダウンロードしたtar.bz2ファイルを展開します。例えば、ホームディレクトリ以下にToolsディレクトリを作成し、そこに展開するのが良いでしょう。
    bash
mkdir ~/Tools
tar -xf gcc-arm-none-eabi-XXXX.XX-YOUR_OS.tar.bz2 -C ~/Tools
    展開後、GCCのbinディレクトリ（例: ~/Tools/gcc-arm-none-eabi-XXXX.XX/bin）へのパスを環境変数PATHに追加します。.bashrc, .zshrc, .profileなどのシェルの設定ファイルに以下の行を追加し、設定ファイルを再読み込み（source ~/.bashrcなど）するか、ターミナルを再起動します。
    bash
export PATH="$PATH:$HOME/Tools/gcc-arm-none-eabi-XXXX.XX/bin"
• 確認: 新しいターミナル（コマンドプロンプト、PowerShell、Bashなど）を開き、以下のコマンドを実行して、コンパイラのバージョン情報が表示されることを確認してください。
  bash
arm-none-eabi-gcc --version
  バージョン情報が表示されれば、インストールとパス設定は成功です。

1.2. ビルドシステム (Make)

プログラムのコンパイル、リンク、書き込みといった一連の作業を自動化するために、ビルドシステムが必要です。組み込み開発ではMakefileを用いたmakeコマンドが広く使われています。

• Windows:
  • Git for Windowsをインストールしている場合、Git Bashに含まれるMakeを使うことができます。https://gitforwindows.org/
  • あるいは、MinGW-w64などの環境をインストールし、そこに含まれるMakeを利用することもできます。https://mingw-w64.org/
  • CMakeを使う場合は別途インストールが必要です。（後述しますが、この記事ではMakefileを主に扱います）
  • MakeコマンドをコマンドプロンプトやPowerShellから使えるように、インストールしたMakeのbinディレクトリにパスを通す必要があります。
• macOS: macOSにはXcode Command Line Toolsに含まれるMakeがプリインストールされています。ターミナルでmake --versionを実行して確認できます。もしインストールされていない場合は、xcode-select --installでインストールできます。

• Linux: ほとんどのLinuxディストリビューションにはMakeがプリインストールされています。make --versionで確認できます。インストールされていない場合は、パッケージマネージャーを使ってインストールしてください（例: sudo apt update && sudo apt install make for Debian/Ubuntu）。

• 確認: ターミナルで以下のコマンドを実行し、Makeのバージョン情報が表示されることを確認してください。
  bash
make --version

1.3. デバッガーインターフェース (OpenOCD or ST-Link GDB Server)

PCとSTM32ボード上のデバッグプローブ（ST-Linkなど）を連携させ、GDB（GNU Debugger）からターゲットを制御するために、デバッガーインターフェースソフトウェアが必要です。代表的なものとしてOpenOCDやST-Link GDB Serverがあります。

• OpenOCD (Open On-Chip Debugger): 多くのデバッグプローブをサポートする汎用的なツールです。ST-Link、J-Link、FTDIなどを通じて様々なチップをデバッグできます。

  • ダウンロード: OpenOCDの公式サイトまたはSourceForgeからダウンロードします。SourceForgeにはWindows用のバイナリも用意されています。https://openocd.org/ / https://sourceforge.net/projects/openocd/files/openocd/
  • インストール:
    • Windows: ダウンロードしたzipファイルを任意のディレクトリ（例: C:\ツール\OpenOCD-XXXX）に展開します。binディレクトリにパスを通すと便利ですが、VS Codeの設定ファイルでパスを直接指定することも可能です。Windowsの場合、ST-Linkドライバーも必要になることがあります。STM32CubeProgrammerをインストールするとドライバーもインストールされます。
    • macOS/Linux: パッケージマネージャーでインストールするのが最も簡単です（例: brew install openocd for macOS, sudo apt update && sudo apt install openocd for Debian/Ubuntu）。ソースコードからビルドすることも可能ですが、初心者には推奨しません。
  • 確認: ターミナルでopenocd --versionを実行してバージョンが表示されるか、またはopenocd -hでヘルプが表示されるか確認します。

• ST-Link GDB Server: STマイクロエレクトロニクスが提供する、ST-Link専用のGDBサーバーです。STM32CubeProgrammerやSTM32CubeIDEに同梱されています。

  • インストール: STM32CubeProgrammerまたはSTM32CubeIDEをインストールすると自動的にインストールされます。
    • STM32CubeProgrammer: https://www.st.com/en/development-tools/stm32cubeprg.html
    • STM32CubeIDE: https://www.st.com/en/development-tools/stm32cubeide.html
  • 確認: インストールディレクトリ内のGDB Server実行ファイル（例: STM32CubeIDE/plugins/com.st.stm32cube.ide.mcu.externaltools.servgdb.XXX/etc/servers/STM32CubeProgrammer/bin/STM32CubeProgrammerLauncher.exe on Windows）を見つけられるか確認します。このパスはVS Codeの設定で必要になります。パスを通すよりは、設定ファイルでフルパス指定する方が一般的です。

• どちらを選ぶか？

  • OpenOCD: ST-Linkだけでなく、J-Linkなど他のプローブも使う可能性がある場合。より多くのカスタマイズオプションがある場合。Linux/macOSでパッケージ管理されていることが多い。
  • ST-Link GDB Server: ST-Linkのみを使う場合。STM32CubeIDE/Programmerを既にインストールしている場合。ST純正ツールなので、特定のST-LinkやSTM32チップで安定している可能性がある。
  • どちらを選んでも、VS Codeのデバッグ設定（launch.json）で指定できます。この記事では主にOpenOCDを中心に解説しますが、ST-Link GDB Serverの設定例も示します。

1.4. STM32CubeMX (推奨)

STM32CubeMXは、STM32マイクロコントローラーの初期設定（クロック、GPIO、周辺機能、ミドルウェアなど）をGUIで設定し、初期化コードとプロジェクトファイル（Makefile含む）を生成するツールです。VS Code環境と組み合わせて使うことで、プロジェクトのセットアップが非常に楽になります。必須ではありませんが、特に初めてのSTM32開発では強く推奨します。

• ダウンロード: STマイクロエレクトロニクスのウェブサイトからダウンロードします。https://www.st.com/en/development-tools/stm32cubemx.html
• インストール: ダウンロードしたインストーラーを実行し、指示に従います。Java Runtime Environment (JRE) が必要なので、もしインストールされていなければ同時にインストールを促されます。
• 使い方 (簡単な紹介):
  1. 新規プロジェクトを作成し、使用するSTM32チップまたは開発ボードを選択します。
  2. ピン配置、クロック設定、ペリフェラル設定などをGUIで行います。
  3. “Project Manager” タブでプロジェクト名、プロジェクトパス、そして Toolchain/IDE として “Makefile” を選択します。
  4. “Generate Code” ボタンをクリックすると、指定したパスにプロジェクトの骨子（初期化コード、Makefile、各種設定ファイル）が生成されます。

STM32CubeMXで生成されたMakefileをベースにすることで、手動でゼロからMakefileを作成する手間を省くことができます。

ステップ2：VS Codeのインストールと初期設定

2.1. VS Code本体のインストール

VS Codeをまだインストールしていない場合は、公式サイトからダウンロードしてインストールします。

• ダウンロード: https://code.visualstudio.com/download
• インストール: ご使用のOSに応じたインストーラーを実行し、指示に従います。

2.2. 必須および推奨拡張機能のインストール

VS CodeをSTM32開発向けに最適化するためには、いくつかの拡張機能が必要です。VS Codeを開き、左側のアクティビティバーにある「Extensions」アイコン（四角形が3つと1つ）をクリックして、以下の拡張機能を検索し、インストールしてください。

1. C/C++ Extension Pack (Microsoft): C/C++開発のための必須拡張機能セットです。 IntelliSense (コード補完、定義へ移動、ホバー情報)、デバッグサポートなどが含まれます。インストール後、おそらくC/C++拡張機能、C/C++ Themesなどがインストールされます。
2. Cortex-Debug: ARM Cortex-M/Rマイクロコントローラー向けのGDBデバッグインターフェースを提供します。VS Codeのデバッグ機能を組み込み開発に対応させます。これが無いと、VS Codeからハードウェアデバッグを行うことができません。
3. STM32CubeMX (Visual Studio Marketplace): STM32CubeMXプロジェクトファイルをVS Code内で開いて設定を確認・変更できる拡張機能です。（必須ではありませんが便利です）
4. File Icons: ファイルの種類に応じたアイコンを表示し、ファイルツリーを見やすくします。
5. GitLens: Gitのリポジトリ情報をコード行ごとに表示するなど、Git連携を強化します。

インストール方法:
VS Codeを開く -> アクティビティバーのExtensionsアイコンをクリック -> 検索バーに拡張機能名を入力 -> 検索結果から見つけて「Install」ボタンをクリック。

ステップ3：プロジェクトの準備 (STM32CubeMXを使用する場合)

VS CodeでSTM32プロジェクトを始める最も簡単な方法は、STM32CubeMXでMakefileプロジェクトを生成し、それをベースに開発を進めることです。

1. STM32CubeMXでプロジェクトを作成:

   • STM32CubeMXを起動します。
   • “New Project” をクリックします。
   • “MCU/Board Selector” で使用するSTM32チップまたはボードを選択します（例: NUCLEO-F446RE）。
   • “Start Project” をクリックします。
   • ペリフェラルの設定、クロック設定などを必要に応じて行います。例えば、LEDを点滅させるだけであれば、LEDが接続されているGPIOピンを”GPIO_Output”に設定し、ラベルを付けておくとコード生成時に分かりやすくなります。System Core > SYSでDebugをSerial Wireに設定することもお忘れなく。
   • “Project Manager” タブを開きます。
   • Project Name: プロジェクト名を入力します。
   • Project Location: プロジェクトファイルを生成するディレクトリを選択します。
   • Toolchain / IDE: ドロップダウンリストから “Makefile” を選択します。
   • Firmware Package: 最新版が選択されていることを確認します。
   • Code Generator:
     • “Copy all used libraries into the project folder” をチェックします。（プロジェクトが自己完結するようになります）
     • “Generate peripheral initialization as a pair of ‘.c/.h’ files per peripheral” をチェックすると、ペリフェラルごとにファイルが分かれて管理しやすくなります。
   • “Generate Code” ボタンをクリックします。

2. 生成されたプロジェクトをVS Codeで開く:

   • STM32CubeMXが指定した場所にプロジェクトフォルダが生成されます。
   • VS Codeを開き、「File」>「Open Folder…」を選択し、生成されたプロジェクトフォルダを選択します。
   • VS CodeのExplorerビューにプロジェクトのファイルツリーが表示されます。Srcディレクトリにメインのソースファイル（main.cなど）、Incディレクトリにヘッダーファイル、DriversディレクトリにSTM32CubeHALドライバ、そしてプロジェクトのルートディレクトリにMakefileが生成されているはずです。

ステップ4：VS Codeの設定ファイル (.vscode ディレクトリ) の作成と編集

VS Codeでプロジェクトのビルドとデバッグを行うためには、プロジェクト固有の設定ファイルを作成する必要があります。これらのファイルはプロジェクトフォルダの.vscodeディレクトリに配置します。

プロジェクトフォルダをVS Codeで開いた状態で、以下のファイルを作成または編集します。

4.1. ビルドタスクの設定 (tasks.json)

tasks.jsonは、VS Code内で実行できるタスク（例: ビルド、クリーン、プログラム書き込み）を定義するファイルです。ここでは、Makeコマンドを呼び出すタスクを設定します。

1. VS Codeでプロジェクトを開いている状態で、「Terminal」>「Configure Tasks…」を選択します。
2. いくつかのオプションが表示されますが、「Create tasks.json file from template」を選択し、「Others」を選びます。
3. デフォルトのtasks.jsonファイルが生成されるので、その内容を削除し、以下の例のように記述します。

json
{
"version": "2.0.0",
"tasks": [
{
"label": "build", // タスク名
"type": "shell", // シェルコマンドとして実行
"command": "make", // 実行するコマンド
"args": [ // コマンド引数
"-j$(nproc)", // 並列ビルド (CPUコア数に応じて高速化)
"all" // Makefileの'all'ターゲットを実行
],
"group": { // タスクのグループ設定
"kind": "build", // ビルドタスクとして識別
"isDefault": true // デフォルトのビルドタスクに設定 (Ctrl+Shift+Bで実行)
},
"presentation": { // タスク実行時の表示設定
"reveal": "always", // 常にターミナルを表示
"panel": "new" // 新しいターミナルパネルを開く
},
"problemMatcher": [ // コンパイルエラーや警告の検出設定
"$gcc" // GCC形式の出力を解析
]
},
{
"label": "clean", // タスク名
"type": "shell",
"command": "make",
"args": [
"clean" // Makefileの'clean'ターゲットを実行
],
"group": "build",
"presentation": {
"reveal": "always",
"panel": "new"
}
},
{
"label": "program", // タスク名 (プログラム書き込み)
"type": "shell",
"command": "make",
"args": [
"program" // Makefileの'program'ターゲットを実行
],
"group": "build",
"presentation": {
"reveal": "always",
"panel": "new"
}
}
]
}

解説:

• このファイルは、build (make all), clean (make clean), program (make program) という3つのタスクを定義しています。
• label：タスクの名前です。VS Codeのコマンドパレット (Ctrl+Shift+P) から「Run Task」を選択したときにこの名前で表示されます。
• type: "shell"：外部コマンドをシェルの子プロセスとして実行します。
• command: "make"：実行するコマンドはmakeです。環境変数PATHにMakeコマンドへのパスが通っている必要があります。
• args: makeコマンドに渡す引数です。
  • -j$(nproc): ビルドを並列実行します。$(nproc)はシステムのCPUコア数を取得します。Linux/macOSで有効です。Windowsの場合は -jX (Xはコア数) のように固定値にするか、Git Bash/MinGW Makeを使用する必要があります。
  • all, clean, program: Makefile内で定義するターゲット名です。
• group: タスクをグループ化します。”build”グループのデフォルトに設定されたタスクは、Ctrl+Shift+Bで簡単に実行できます。
• presentation: タスク実行時のVS Codeのターミナルパネルの挙動を設定します。
• problemMatcher: ["$gcc"]: ターミナル出力中のコンパイルエラーや警告を自動的に検出し、Problemsパネルに表示したり、エディタ内に波線を表示したりするための設定です。GCCの出力形式を解析するように指定しています。

4.2. デバッグ設定 (launch.json)

launch.jsonは、VS Codeのデバッガーをどのように起動するかを定義するファイルです。ここでは、Cortex-Debug拡張機能を使ってGDBとデバッガーインターフェース（OpenOCDまたはST-Link GDB Server）を連携させる設定を行います。

1. VS Codeでプロジェクトを開いている状態で、「Run and Debug」ビュー（アクティビティバーの虫アイコン）を開きます。
2. 「create a launch.json file」リンクをクリックします。
3. いくつかの環境が表示されるので、「Cortex-Debug」を選択します。
4. デフォルトのlaunch.jsonファイルが生成されるので、その内容を削除し、以下の例のように記述します。

例: OpenOCDを使用する場合

json
{
"version": "0.2.0",
"configurations": [
{
"name": "Debug (OpenOCD)", // デバッグ設定の名前
"cwd": "${workspaceRoot}", // デバッグ実行時のカレントディレクトリ
"executable": "${workspaceFolder}/build/${config:target}.elf", // デバッグ対象の実行ファイルパス
"request": "launch", // デバッグリクエストの種類 (起動)
"type": "cortex-debug", // 使用するデバッガーの種類 (Cortex-Debug拡張機能)
"servertype": "openocd", // GDBサーバーとしてOpenOCDを使用
"device": "STM32F446RETx", // 使用するSTM32デバイス名 (SVDファイルパスの指定にも使われる)
"configFiles": [ // OpenOCD設定ファイルへのパス
"interface/stlink.cfg", // デバッガインターフェース設定 (ST-Link)
"target/stm32f4x.cfg" // ターゲットデバイス設定 (STM32F4シリーズ)
],
// "openOCDPath": "/usr/local/bin/openocd", // OpenOCDの実行ファイルパス (PATHが通っていない場合)
"searchDir": [ // OpenOCD設定ファイルの検索ディレクトリ
"${openocd.gdbpath}/../share/openocd/scripts" // OpenOCDインストールディレクトリ内のscriptsフォルダを指定
],
"gdbPath": "arm-none-eabi-gdb", // GDBの実行ファイルパス (PATHが通っている場合)
// "gdbPath": "/path/to/gcc-arm-none-eabi/bin/arm-none-eabi-gdb", // GDBの実行ファイルパス (PATHが通っていない場合)
"svdFile": "${env:CUBEMX_DIR}/STM32Cube_FW_F4_V1.26.2/Drivers/CMSIS/Device/ST/STM32F4xx/SVD/STM32F446x.svd", // デバイスのSVDファイルパス (レジスタ/ペリフェラルビュー用)
"runToEntryPoint": "main", // 起動時にブレークする関数名
"showRegisters": true, // デバッグ時にレジスタビューを表示
"showCommits": true, // Gitコミット情報を表示
"preLaunchTask": "build", // デバッグ開始前に実行するtasks.jsonのタスク (ビルド)
"postRestartCommands": [ // リスタート後に実行するGDBコマンド
"c" // リセット後に実行を継続
],
"postLaunchCommands": [ // 起動後に実行するGDBコマンド
// "monitor reset and halt", // ターゲットをリセットして停止させる場合
// "monitor program ${workspaceFolder}/build/${config:target}.elf verify", // プログラムを書き込む場合
// "monitor resume" // プログラムを実行させる場合
],
"rttConfig": { // Real-Time Transfer (RTT) 設定 (Segger RTT対応デバッガ使用時など)
"enabled": true,
"address": "auto", // RTT Control Blockのアドレスを自動検出
"decoders": [
{
"port": 0, // RTTポート番号
"type": "console" // 出力タイプ (コンソール)
}
]
}
}
]
}

解説:

• name: デバッグ設定の名前です。Run and Debugビューのドロップダウンリストで表示されます。
• cwd: デバッグセッションを開始するカレントディレクトリです。通常はプロジェクトルート${workspaceRoot}または${workspaceFolder}で良いでしょう。
• executable: デバッグ対象の実行ファイルへのパスを指定します。Makefileでビルドする際に生成されるELFファイル（通常は.elf拡張子）を指定します。パスはMakefileの設定に合わせて変更してください。build/${config:target}.elfは、MakefileのTARGET変数とBUILD_DIR変数に対応することが多いです。
• request: デバッグリクエストの種類です。組み込み開発では通常launch（起動してデバッグ）を使用します。
• type: 使用するVS Codeデバッガーアダプターの種類です。Cortex-Debug拡張機能を使用するためcortex-debugを指定します。
• servertype: GDBサーバーの種類を指定します。OpenOCDを使う場合はopenocd、ST-Link GDB Serverを使う場合はstutilを指定します。
• device: デバイス名です。Cortex-DebugやOpenOCDが適切な設定やSVDファイルを見つけるために使用します。正確なデバイス名（例: STM32F446RETx）を指定します。
• configFiles (OpenOCDの場合): OpenOCDを起動する際に読み込ませる設定ファイルへのパスリストです。通常はデバッガインターフェース設定（例: interface/stlink.cfg）とターゲット設定（例: target/stm32f4x.cfgなど、デバイスシリーズに合わせて変更）を指定します。これらのファイルはOpenOCDのscriptsディレクトリにあります。searchDirでそのディレクトリを指定しておくと、ファイル名だけで指定できます。
• openOCDPath (OpenOCDの場合): OpenOCDの実行ファイル（openocd）へのパスです。PATHが通っていれば省略できます。
• searchDir (OpenOCDの場合): OpenOCDがconfigFilesで指定された設定ファイルを探すディレクトリです。OpenOCDのインストールディレクトリ内のscriptsフォルダを指定するのが一般的です。${openocd.gdbpath}のような変数はCortex-Debugが提供するものです。
• gdbPath: GDBの実行ファイル（arm-none-eabi-gdb）へのパスです。PATHが通っていれば省略できます。
• svdFile: デバイスのSystem View Description (SVD) ファイルへのパスです。これを指定すると、デバッグ中にレジスタやペリフェラルの値をVS CodeのUIで確認できるようになります。SVDファイルはSTM32CubeIDEのインストールディレクトリや、STM32Cube Firmwareパッケージに含まれています。パスは環境に合わせて正確に指定してください。環境変数${env:CUBEMX_DIR}は例です。
• runToEntryPoint: デバッグセッション開始後、最初に実行を停止する関数名です。通常はmainを指定します。
• showRegisters: デバッグ中にレジスタビューを表示するかどうか。
• preLaunchTask: デバッグセッションを開始する前に実行するtasks.jsonで定義されたタスクのlabelを指定します。ここで"build"を指定することで、デバッグ開始前に自動的にプロジェクトがビルドされるようになります。
• postRestartCommands: デバッグセッションのリスタート後にGDBに送るコマンドのリストです。"c"はcontinue（実行継続）コマンドです。
• postLaunchCommands: デバッグセッション開始後にGDBに送るコマンドのリストです。コメントアウトしている例のように、プログラムの自動書き込みやリセット、実行などの操作を自動化できます。ただし、preLaunchTaskでmake programを実行する方がMakefileに処理を集約できて管理しやすいことが多いです。
• rttConfig: Segger RTT (Real-Time Transfer) を使用する場合の設定です。デバッガー（J-Linkなど）がRTTに対応している必要があります。ST-Linkは通常RTTを直接サポートしませんが、一部のツールや方法で利用できる場合があります。

例: ST-Link GDB Serverを使用する場合

json
{
"version": "0.2.0",
"configurations": [
{
"name": "Debug (ST-Link GDB Server)",
"cwd": "${workspaceRoot}",
"executable": "${workspaceFolder}/build/${config:target}.elf", // 実行ファイルパス
"request": "launch",
"type": "cortex-debug",
"servertype": "stutil", // GDBサーバーとしてST-Link GDB Serverを使用
"device": "STM32F446RETx", // デバイス名
"gdbPath": "arm-none-eabi-gdb", // GDBパス
"stutilPath": "C:/ST/STM32CubeIDE_XXXX/plugins/com.st.stm32cube.ide.mcu.externaltools.servgdb.XXXX/etc/servers/STM32CubeProgrammer/bin/STM32CubeProgrammerLauncher.exe", // ST-Link GDB Server実行ファイルのフルパス
"stm32cubeprogrammer": "C:/ST/STM32CubeIDE_XXXX/plugins/com.st.stm32cube.ide.mcu.externaltools.cubeprog.XXXX/etc/STM32_Programmer_CLI.exe", // STM32CubeProgrammer CLIのフルパス (Program/Resetコマンド用)
"svdFile": "C:/ST/STM32CubeIDE_XXXX/plugins/com.st.stm32cube.ide.mcu.product_XXXX/cmsis_device/STM32F4xx/Source/CMSIS/Device/ST/STM32F4xx/SVD/STM32F446x.svd", // SVDファイルパス
"runToEntryPoint": "main",
"showRegisters": true,
"showCommits": true,
"preLaunchTask": "build",
"postRestartCommands": [
"c"
],
"postLaunchCommands": [ // プログラム書き込みを自動化する場合
// "monitor flash write_image erase ${workspaceFolder}/build/${config:target}.elf", // STM32CubeProgrammerCLIを使って書き込み
// "monitor reset"
]
}
]
}

解説:

基本的な設定はOpenOCDの場合と同じですが、servertypeがstutilとなり、ST-Link GDB Server固有のパス指定（stutilPath, stm32cubeprogrammer）が必要になります。これらのパスは、ご自身のSTM32CubeIDEまたはSTM32CubeProgrammerのインストールディレクトリに合わせて変更してください。

4.3. C/C++拡張機能の設定 (c_cpp_properties.json)

C/C++拡張機能がコード補完（IntelliSense）やエラー検出を正しく行うためには、プロジェクトのインクルードパス、定義済みマクロ、コンパイラパスなどの情報を設定する必要があります。これは.vscode/c_cpp_properties.jsonファイルで行います。

このファイルは手動で作成することもできますが、最も簡単な方法はVS Codeのコマンドパレットから生成・編集することです。

1. VS Codeでプロジェクトを開いている状態で、CまたはC++ファイルを開きます（例: main.c）。
2. コマンドパレット (Ctrl+Shift+P) を開き、「C/C++: Edit Configurations (UI)」または「C/C++: Edit Configurations (JSON)」を選択します。JSONを選択した場合は.vscode/c_cpp_properties.jsonファイルが開かれます。UIを選択した場合は設定画面が開きます。
3. JSONモードで開いた場合は、以下の例のように記述します。UIモードの場合は、対応する項目に入力します。

json
{
"configurations": [
{
"name": "STM32", // 設定の名前
"includePath": [ // インクルードファイルを探すディレクトリのリスト
"${workspaceFolder}/**", // プロジェクト内の全てのサブディレクトリ
// STM32Cube HALドライバ、CMSISなどのパス
"${workspaceFolder}/Drivers/STM32F4xx_HAL_Driver/Inc",
"${workspaceFolder}/Drivers/STM32F4xx_HAL_Driver/Inc/Legacy",
"${workspaceFolder}/Drivers/CMSIS/Device/ST/STM32F4xx/Include",
"${workspaceFolder}/Drivers/CMSIS/Include",
// CubeMXで設定したミドルウェアなどのIncludeパスも必要に応じて追加
// 例: FreeRTOS
// "${workspaceFolder}/Middlewares/Third_Party/FreeRTOS/Source/include",
// "${workspaceFolder}/Middlewares/Third_Party/FreeRTOS/Source/CMSIS_RTOS",
// "${workspaceFolder}/Middlewares/Third_Party/FreeRTOS/Source/portable/GCC/ARM_CM4F", // 使用するポートに合わせて変更
// 必要に応じて、STM32Cube Firmwareパッケージ全体のパスも追加
// "${env:CUBEMX_DIR}/STM32Cube_FW_F4_V1.26.2/Drivers/..."
],
"defines": [ // プリプロセッサ定義マクロのリスト (Makefileの-Dオプションと合わせる)
"USE_HAL_DRIVER",
"STM32F446xx", // 使用するチップに合わせて変更
// 必要に応じて、Makefileで定義している他のマクロを追加
// 例: HSE_VALUE, HSI_VALUE, USBCONFIG_NO_FS_SWAP, VECT_TAB_FLASH など
],
"compilerPath": "arm-none-eabi-gcc", // 使用するコンパイラのパス (PATHが通っていればファイル名のみ)
// "compilerPath": "/path/to/gcc-arm-none-eabi/bin/arm-none-eabi-gcc", // PATHが通っていない場合
"cStandard": "c11", // 使用するC標準
"cppStandard": "c++11", // 使用するC++標準 (C++を使う場合)
"intelliSenseMode": "gcc-arm", // IntelliSenseエンジンモード
"configurationProvider": "ms-vscode.makefile-tools" // Optional: Makefile Tools拡張機能を使う場合
}
],
"version": 4
}

解説:

• name: この設定構成の名前です。
• includePath: IntelliSenseがヘッダーファイルを探すディレクトリのパスリストです。プロジェクト内のソースディレクトリ、STM32Cube HALドライバのIncディレクトリ、CMSISのIncludeディレクトリ、使用するミドルウェアなどのヘッダーディレクトリを正確に指定する必要があります。STM32CubeMXで生成されたMakefileのC_INCLUDES変数などを参考に設定してください。${workspaceFolder}はプロジェクトルートディレクトリを指すVS Code変数です。
• defines: プリプロセッサで定義されているマクロのリストです。これは、コンパイル時に-Dオプションで渡されるマクロと一致させる必要があります。チップ固有のマクロ（例: STM32F446xx）や、HALドライバで使用されるマクロ（例: USE_HAL_DRIVER）、システムクロックの値（例: HSE_VALUE=8000000）などを指定します。MakefileのC_DEFS変数などを参考に設定してください。
• compilerPath: コンパイラの実行ファイルへのパスです。PATHが通っていればarm-none-eabi-gccと記述できます。
• cStandard, cppStandard: 使用するC/C++言語の標準規格を指定します。
• intelliSenseMode: IntelliSenseエンジンのモードを指定します。ARM GCC Toolchainを使用する場合はgcc-armが推奨されます。
• configurationProvider: （オプション）Makefile Tools拡張機能などを使用している場合に指定します。Makefileから設定を自動取得できる場合がありますが、手動設定の方が確実なことが多いです。

重要な注意点:
includePathとdefinesの設定は、Makefileの内容と一致している必要があります。Makefileのコンパイルオプション（-Iで指定されるインクルードパス、-Dで指定されるマクロ）をよく確認し、正確にc_cpp_properties.jsonに反映させてください。設定が間違っていると、VS Codeのエディタ上で大量のエラーが表示されたり、コード補完が正しく機能しなかったりします。

ステップ5：Makefileの確認と編集

STM32CubeMXで生成されたMakefileは、そのままVS Code環境で使用できますが、必要に応じて編集が必要になる場合があります。特に、デバッグターゲットのパスや、プログラム書き込みのターゲットを追加・修正することがあります。

生成されたMakefileファイルを開き、以下の点を確認または編集します。

1. Toolchainパス: TOOLCHAIN変数などでGCCコンパイラのパスが正しく設定されているか確認します。多くのMakefileでは単にarm-none-eabi-と指定されており、環境変数PATHに依存しています。パスが通っていれば問題ありません。
2. ビルドディレクトリとターゲット名: BUILD_DIRやTARGET変数が、VS Codeのlaunch.jsonで指定した実行ファイルパス（executable）と一致しているか確認します。通常、executableは${workspaceFolder}/${BUILD_DIR}/${TARGET}.elfの形式になります。
3. ソースファイルとインクルードパス: C_SOURCES, ASM_SOURCES, C_INCLUDESなどの変数が、プロジェクトに含まれる全てのソースファイルやヘッダーディレクトリを正しく網羅しているか確認します。新しいファイルを追加したり、ミドルウェアを有効にしたりした場合、これらの変数を手動で更新する必要があることがあります（CubeMXで再生成すれば自動的に更新されます）。
4. 定義済みマクロ: C_DEFSなどの変数が、必要なマクロ（チップ名、HAL使用、クロック値など）を定義しているか確認します。これはc_cpp_properties.jsonのdefinesと一致させる必要があります。
5. リンカースクリプト: LD_SCRIPT変数でリンカースクリプトファイル（.ld拡張子）が正しく指定されているか確認します。これはメモリマップやセクション配置を定義する重要なファイルです。
6. 書き込みターゲット (program) の追加/編集: STM32CubeMXで生成されるMakefileには、デフォルトでprogramターゲットが含まれていないことがあります。tasks.jsonでmake programを実行するためには、このターゲットが必要です。以下の例のように、OpenOCDまたはSTM32CubeProgrammer CLIを使ってプログラムを書き込むターゲットを追加します。

Makefileにprogramターゲットを追加する例 (OpenOCD使用):

“`makefile

… (他のMakefileの内容) …

プログラム書き込みターゲット

program: $(BUILD_DIR)/$(TARGET).elf
@echo “Flashing $(TARGET).elf”
@$(OPENOCD) -f $(OPENOCDCFG) -c “program $< verify reset exit”

OpenOCD関連の変数 (Makefileの先頭などで定義)

OPENOCD = openocd # PATHが通っていればファイル名のみ
OPENOCDCFG = interface/stlink.cfg -f target/stm32f4x.cfg # 使用するインターフェースとターゲットの設定ファイルに合わせて変更

OPENOCD = /path/to/openocd/bin/openocd # PATHが通っていない場合

“`

Makefileにprogramターゲットを追加する例 (STM32CubeProgrammer CLI使用):

“`makefile

… (他のMakefileの内容) …

プログラム書き込みターゲット

program: $(BUILD_DIR)/$(TARGET).elf
@echo “Flashing $(TARGET).elf”
@$(CUBEPROGRAMMER) connect port=SWD –download $< –verify –reset

CubeProgrammer関連の変数 (Makefileの先頭などで定義)

CUBEPROGRAMMER = STM32_Programmer_CLI # PATHが通っていればファイル名のみ

CUBEPROGRAMMER = /path/to/STM32CubeProgrammer_CLI.exe # PATHが通っていない場合

“`

• < は依存関係リストの最初の項目（ここではビルドされたELFファイル）を指す自動変数です。
• @echo はコマンド自体を表示せずにメッセージのみを表示します。
• OpenOCDコマンドの -c "..." オプションで、起動後に実行するTclコマンドを指定します。program <file> verify reset exit は、指定したファイルをフラッシュに書き込み、ベリファイ（検証）し、ターゲットをリセットして、OpenOCDを終了するという一連の操作を行います。
• STM32CubeProgrammer CLIコマンドの connect, port, --download, --verify, --reset オプションで同様の操作を行います。

必要に応じて、Makefileにdebugターゲットを追加し、OpenOCDやST-Link GDB Serverを起動するコマンドを記述することもできますが、通常はlaunch.jsonでGDBサーバーの起動はCortex-Debug拡張機能に任せるため、Makefile側には書き込み用のprogramターゲットがあれば十分です。

ステップ6：ビルドとプログラム書き込み

これでVS Code環境の基本的な設定が完了しました。実際にプロジェクトをビルドし、ターゲットボードに書き込んでみましょう。

1. ビルド:

   • VS Codeの「Terminal」メニューから「Run Build Task…」を選択します。
   • tasks.jsonで定義したビルドタスク（build）が実行されます。tasks.jsonで"isDefault": trueを設定している場合は、Ctrl+Shift+Bを押すだけでもビルドが開始されます。
   • VS Code下部のターミナルパネルにビルドの進行状況と結果が表示されます。エラーや警告があればここに表示されます。
   • ビルドが成功すると、Makefileで指定したビルドディレクトリ（通常はbuildやDebug）に、.elf, .hex, .binなどのファイルが生成されます。.elfファイルがデバッグ情報を含む実行ファイルです。

2. プログラム書き込み (フラッシュ):

   • STM32ボードをPCに接続します。必要であれば、ドライバが正しくインストールされているか確認してください。
   • VS Codeの「Terminal」メニューから「Run Task…」を選択します。
   • tasks.jsonで定義したprogramタスクを選択します。
   • Makefileのprogramターゲットが実行され、ビルドされた.elfファイルがターゲットボードのフラッシュメモリに書き込まれます。ターミナルに出力されるメッセージで書き込みが成功したか確認してください。
   • 書き込み後、ボードがリセットされ、新しいプログラムが実行されるはずです。例えば、LED点滅プログラムであれば、LEDが点滅を開始します。

トラブルシューティング（ビルド/書き込み）:

• command 'make' not found: Makeコマンドへのパスがシステム環境変数PATHに通っていません。手順1.2を確認してください。
• arm-none-eabi-gcc: command not found: GCC ToolchainのbinディレクトリへのパスがPATHに通っていません。手順1.1を確認してください。
• Compile errors: コードに文法エラーや論理エラーがあります。Problemsパネルやターミナルの出力を見て修正してください。c_cpp_properties.jsonのインクルードパスや定義済みマクロが間違っている場合もエラーが多く出ます。
• Linker errors: リンカースクリプトのパスが間違っている、必要なソースファイルがMakefileに追加されていない、ライブラリがリンクされていない、などの問題が考えられます。リンカーの出力メッセージを詳しく確認してください。
• Flashing failed: ターゲットボードがPCに正しく接続されていない、デバッガードライバの問題、Makefileのprogramターゲットのコマンドが間違っている、OpenOCD/CubeProgrammerのパスや設定ファイルが間違っているなどが考えられます。ターミナル出力のエラーメッセージを確認してください。OpenOCDを使う場合は、別途ターミナルで手動でOpenOCDを起動してみて、エラーが出ないか確認すると原因特定に役立ちます。

ステップ7：デバッグ

VS Codeの強力なデバッグ機能を使って、実行中のプログラムの挙動を確認してみましょう。

1. デバッグの開始:

   • launch.jsonでデバッグ設定（例: “Debug (OpenOCD)”) が正しく選択されていることを確認します。（Run and Debugビューのドロップダウンリストで選択できます）
   • アクティビティバーの「Run and Debug」アイコンをクリックし、緑色の三角形の「Start Debugging」ボタンをクリックします。
   • launch.jsonで"preLaunchTask": "build"を設定している場合、デバッグ開始前に自動的にビルドが実行されます。
   • ビルドが成功すると、Cortex-Debug拡張機能がGDBと指定したGDBサーバー（OpenOCDなど）を起動し、ターゲットボードに接続します。
   • デバッグセッションが開始されると、VS Codeのウィンドウ上部がオレンジ色（デフォルトテーマの場合）になり、デバッグコントロールバーが表示されます。
   • launch.jsonで"runToEntryPoint": "main"を設定している場合、プログラムはmain関数の開始位置で停止します。

2. ブレークポイントの設定と操作:

   • コードエディタで、プログラムを一時停止させたい行の左端（行番号の隣）をクリックすると、赤い丸のブレークポイントが設定されます。
   • デバッグセッション実行中にブレークポイントに到達すると、プログラムの実行が一時停止します。
   • デバッグコントロールバーを使って、プログラムの実行を制御できます：
     • Continue (F5): 次のブレークポイントまで実行を継続します。
     • Step Over (F10): 現在の行を実行し、次の行に進みます（関数呼び出しの中には入らない）。
     • Step Into (F11): 現在の行を実行し、関数呼び出しがある場合はその関数の中に入ります。
     • Step Out (Shift+F11): 現在の関数から抜け出し、呼び出し元の次の行で停止します。
     • Restart (Ctrl+Shift+F5): デバッグセッションを最初からやり直します（ターゲットリセット）。
     • Stop (Shift+F5): デバッグセッションを終了します。

3. 変数の確認とウォッチ:

   • デバッグセッションが一時停止している間、左側の「Run and Debug」ビューに「Variables」パネルが表示されます。ここでは、現在のスコープ内のローカル変数やグローバル変数の値を確認できます。
   • 「Watch」パネルでは、監視したい変数を追加できます。変数の名前を入力するか、エディタで変数を選択して右クリックし「Add to Watch」を選びます。複雑な構造体や配列の中身も展開して確認できます。
   • 変数や式を右クリックして「Copy Value」「Copy as Expression」「Set Value」なども利用できます。

4. コールスタック、レジスタ、メモリ、ペリフェラル:

   • Call Stack: 現在実行中の関数の呼び出し履歴が表示されます。どの関数から現在の関数が呼ばれたかを確認できます。
   • Registers: CPUのレジスタの値が表示されます。
   • Memory: 指定したメモリ領域の値をダンプ表示できます。アドレスを入力してメモリの内容を監視できます。
   • Peripherals: launch.jsonでSVDファイルを指定している場合、ターゲットデバイスのペリフェラル（GPIO, タイマー, SPIなど）のレジスタマップがツリー形式で表示され、現在のレジスタ値を確認・変更できます。これは組み込み開発において非常に強力な機能です。

トラブルシューティング（デバッグ）:

• Debugger connection failed: PCとターゲットボードが正しく接続されていない、デバッガードライバの問題、launch.jsonの設定（servertype, configFiles, device, openOCDPath/stutilPathなど）が間違っている、OpenOCD/GDB Serverが正しく起動しない、などが考えられます。Run and Debugビューの下部にある「Debug Console」タブに表示されるメッセージや、GDBサーバー（OpenOCDなど）が起動しているターミナル（またはログファイル）を確認してください。
• Program doesn’t stop at breakpoints:
  • ビルドされたELFファイルにデバッグ情報が含まれていない可能性があります。MakefileでCFLAGSに-gオプションが含まれているか確認してください。最適化レベルが高すぎるとデバッグ情報が失われることがあります（-O0や-Ogがデバッグに適しています）。
  • 設定したブレークポイントの行が、コンパイラによって生成された実行コードに対応していない（例えば、最適化によってコードが削除・移動された）可能性があります。
  • launch.jsonのexecutableパスが、実際に書き込んだプログラムと一致しているか確認してください。
  • ターゲットボードがハングアップしている可能性もあります。
• Peripherals view is empty or incorrect: launch.jsonのsvdFileパスが間違っているか、指定されたSVDファイルがデバイスと一致していません。
• Stepping works strangely: コンパイラの最適化レベルが高い場合に起こりやすいです。デバッグ中は最適化レベルを下げる（-O0または-Og）ことを推奨します。

ステップ8：より快適な開発のために

VS Code環境でのSTM32開発をさらに効率化するためのヒントをいくつか紹介します。

• C/C++ IntelliSenseの精度向上: c_cpp_properties.jsonのincludePathとdefinesの設定は非常に重要です。Makefileで定義されている全てのパスとマクロを正確に反映させるように努めてください。STM32CubeMXでプロジェクト設定を変更した場合は、Makefileと合わせてc_cpp_properties.jsonも更新する必要があります。
• Formatterの利用: コードフォーマッター（例: clang-format）を利用すると、コードスタイルを統一し可読性を高めることができます。VS CodeのC/C++拡張機能はclang-formatをサポートしています。.clang-formatファイルを作成し、設定を定義することで、保存時に自動的にフォーマットをかけるように設定できます。
• Version Control (Git): VS CodeはGitとの連携が強力です。プロジェクトをGitリポジトリで管理し、変更履歴の追跡、ブランチング、リモートリポジトリとの同期などを活用しましょう。.gitignoreファイルを作成し、ビルド生成物（buildディレクトリなど）やツール設定ファイル（.vscodeなど、共有しない場合）を無視するように設定します。
• Static Analysis: 静的解析ツール（例: cppcheck, clang-tidy）を導入することで、コンパイル前に潜在的なバグやコードスタイルの問題を検出できます。これらのツールをVS Codeのタスクとして実行したり、関連する拡張機能を探したりすることで、開発ワークフローに組み込むことができます。
• タスクランナーの活用: tasks.jsonにはビルド、クリーン、プログラム書き込みだけでなく、Lint実行、ドキュメント生成など、様々なタスクを追加できます。よく使うタスクはキーバインドを割り当てると便利です。
• ターミナルの使い分け: VS Codeの統合ターミナルは複数開くことができます。一つをビルド出力用、一つをGDBサーバー用（デバッグ時）、一つを他のコマンド実行用、といった使い分けができます。
• STM32CubeIDEとの連携: STM32CubeIDEは便利なGUI設定ツールや、特定のチップ・機能に特化したコード生成など、依然として強力な側面があります。VS Code環境で開発しつつ、CubeIDEを初期設定や特殊機能のコード生成のために使い分けるという運用も可能です。CubeIDEでプロジェクト設定を変更したら、Makefileとソースコードを生成し直し、VS Code環境のMakefileや.vscode設定を適宜更新します。

まとめ

この記事では、VS Codeと外部ツールチェーン（ARM GCC, Make, OpenOCD/ST-Link GDB Server）を組み合わせて、STM32開発環境を構築する手順を詳細に解説しました。STM32CubeMXでMakefileプロジェクトを生成し、VS Codeの.vscodeディレクトリにtasks.json、launch.json、c_cpp_properties.jsonといった設定ファイルを作成・編集することで、ビルド、プログラム書き込み、そして強力なハードウェアデバッグが可能になることを示しました。

VS Code環境は、初期設定にやや手間がかかるかもしれませんが、一度構築してしまえば、軽量で高速なエディタ、豊富な拡張機能、そして自由度の高いビルド・デバッグ設定により、非常に快適な開発体験を提供します。自分好みの環境を構築し、STM32開発をさらに楽しんでください。

この記事で解説した設定は、一般的なケースに基づいています。使用するSTM32チップ、開発ボード、デバッグプローブ、OS、ツールのインストールパスなどによって、細部の設定は異なる場合があります。もしうまくいかない場合は、エラーメッセージをよく確認し、各ツールのドキュメントやオンラインコミュニティの情報を参考に、設定を調整してみてください。

VS CodeでのSTM32開発は、自由とカスタマイズ性の世界への扉を開きます。このガイドが、あなたの組み込み開発の旅の一助となれば幸いです。

---