STM32 で ST-LINK が
突然繋がらなくなった時の
救出ガイド

はじめに：誰もが一度は遭遇するエラー

STM32 で組込み開発をしていると、ある日突然 STM32CubeProgrammer や STM32CubeIDE から以下のようなエラーが出て書き込めなくなることがあります。

Error: No STM32 target found!
Error: Target was not detected
Error: Connection cannot be established
Unable to connect to ST-LINK
The interface firmware FAILED to reset/halt the target MCU

原因はおおまかに 6 系統 に分けられ、それぞれ救出手順がまったく違います。本記事では ST 公式の AN4989「STM32 Microcontroller Debug Toolbox」と UM2237「STM32CubeProgrammer software description」 を一次資料に、原因別の救出フローと、最後の砦となる 14 ステップのチェックリストを体系化します。

SWD / SWO ピンの正式割当を再確認

STM32（Cortex-M3 / M4 / M33 系）はリセット直後、以下のピンを SWJ-DP（Serial Wire / JTAG Debug Port）専用として確保しています。これは F1 / F4 / L4 / G4 / G0 / U5 など主要ファミリ共通です。^{(出典: ST Community「Reset state for JTAG pins」)}

つまり PA13 / PA14 / PB3 / PA15 / PB4 の 5 本は、外部回路で何もしなくても初期状態で「JTAG / SWD」用に確保されている という設計です。CubeMX 上で「Debug = Serial Wire」を選んでいる場合は PA13 / PA14 / PB3 のみが SWJ-DP 用、PA15 / PB4 は通常 GPIO として解放されます。

STM32G0 / G4 系の例外：BOOT0 ピンが PA14（SWCLK と物理同一ピン）と共有されている品種があり、Option Byte の nBOOT_SEL ビットでどちらの機能を優先するかが決まります。詳細は 原因 A で扱います。

原因別 救出マトリクス（早見表）

症状からおおよその原因と救出手順を絞り込む早見表です。複数該当することも多いので、上から順に試すのが定石です。

原因 A：SWD ピンを GPIO に再定義してしまった

最も頻発するパターンです。「GPIO がもう一つ欲しい」と PA13 / PA14 を出力に再割り当てしてビルド・書き込みした瞬間、次回からデバッガが応答しなくなります。ユーザコードの MX_GPIO_Init() で GPIOA->MODER が書き換えられた瞬間に SWJ-DP が物理切断されるためです。

Method A：Connect Under Reset（最も成功率が高い）

STM32CubeProgrammer に最重要のオプション "Under Reset" モードがあります。NRST を Low に保持しながら接続することで、ユーザコードが PA13 / PA14 を奪う 前にデバッガが Halt させます。

1. STM32CubeProgrammer を起動し、右上の接続パネルで "Mode" → "Under Reset" を選択
2. "Reset Mode" → "Hardware reset" に設定
3. 必要に応じ "Frequency" を 4 MHz → 1.8 MHz → 950 kHz へ段階的に下げる
4. ターゲット側で物理 RESET ボタンを押し続ける
5. "Connect" をクリック
6. "Connected" 表示が出たら RESET ボタンを離す
7. すぐに "Erase & Programming" タブ → "Full Chip Erase" を実行

CLI でも同じ操作ができます。

# Under Reset モードで接続テスト
STM32_Programmer_CLI -c port=SWD mode=UR

# 周波数を 1.8 MHz に下げて全消去
STM32_Programmer_CLI -c port=SWD mode=UR freq=1800 -e all

Method B：BOOT0 ピンで System Memory Bootloader を起動

Method A が効かない場合の本命です。BOOT0 = High で起動すると、STM32 は内蔵 ROM のシステムブートローダから起動し、ユーザコードは実行されません。SWD ピン GPIO 化問題を物理的にバイパスできます。

1. ターゲット電源 OFF
2. BOOT0 ピンを VDD（3.3V）にプルアップ。Nucleo 等の評価ボードでは BOOT0 タクトスイッチ / ジャンパで選択
3. 電源 ON（または NRST トグル）
4. システムブートローダが起動。USB DFU / UART / I2C / SPI / CAN のいずれかでホストと通信可能
5. STM32CubeProgrammer で対応する port を選択して接続（USB-DFU が手軽）
6. Full Chip Erase を実行 → SWD ピン GPIO 化のユーザコードが消える
7. BOOT0 を GND に戻し、電源 OFF / ON で通常起動。SWD で再接続可能になる

