# STM32 で ST-LINK が突然繋がらなくなった時の救出ガイド｜SWD ピン誤定義・Stop モード切断・Connect Under Reset の全手順｜株式会社テクノスフィア

> STM32 で誰もが遭遇する「ST-LINK が繋がらない」「Target was not detected」の救出手順を AN4989・UM2237・UM1075 を一次資料に 14 ステップで体系化。SWD 復旧から偽物検出まで網羅。

URL: https://technosphere.co.jp/blog/stm32-swd-debugger-rescue

** 目次
1. はじめに：誰もが一度は遭遇するエラー
2. SWD / SWO ピンの正式割当を再確認
3. 原因別 救出マトリクス（早見表）
4. 原因 A：SWD ピンを GPIO に再定義してしまった
5. 原因 B：Stop / Standby モードで切断される
6. 原因 C：CubeMX で "Serial Wire" を設定し忘れた
7. 原因 D：ST-LINK ハードウェア / ファームウェア
8. 原因 E：Read Out Protection (RDP) で締め出された
9. 原因 F：電源・配線・NRST まわり
10. 14 ステップ救出チェックリスト
11. 公式リソース・参考文献
12. まとめ

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

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 ステップのチェックリスト**を体系化します。  ** 弊社での活用実績

弊社は STM32 F4 / L4 / G4 / U5 系を中心に [多数の組込み開発実績](https://technosphere.co.jp/embedded-achievements) があり、本記事に出てくる救出パターンはすべて現場で実際に遭遇したものです。基礎となる SWD ピン配置や CubeMX の使い方は [STM32 のUART・I2C・SPI・CAN通信 実装ガイド](https://technosphere.co.jp/blog/stm32-uart-i2c-can) を併せてご覧ください。

## 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** | SWDIO（JTAG時 JTMS） | 入力、内部プルアップ有効 |
| **PA14** | SWCLK（JTAG時 JTCK） | 入力、内部プルダウン有効 |
| PA15 | JTDI（5pin JTAG時のみ） | AF 入力、内部プルアップ |
| **PB3** | JTDO / TRACESWO（SWO 出力） | AF 出力（リセット直後 JTAG/SWV 用） |
| PB4 | NJTRST | AF 入力、内部プルアップ |

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

STM32CubeMX → **Pinout & Configuration → System Core → SYS → Debug** プルダウンの選択肢：
- **Serial Wire**（推奨デフォルト。SWDIO + SWCLK のみ確保）
- **Trace Asynchronous Sw**（Serial Wire + SWO（PB3））
- JTAG (4 pins) / JTAG (5 pins)
- **No Debug** ← これを選ぶと PA13 / PA14 が GPIO に解放され、書き込み不能の最大原因になる

「とりあえず GPIO を増やしたい」という理由で No Debug を選んで生成した瞬間、次回フラッシュ書き込み後にデバッガから二度と見えなくなります。(出典: AN4989 Figure 24 "SWD Pins PA13 And PA14 In Reset State Under CubeMX")

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

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

症状からおおよその原因と救出手順を絞り込む早見表です。複数該当することも多いので、上から順に試すのが定石です。
| 症状の特徴 | 主原因 | 救出方法 |
| 昨日まで動いていたのに突然繋がらない | SWD ピンを GPIO に再定義 / No Debug を選択 | Connect Under Reset → Mass Erase（原因A） |
| 書き込みは一瞬通るがすぐ Disconnect される | 起動直後に Stop モード突入 | Connect Under Reset（原因B） |
| STM32CubeIDE デバッグ中、Stop に入ると即切断 | DBGMCU_CR.DBG_STOP が 0 | `HAL_DBGMCU_EnableDBGStopMode()` 呼出し（原因B） |
| 新規 CubeMX プロジェクトを書いた直後から接続不能 | SYS で Serial Wire 未設定 | Connect Under Reset → Mass Erase（原因C） |
| 新しい品種が認識されない | ST-LINK ファームウェア古い | STSW-LINK007 で更新（原因D） |
| "Unable to connect" でファーム情報も読めない | USB ケーブル / VAPP / 偽物 ST-LINK | ケーブル交換・VAPP 確認（原因D） |
| Connect は通るが Read Out Protection エラー | RDP Level 1 / 2 | RDP regression（原因E） |
| ターゲット電圧が読めない / VAPP 0V | ターゲット未給電・NRST Low固定 | 電源・配線確認（原因F） |

## 原因 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」**に網羅されています。  ** STM32G0 系の罠：BOOT0 = PA14（SWCLK と共有）

STM32G0 シリーズでは **BOOT0 と SWCLK が同じ PA14 ピン**に割り当てられています。さらにデフォルトの Option Byte は **nBOOT_SEL = 1, nBOOT0 = 1** なので、Option Bit が優先され **物理 BOOT0 ピンに 3.3V を入れても反応しません**。Method B を使うには事前に nBOOT_SEL = 0 に書き換える必要があります。

STM32L4R / L4S 系は PH3-BOOT0 兼用、STM32U5 / L5 / H5 系も Option Byte 制御です。**BOOT0 ピンの位置と挙動は必ず該当品種のデータシートで確認**してください。(出典: ST Community「STM32G030 BOOT0 versus SWD」/「PH3-BOOT pin」)

### 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)
| ビット | 名前 | 効果 |
| 0 | DBG_SLEEP | Sleep モード中も HCLK 維持、デバッグ継続可 |
| 1 | DBG_STOP | Stop モード中も全クロック維持、デバッグ継続可 |
| 2 | DBG_STANDBY | Standby モード中も電源・クロック維持、デバッグ継続可 |

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

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

   ** リリースビルドで消費電流が下がらない問題

DBGMCU_CR は **POR（パワーオンリセット）でしかクリアされません**。System Reset（NRST）では値が残ります。デバッガで書き込んだリリース版が `DBG_STOP = 1` のまま走ると、Stop モード入っても本来の µA レベルまで消費電流が落ちません。

対策：① 一度電源を OFF / ON する、② ファーム冒頭で明示的に `DBGMCU->CR = 0;` を書く、③ IDE の「Reset after download」を有効化。(出典: ST Community「Increased consumption in low power modes」)

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

「起動直後 Stop に入る」コードを書き込んでしまったあとは、**原因 A の Method A（Connect Under Reset）と同じ手順**でしか救えません。低消費電力設計の詳細は [STM32 低消費電力モード完全ガイド](https://technosphere.co.jp/blog/stm32-low-power-battery) をご覧ください。

## 原因 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 世代別の機能差
| 機種 | SWD | JTAG | SWO | VCP | 備考 |
| ST-LINK/V2 | ○ | ○ | ○ | - | 標準スタンドアロン |
| ST-LINK/V2-1 | ○ | - | ○ | ○ | Nucleo 等に内蔵、Mass Storage 書込可 |
| STLINK-V3SET | ○ | ○ | ○ | ○ | 最新フラッグシップ、Bridge API 対応 |
| STLINK-V3MINI(E) | ○ | - | ○ | ○ | 小型版 |

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

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` バイトで制御されます。
| Level | バイト値 | 効果 | 戻せるか |
| 0 | 0xAA | 全アクセス可 | - |
| 0.5 | 0x55 | STM32 U5 等 TrustZone 系のみ。Non-secure のみ書込可 | 0 へ可 |
| 1 | 0xAA / 0xCC 以外（典型 0xBB） | デバッガ・RAM・Bootloader からの Flash 読出禁止 | 0 へ regression 可（**Flash Mass Erase 自動実行**） |
| 2 | 0xCC | JTAG / SWD / SWV / ETM / Boundary Scan 全停止、Option Byte 改変不可 | **不可（永久）** |

### 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 で通常接続可能
```

   ** RDP Level 2 は絶対に誤設定しないこと

RDP = 0xCC は **JTAG / SWD / SWV / ETM / Boundary Scan が永久に無効化**されます。Option Byte の書き換えすら不可能になり、その個体はデバッグもプログラム書き換えも一切できなくなります。実質的に廃棄です。Level 2 は最終量産直前の最後のステップだけで使用してください。

### 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 番目までで解決します。
| # | チェック項目 | 対象原因 |
| 1 | USB ケーブルを交換し、別 USB ポートへ挿し直す | D |
| 2 | ST-LINK ドライバ確認・更新（特に Windows） | D |
| 3 | ST-LINK ファームウェア更新（STSW-LINK007） | D |
| 4 | ターゲット電源確認：VDD / VDDA 電圧、VAPP 接続、BOOT0 プルダウン | F |
| 5 | SWD 配線導通チェック：SWDIO / SWCLK / GND / NRST / VAPP | F |
| 6 | SWD 周波数を下げる：4 MHz → 1.8 MHz → 950 kHz | D / F |
| 7 | STM32CubeProgrammer の "Mode" を "Under Reset"、"Reset Mode" を "Hardware reset" に | A / B / C |
| 8 | 物理 RESET ボタンを押しながら "Connect"、接続後ボタン離して即 "Full Chip Erase" | A / B / C |
| 9 | BOOT0 = High で System Memory Bootloader 起動 → DFU / UART で Mass Erase | A / B / C |
| 10 | Option Bytes 読み出し（`-ob displ`）で RDP / nBOOT_SEL / nBOOT0 状態確認 | E |
| 11 | RDP = 0xAA に書き戻し（自動 Mass Erase 実行） | E |
| 12 | 別ベンダの probe（J-Link / Black Magic）で接続試行（ST-LINK 個体不良切り分け） | D |
| 13 | 偽物 ST-LINK 疑いなら、NRST 配線をテスター確認 or 正規品に交換 | D |
| 14 | TrustZone 系（U5 / L5 / H5）なら Debug Authentication / RDP regression 検討 | E |      ** 切り分けのコツ
- **別ボードでは ST-LINK が動くか** ― 別のターゲットで接続テストすれば、ST-LINK 自体の故障かが切り分けられる
- **別の ST-LINK ではどうか** ― 同じターゲットを別の ST-LINK で接続。Connect Under Reset が効くかどうかで個体差を確認
- **BOOT0 = High でも繋がらないなら基板側の電源・水晶を疑う** ― ROM ブートでも繋がらない場合、ハードウェア起因の可能性が高い

## 公式リソース・参考文献

### 最重要 Application Note / User Manual
- **AN4989** – STM32 Microcontroller Debug Toolbox（救出全般の決定版）
 [st.com → AN4989 PDF](https://www.st.com/resource/en/application_note/an4989-stm32-microcontroller-debug-toolbox-stmicroelectronics.pdf)
- **AN2606** – STM32 microcontroller system memory boot mode（BOOT0 ブートローダ仕様）
 [st.com → AN2606 PDF](https://www.st.com/resource/en/application_note/an2606-introduction-to-system-memory-boot-mode-on-stm32-mcus-stmicroelectronics.pdf)
- **UM2237** – STM32CubeProgrammer software description
 [st.com → UM2237 PDF](https://www.st.com/resource/en/user_manual/um2237-stm32cubeprogrammer-software-description-stmicroelectronics.pdf)
- **UM1075** – ST-LINK/V2 user manual
 [st.com → UM1075 PDF](https://www.st.com/resource/en/user_manual/um1075-stlinkv2-incircuit-debuggerprogrammer-for-stm8-and-stm32-stmicroelectronics.pdf)
- **UM2448** – STLINK-V3SET user manual
 [st.com → UM2448 PDF](https://www.st.com/resource/en/user_manual/um2448-stlinkv3set-debuggerprogrammer-for-stm8-and-stm32-stmicroelectronics.pdf)
- **RN0093** – ST-LINK firmware upgrade release note
 [st.com → RN0093 PDF](https://www.st.com/resource/en/release_note/rn0093-firmware-upgrade-for-stlink-stlinkv2-stlinkv21-and-stlinkv3-boards-stmicroelectronics.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（公式書き込み・診断ツール）](https://www.st.com/en/development-tools/stm32cubeprog.html)
- [STSW-LINK007（ST-LINK ファームウェア更新ツール）](https://www.st.com/en/development-tools/stsw-link007.html)

### コミュニティ・参考
- [ST Community – How to solve debugger connection issues](https://community.st.com/t5/stm32-mcus/how-to-solve-debugger-connection-issues/ta-p/49693)
- [ST Community – FAQ STM32 boot process](https://community.st.com/t5/stm32-mcus/faq-stm32-boot-process/ta-p/49358)
- [stmcu.jp – ST-LINK Utility のリセットスタート（日本語）](https://www.stmcu.jp/technical/hint/no-017/)

## まとめ

###  この記事のまとめ
- STM32 の SWD ピンは **PA13 (SWDIO) / PA14 (SWCLK) / PB3 (SWO)** がリセット直後の確保ピン
- CubeMX で「Debug = No Debug」を選んだ瞬間に PA13 / PA14 が GPIO 解放され、書き込み不能の最大原因に
- **Connect Under Reset** が SWD ピン GPIO 化・Stop モード突入・CubeMX 設定漏れすべての第一救出手段
- **BOOT0 = High で System Memory Bootloader** がそれでもダメな時の本命。STM32G0 系は nBOOT_SEL = 1 デフォルトに注意
- 低消費電力アプリでは `HAL_DBGMCU_EnableDBGStopMode()` を `#ifdef DEBUG` で囲んで活用。リリースビルドの消費電流問題に注意
- **RDP Level 2 は永久不可逆**。最終量産直前まで絶対に書かないこと
- 偽物 ST-LINK は NRST 配線が省略されている個体があり、Connect Under Reset が効かない
- **14 ステップのチェックリスト**を上から順に試せば 9 割のケースは解決する

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

STM32 の量産トラブル・基板リバイバル・SWD 接続不能の調査・救出まで [組込み制御・マイコン開発](https://technosphere.co.jp/embedded) として対応しています。   ／この内容の受託開発・PoC相談はこちら＼

### STM32 量産トラブル・基板リバイバルの受託対応

SWD接続不良・RDP 解除・量産バグの再現解析・既存基板の再生など、現場で詰んでいる組込みトラブルを救出します。20 年超のマイコン開発ノウハウをベースに、設計から量産対応まで一貫してサポート。  [組込み開発サービスを見る](https://technosphere.co.jp/embedded) [量産トラブル・救出相談](https://technosphere.co.jp/contact)

## よくある質問（FAQ）   ** ST-LINKでSTM32に接続できなくなったとき、最初に何を試すべきですか？

最も成功率が高いのはConnect Under Resetです。NRSTを配線した状態でSTM32CubeProgrammerのリセット方式をHardware resetにし、リセット直後にデバッガを接続します。それでも入れない場合はBOOT0 = HighでSystem Memory Bootloaderを起動し、DFU/UART経由でフラッシュを消去します。   ** SWDピンをGPIOに再定義して書き込めなくなった場合はどう復旧しますか？

リセット直後の瞬間はSWDピンがまだデバッグ機能に割り当てられているため、Connect Under Resetで接続してフラッシュを消去するのが定石です。接続できない場合はBOOT0 = Highで起動すればユーザーコードが実行されないため、System Memory Bootloader経由で復旧できます。   ** Stop/Standbyモードに入るとST-LINKが切断されるのはなぜですか？

低消費電力モードではデバッグ用のクロックも停止するためです。開発中はHAL_DBGMCU_EnableDBGStopMode / HAL_DBGMCU_EnableDBGStandbyModeを呼んでおくとデバッグ接続を維持できます。消費電流が増えるため、量産ファームウェアでは必ず無効化（DBGMCU->CR = 0）してください。   ** 安価な互換ST-LINKで接続に失敗することはありますか？

あります。互換品にはRESET線が引き出されておらずConnect Under Resetが実行できない個体が存在します。正規のST-LINK V2 / V2-1 / V3に交換するのが最も確実で、代替としてJ-LinkやBlack Magic Probeを使う方法もあります。     # STM32 # ST-LINK # SWD # デバッガ # STM32CubeProgrammer # BOOT0 # RDP # マイコン開発

##   次に読む｜STM32 シリーズ記事
-  [STM32 シリーズ STM32マイコンのUART・I2C・SPI・CAN通信 実装ガイド HAL ライブラリで通信ペリフェラルを使いこなす定番ガイド](https://technosphere.co.jp/blog/stm32-uart-i2c-can)
-  [STM32 シリーズ STM32 低消費電力モード完全ガイド Stop / Standby / Shutdown 活用で年単位のバッテリー駆動](https://technosphere.co.jp/blog/stm32-low-power-battery)
-  [STM32 シリーズ STM32G4 内蔵アナログ計測誤差の罠 R_AIN とサンプリング時間の関係を一次資料で読み解く](https://technosphere.co.jp/blog/stm32-g4-analog-precision)
-  [開発実績 組込み制御・マイコン開発 実績紹介 STM32 量産案件を含む 20 年超の事例](https://technosphere.co.jp/embedded-achievements)
   [技術コラム一覧に戻る](https://technosphere.co.jp/blog/)