対応するブートローダ種別と各品種の詳細は AN2606「STM32 microcontroller system memory boot mode」に網羅されています。

Method C：偽物 / クローン ST-LINK の罠

Amazon / AliExpress 等で売られている互換 ST-LINK の中には、NRST 線が物理的に結線されていない個体が存在します。この場合 Connect Under Reset を選んでも NRST が駆動されないため、Method A が永久に効きません。

• 正規 ST-LINK V2 / V2-1 / V3 に交換するのが最も確実
• クローン品を改造して RESET 線を引き出す事例もある（自己責任）
• または別ベンダの J-Link / Black Magic Probe で接続

原因 B：Stop / Standby モードで切断される

低消費電力アプリでよくあるトラブルです。起動直後に Stop / Standby モードに入るコードを書き込むと、デバッガが Halt する前にチップが止まり、SWJ-DP に応答しなくなります。

DBGMCU レジスタで「デバッグ中だけ Stop/Standby を維持」

STM32 の DBGMCU（Debug MCU configuration） レジスタには、低消費電力モード中もクロックと電源を維持してデバッグを継続させるためのビットがあります。^{(出典: RM0351 / RM0440 §47 DBG)}

HAL API も用意されています。main() 冒頭に追加するだけで、デバッグ中は Stop / Standby から抜け出せるようになります。

/* デバッグ中のみ Stop / Standby でクロック維持 */
#ifdef DEBUG
    HAL_DBGMCU_EnableDBGSleepMode();
    HAL_DBGMCU_EnableDBGStopMode();
    HAL_DBGMCU_EnableDBGStandbyMode();
#endif

すでに切断されたチップは Connect Under Reset で救う

「起動直後 Stop に入る」コードを書き込んでしまったあとは、原因 A の Method A（Connect Under Reset）と同じ手順でしか救えません。低消費電力設計の詳細は STM32 低消費電力モード完全ガイド をご覧ください。

原因 C：CubeMX で "Serial Wire" を設定し忘れた

新規プロジェクト作成時に SYS → Debug = "No Debug" を選んだ状態で Code Generate → 書き込んでしまうケースです。生成された MX_GPIO_Init() 内で PA13 / PA14 が GPIO 入力（または Analog）として初期化されるため、書き込み直後に SWJ-DP が物理切断されます。

救出

原因 A と完全に同じです。Connect Under Reset → Mass Erase で救出後、CubeMX の SYS タブで Debug = "Serial Wire" に変更して再生成・再書き込みしてください。

予防策（開発中だけ）

開発中の予防策として、main() 冒頭に短い遅延を入れておくと、デバッガが割り込める窓ができます。

int main(void)
{
    HAL_Init();
    SystemClock_Config();

#ifdef DEBUG
    HAL_Delay(2000);  /* デバッガ救出用の窓（リリース時は #ifdef で外す） */
#endif

    /* ... 通常初期化と Stop モード突入など ... */
}

原因 D：ST-LINK ハードウェア / ファームウェア

ST-LINK 世代別の機能差

ファームウェアが古いと新しい品種を認識しない

STM32 の新しい品種（例：STM32U5、STM32N6 等）は、ST-LINK ファームウェアが古いと "Unknown target" 扱いされます。STSW-LINK007 または STM32CubeProgrammer 内蔵の "Firmware upgrade" で最新版に更新してください。リリースノートは RN0093 に集約されています。

VAPP / VTREF：ターゲット電源検出

ST-LINK の VAPP ピン（旧 VTREF）はターゲット VCC を検出してロジックレベルを合わせるためのものです。VAPP 配線忘れ・ターゲット電源 OFF の状態だと、ST-LINK は「ターゲット電源無し」と判定して接続を拒否します。

• ターゲット VDD（1.65V～3.6V）を VAPP に必ず接続
• 20pin コネクタなら 1 番ピンが VAPP
• 5V トレラント入力なので 3.3V / 1.8V どちらでも可

VCP（Virtual COM Port）が認識されない

Nucleo の場合 CN3 ジャンパで ST-LINK ⇔ ターゲット UART の経路をオン / オフします。VCP が見えない時はジャンパ位置を確認。Windows 8 以降は ST-LINK V2-1 / V3 のドライバは OS 標準ですが、認識されない場合は手動更新かファーム更新が必要です。

USB ケーブル品質

意外と見落とされがちですが、データ線が省かれた「充電専用」USB ケーブルでは「電源は来るが SWD は通らない」状態になります。短い高品質ケーブルへ交換してください。

原因 E：Read Out Protection (RDP) で締め出された

RDP は Flash の不正読み出しを防ぐセキュリティ機能ですが、誤設定するとデバッグもできなくなります。Option Bytes の FLASH_OPTR.RDP バイトで制御されます。

RDP Level 1 からの解除手順

Level 1 は救えます。Mass Erase は強制されますが、デバッグ可能な状態に戻せます。

# 現在の Option Bytes を表示
STM32_Programmer_CLI -c port=SWD -ob displ

# RDP を 0xAA（Level 0）に書き戻す → 自動 Mass Erase
STM32_Programmer_CLI -c port=SWD -ob RDP=0xAA

# 完了まで 5〜10 秒。完了後 SWD で通常接続可能

TrustZone 系（U5 / L5 / H5 / WBA）の追加注意

TrustZone を有効化（TZEN = 1）した状態で RDP = 1 にすると、Non-secure コード実行中にしかデバッガ attach できない制約が加わります。TZEN を 0 に戻すには RDP1 → RDP0 regression（= Mass Erase）が必須です。STM32 H5 / H7RS などでは Debug Authentication (DA) で password 認証付きの regression が可能になっており、AN6008 に手順がまとめられています。

原因 F：電源・配線・NRST まわり

NRST のプルアップとフィルタ

• STM32 の NRST は 内蔵 40 kΩ プルアップと 内蔵 70 ns ノイズフィルタ付き
• 外付け 100 nF をグランド側に置くと電磁ノイズ環境での誤リセットを防げる（必須ではないが推奨）
• NRST が Low 固定（GND ショート、外付け回路の不具合）になっていると ST-LINK が永遠に Reset 状態から抜け出せず接続不能

BOOT0 浮き

BOOT0 を物理的に何も接続しないと、起動するたびにランダムに ROM ブート / ユーザコード起動が切り替わってしまいます。10 kΩ ～ 1 MΩ のプルダウン抵抗を必ず接続してください。

VDD / VDDA 電源

VDD / VDDA が POR / PDR スレッショルド（典型 1.71V）未達だと、チップは Reset 状態に張り付き SWJ-DP に応答しません。電源が立ち上がっているか、ノイズで瞬断していないかを必ず実機で電圧確認してください。

SWD ライン長

SWD クロックは使用するデバッグプローブに依存し、ST-LINK/V3 で最大 24 MHz 程度まで設定できますが、ノイズ環境では数 MHz 程度に落とすのが安全です。配線は短く（典型 20 cm 以下）、GND を並走させてシールド代わりにすると安定します。

14 ステップ救出チェックリスト

原因の特定が難しい場合、以下のチェックリストを上から順に試してください。経験上、9 割のケースは 10 番目までで解決します。

公式リソース・参考文献

最重要 Application Note / User Manual

• AN4989 – STM32 Microcontroller Debug Toolbox（救出全般の決定版）
  st.com → AN4989 PDF
• AN2606 – STM32 microcontroller system memory boot mode（BOOT0 ブートローダ仕様）
  st.com → AN2606 PDF
• UM2237 – STM32CubeProgrammer software description
  st.com → UM2237 PDF
• UM1075 – ST-LINK/V2 user manual
  st.com → UM1075 PDF
• UM2448 – STLINK-V3SET user manual
  st.com → UM2448 PDF
• RN0093 – ST-LINK firmware upgrade release note
  st.com → RN0093 PDF

セキュリティ / TrustZone 系

• AN5347 – Introduction to Arm TrustZone features on STM32 L5 / U5 / U3
• AN5421 – Getting started with STM32 MCUs and Arm TrustZone
• AN6008 – Getting started with Debug Authentication (DA) for STM32
• AN4758 – Proprietary Code Readout Protection on L4 / G4 / WB

ツール

• STM32CubeProgrammer（公式書き込み・診断ツール）
• STSW-LINK007（ST-LINK ファームウェア更新ツール）

コミュニティ・参考

• ST Community – How to solve debugger connection issues
• ST Community – FAQ STM32 boot process
• stmcu.jp – ST-LINK Utility のリセットスタート（日本語）

まとめ

STM32 開発で「もうチップが壊れたかもしれない」と諦める前に、ぜひ本記事のチェックリストを試してみてください。それでも解決しない場合や、量産設計でこうしたトラブルを未然に防ぎたい場合は、弊社にお気軽にご相談ください。設計から量産対応まで、20 年超のマイコン開発実績で一貫してサポートします。