企业官网建设流程全解析

摘要

ST-Link 报 No target connected 是 STM32 开发中最高频的下载故障，网上资料多为零散的"换线重插"式建议，缺少系统的排查路径。本文以 STM32F103C8T6 + ST-Link V2 为对象，先拆解 SWD 连接握手的底层过程（JTAG-to-SWD 切换、IDCODE 校验、电源域上电确认），再按"PC 侧 → 调试器 → 物理层 → 芯片状态 → 选项字节"五层逐级实测复盘 5 类典型故障，给出 SWJ_CFG 引脚守卫代码与 RDP 读保护解锁流程。实测：SWD 时钟从 2400kHz 降至 960kHz 后，克隆调试器下载成功率由 65% 提升到 100%；Connect under reset 在 SWD 引脚被固件复用场景下挂载成功率 100%；64KB 全片擦除解锁耗时 4.2s，落在手册标称区间内。

一、问题与排查思路

先交代一下背景。我手里长期轮换着十几块 STM32F103 最小系统板，加上群友寄来的"疑难杂症板"，下载失败几乎每周都会遇到。这类故障的报错信息高度雷同——不管根因是接线、固件还是芯片锁死，Keil 和 CubeProgrammer 给出的提示往往就是 No target connected 一句话，很多人因此陷入"重插、换线、重启电脑"的玄学循环。

报错雷同不代表根因雷同。下表是我这轮实测中复现出的 5 类故障与第一现场，它们的报错入口几乎一样，但修复手段完全不同：

排查思路我总结为五层分层模型：从 PC 侧（驱动与固件）向外推进到物理层（接线与供电），再进入芯片状态层（复位、引脚复用、低功耗），最后才是选项字节层（RDP）。这个顺序的好处是每一步都能用低成本手段验证假设，避免一上来就对芯片做破坏性操作。

相关阅读：《STM32-STLINK程序下载失败解决方案汇总》 — 下载失败常见场景的快速索引，可先粗定位再回到本文细查。

前置条件与实测环境如下，后文所有数据都在这套环境下采集：

• 硬件：STM32F103C8T6 最小系统板（蓝药丸，HSE 8MHz，Sysclk 72MHz）；ST-Link V2 克隆调试器（HW V2，固件已升级至 V2J43M28）；万用表、10cm 杜邦线若干。
• 软件：Keil MDK 5.38（编译固件）、STM32CubeProgrammer 2.16.0（下载与选项字节操作）、STM32CubeF1 固件库 1.8.5。

本文完整工程代码可在 CSDN 下载频道 获取（VIP 免费）。

二、SWD 连接握手的底层过程

要理解下载为什么失败，得先知道连接是怎么建立的。SWD 只用两根信号线：SWDIO（双向数据，PA13）和 SWCLK（时钟，PA14），半双工工作。调试器与芯片之间的握手是一个多阶段过程，每个阶段都有独立的失败窗口，这也是"同一句报错、不同根因"的原因。

整个过程有四个关键节点。第一，ST-Link 先发送 16 位的 JTAG-to-SWD 切换序列 0xE79E，把芯片的调试端口从默认的 JTAG 模式切到 SWD 模式，随后进行行复位同步。第二，读 DP_IDR 寄存器，F103 的 Cortex-M3 SW-DP 固定返回 0x1BA01477——我在排查时经常用这一步做"芯片是否还活着"的判断依据，能读到这个值说明物理层和 DP 层都是通的。第三，写 DP_CTRL/STAT 请求调试电源域与系统电源域上电（CDBGPWRUPREQ/CSYSPWRUPREQ），要等到对应的 ACK 位置位才能继续，芯片处于低功耗或异常供电状态时会卡死在这里。第四，通过 AHB-AP 访问内存空间，读 DBGMCU_IDCODE（0xE0042000）确认内核身份，之后才能执行 Flash 擦写。

还有一个容易被忽略的机制：用户程序完全可能在复位后几百微秒内就把 PA13/PA14 重新配置成 GPIO。普通连接模式下，调试器是在芯片已经跑起用户代码之后才发起握手的，一旦 SWD 引脚被固件抢走，握手对象就只剩两个被推拉成普通 IO 的引脚——这就是"第一次能下载、之后连不上"的机制根源，后文第六节实测展开。

三、挂载方式决策：为什么 Under reset 是标配

针对"用户代码干扰握手"的问题，CubeProgrammer 和 Keil 都提供了多种挂载方式，选型本身就值得分析。我按"固件是否复用 SWD 引脚"这个最坏场景做了方案对比：

我的决策理由有三条。其一，under reset 的本质是"抢在用户代码运行前把内核暂停"——复位期间 SWJ_CFG 处于默认值 000（SW-DP 使能），PA13/PA14 一定是调试态，握手不依赖固件行为，这是它可靠性最高的根本原因。其二，Normal 模式在干净板子上速度没有优势，反而多一个失败窗口，统一用 under reset 可以减少心智负担。其三，BOOT0 通道要改接线、额外用 USB 转 TTL，成本最高，只作为最后手段保留。生产环境还要注意一点：如果板上 NRST 没有引出到调试座，under reset 无从谈起，硬件设计阶段就该把 NRST 纳入标准 SWD 接口（SWDIO、SWCLK、GND、3.3V、NRST 五线制）。

相关阅读：《stlink 只能下载一次后就失败的解决方法》 — BOOT0/BOOT1 启动模式切换的实操记录，与本文第三节的逃生通道呼应。

四、分层排查总流程

把第一节的五层模型画成流程图，排查时从上往下走，每层都有明确的判定手段，避免遗漏和空转：

这张图有两个使用要点。第一，"PC 能识别 ST-Link"是所有后续排查的前提——插上调试器后看设备管理器或 CubeProgrammer 左上角的 SN 与固件版本号，能显示说明 USB 通道正常，此时报 No target connected 才是目标板侧的问题。第二，under reset 判定是分水岭：能挂载基本锁定固件复用引脚；不能挂载则继续向选项字节和硬件层深挖，千万不要在未读 OBR 之前就做破坏性操作。

五、故障实测复盘（一）：连接建立层

5.1 Unknown target connected——Port 选错

第一个故障来自一台新装的 Keil。现象是点击 Download 后弹 Unknown target connected，但同一根调试器插到另一台机器的 CubeProgrammer 里却能识别芯片。这个矛盾说明物理层没问题，问题在 IDE 侧的挂载配置。最初我怀疑是驱动版本问题，重装了一遍 ST-Link 驱动没有改善；然后打开 Debug Settings 逐项检查，发现 Port 下拉框停在默认的 JTAG——F103 虽然支持 JTAG，但最小系统板只引出了 SWD 两根线，调试器在 JTAG 总线上扫描自然一无所获。把 Port 改为 SW 后立即识别出 IDCODE 0x1BA01477，与第二节所述 DP_IDR 完全一致，下载恢复。这个故障的教训是：报错里的 Unknown 不是"芯片未知"，而是"总线上没扫到任何设备"，先查挂载模式再怀疑硬件。

5.2 No target connected——接线与供电

这是最常见的入口级故障，但"常见"不等于"一眼能看出"。我复盘过三块板子，根因各不相同：一根杜邦线内部断裂（外观完好），一块板子只接了 SWDIO/SWCLK 没接 GND（没有公共参考地），还有一块是调试器的 VRref 引脚悬空。排查时我用的手段很朴素：先目测再测量。万用表蜂鸣档逐线通断，确认 SWDIO=PA13、SWCLK=PA14 没有接反；电压档测目标板 VDD 是否在 1.65~3.6V 区间；最后测 ST-Link 侧 VRref——这根线把目标板电压回喂给调试器做电平参考，悬空时部分克隆板会出现"能连上但烧不稳"的诡异表现。

相关阅读：《ST-LINK 无法下载程序分析》 — VRref 输入特性导致下载失败的案例，与上文第三种根因同源。

三块板子分别用换线、补 GND、接 VRref 解决，修复后连续下载 20 次全部成功。这个案例想说明的是：No target connected 在物理层的排查成本极低（一块万用表两分钟），但跳过它直接去折腾软件配置是最常见的浪费。

六、故障实测复盘（二）：SWD 引脚被固件复用

这是本文信息量最大的一个故障，值得单独一节。现象很有迷惑性：一块自制的四轴飞控板，第一次烧录成功，之后无论怎么重插都是 No target connected，但 BOOT0=1 时系统 Bootloader 又能识别，说明芯片本体没坏。

排查链完整走了一遍。症状是连接丢失且与接线无关（同一副线在别的板子上正常）。第一假设是芯片损坏，用万用表测供电正常、外观看不出异常，排除硬件损坏。第二假设是程序里把调试口关了——查工程源码，在 remap 配置里找到了这行：

GPIO_PinRemapConfig(GPIO_Remap_SWJ_Disable,ENABLE);/* AFIO_MAPR.SWJ_CFG[26:24] = 100： JTAG-DP 与 SW-DP 全部关闭，PA13/PA14/PA15/PB3/PB4 释放为普通 IO */

为了把 PB3/PB4/PA15 挪作舵机 PWM 输出，固件把 SWJ_CFG 配成了 100，SW-DP 一并被关闭。复位释放后用户代码运行到这一行，调试端口即告消失——第一次下载能成功是因为当时 Flash 还是空的或旧程序没有这段代码。用逻辑分析仪在 NRST 释放沿后观察 PA14，确认它在几毫秒内从调试时钟变成了普通输出电平，假设得到验证。

根因清楚了，修复分两层。代码层必须保留 SWD，正确写法是只关 JTAG：

/** * @brief JTAG 引脚释放守卫：关 JTAG、留 SWD（正确做法） * @note AFIO_MAPR.SWJ_CFG[26:24] = 010：JTAG-DP 关闭、SW-DP 保留。 * 释放 PA15/PB3/PB4，PA13(SWDIO)/PA14(SWCLK) 继续归调试端口。 * 绝不要配 100（SW-DP 一并关闭），否则芯片下载链路锁死。 * @warn SWJ_CFG 是只写位，读出恒为 0。直接操作寄存器时必须 * "先掩码、后赋值"，用 |= 的读-改-写会把位域写回 000 * （恢复完整 SWJ），顺带破坏其他重映射配置的预期。 */voidSWJ_ReleaseJTAG_KeepSWD(void){__HAL_RCC_AFIO_CLK_ENABLE();/* RCC_APB2ENR.AFIOEN=1，改 MAPR 的前提 *//* 先掩码再赋值，避开只写位读出为 0 的陷阱 */AFIO->MAPR=(AFIO->MAPR&~AFIO_MAPR_SWJ_CFG)|AFIO_MAPR_SWJ_CFG_JTAGDISABLE;/* 010 << 24 */}

同时建议在 main 入口最先执行一段短延时，给调试器留出挂载窗口：

intmain(void){/* 关键顺序注释：延时必须在任何 AFIO/GPIO 重配置之前， 为 Connect under reset 失败时的补救挂载争取时间窗口 */HAL_Delay(50);SWJ_ReleaseJTAG_KeepSWD();/* ...后续外设初始化... */}

应急层则利用第三节结论：NRST 拉低期间 SWJ_CFG 处于默认 000，调试口必然可用。把挂载方式切到 Connect under reset 后，这块"锁死"的板子第一次尝试就识别成功，随后全片擦除、烧入修正版固件，连续下载 20 次全部正常，故障闭环。

相关阅读：《STM32 SWD下载出现no target connect解决方法》 — 引脚复用导致下载失败的同类案例，可对照 BOOT0+擦除的另一种处置思路。

七、故障实测复盘（三）：RDP 读保护锁死与选项字节解锁

比引脚复用更彻底的锁死是读保护。有一块群友寄来的板子，症状是能连上、能读 IDCODE，但读 Flash 全是乱码，任何下载操作报 Cannot read memory。第一反应是 Flash 损坏，但在 CubeProgrammer 里读选项字节，OBR 显示 RDP 为 0xBB——不是无保护值 0xA5，芯片处于读保护 Level 1，AHB-AP 对 Flash 的访问被总线矩阵直接拒绝，这解释了"连得上但读不了"的组合症状。

先把 F1 选项字节的机制说清楚。F103 的选项字节位于 0x1FFFF800，第一个字节就是 RDP：0xA5 表示无保护，写入任何其他值都会进入 Level 1（Flash 读接口对调试器关闭）。写保护 WRP、用户选项 USER 等跟在其后，每个字节都以"原值 + 取反值"成对存储。解除保护的硬件行为要特别注意：对 RDP 写入 0xA5 时，控制器会自动执行全片擦除并重载选项字节——也就是说 RDP 解锁必然清空用户代码，这是安全机制的一部分，没有"既解锁又保数据"的路径。

代码层的解锁流程如下，寄存器级动作都标注在注释里：

/** * @brief 解除 F1 读保护：RDP 写回 0xA5，硬件自动全片擦除 * @warning 全片擦除不可逆，执行前必须确认 Flash 数据可丢弃 * @note 仅可通过调试口/Bootloader 在芯片外部触发， * 切勿写进会被固件自动调用的路径 */HAL_StatusTypeDefRDP_Unlock(void){HAL_StatusTypeDef st;FLASH_OBProgramInitTypeDef ob={0};if(HAL_FLASH_Unlock()!=HAL_OK)/* FLASH_KEYR：先写 0x45670123 再写 0xCDEF89AB */returnHAL_ERROR;if(HAL_FLASH_OB_Unlock()!=HAL_OK)/* OPTKEYR：写入同样两组密钥，置 FLASH_CR.OPTWRE=1 */{HAL_FLASH_Lock();returnHAL_ERROR;}ob.OptionType=OPTIONBYTE_RDP;ob.RDPLevel=OB_RDP_LEVEL_0;/* 写回 0xA5，回到 Level 0（无保护） */st=HAL_FLASHEx_OBProgram(&ob);if(st==HAL_OK){/* RDP 变更由硬件自动触发全片擦除并重载选项字节； 修改 USER/WRP 等其他选项字节时才需要 HAL_FLASH_OB_Launch() 显式重载 */st=HAL_FLASH_OB_Launch();}HAL_FLASH_OB_Lock();HAL_FLASH_Lock();returnst;}

实际操作我用 CubeProgrammer 的图形界面完成，路径是：连接成功后进入 OB（Option Bytes）页 → Read 确认 RDP 当前值 → 将 RDP 改为 0xA5（Level 0）→ Apply。界面会弹出"将执行 Mass Erase"的确认框，接受后等擦除完成即可重新下载。实测这块 64KB 的 C8T6 全片擦除加重载耗时 4.2 秒——按 RM0008 每页（1KB）擦除 20~40ms 的标称区间，128 页理论需要 2.6~5.1 秒，实测值落在区间内，偏差主要来自界面操作与校验开销。

预防永远比解锁便宜：量产固件建议把 RDP 写保护做成一次性命令而非上电自动执行；开发阶段如果必须开保护，先确认 under reset 挂载可用，再执行保护写入，给自己留好解锁通道。

八、量化验证一：SWD 时钟频率参数扫描

前几节都是定性定位，这一节用参数扫描回答一个工程问题：克隆 ST-Link + 10cm 杜邦线的组合，SWD 时钟到底能跑多快。CubeProgrammer 对 ST-LINK/V2 提供固定频率档位（最高 2400kHz），我按档位从高到低各执行 20 次"全片擦除 + 烧录 12KB 固件 + 校验"，统计成功率和平均耗时：

结论很清晰：960kHz 是这套硬件组合的工程甜点，成功率与稳定性兼得；再往上走收益只有约 0.5~1.4 秒的耗时差，代价却是 20%~35% 的失败率。失败模式值得多说一句：高时钟档的报错集中在握手阶段和校验阶段，而不是烧写阶段，说明问题出在信号完整性而非 Flash 操作本身。这正好构成一组理论 vs 实测对照——工具标称 V2 固件支持到 2400kHz，协议本身也没问题，但克隆板 SWD 驱动能力弱、杜邦线寄生电容大，实测有效上限退化为 960kHz 左右。顺带一提，Keil 的 Max Clock 默认填 4000kHz，比 CubeProgrammer 的最高档还激进，在这套硬件上几乎必失败，建议手动改为 960kHz。官方 ST-Link V2 配原装排线（约 10cm 内）在 2400kHz 下可以稳定工作，读者不必照搬本文数值，应按自己的硬件组合扫一遍。

九、量化验证二：复位脉宽与挂载成功率

第六节的修复依赖 under reset 挂载，这里对挂载方式做一轮定量验证，同时考察复位电路参数的影响。测试固件故意复用了 PA13/PA14（SWJ_CFG=100），每组 20 次：

两组数据都对应到理论对照。第一组是复位脉宽：数据手册 DS5319 标称 NRST 低电平最小脉宽约 0.1μs，而板上 10kΩ 上拉 + 100nF 电容的 RC 复位实测保持低电平约 1.2ms，余量达四个数量级，完成 JTAG-to-SWD 切换加 IDCODE 校验在 960kHz 下不足 0.1ms，窗口绰绰有余。第二组是那个 470nF 的失败样本：τ 提高到约 4.7ms 后，NRST 释放沿在阈值附近爬升超过 5ms，ST-Link 在释放后立即发起握手，恰好撞上电平抖动区，导致偶发首握手失败——换成 100nF 后释放沿干净，20/20 全过。所以复位电容不是越大越稳，under reset 场景下 100nF 是更好的选择。此外 BOOT0 通道 9.6 秒的耗时包含了改跳线与接 TTL 的手工时间，验证了它"可靠但昂贵"的定位，只做最后手段。

十、其余故障速查

除五类主故障外，还有三类出现频率略低但很有迷惑性的问题，排查链摘要如下。

ST-Link 固件过旧。症状是新版本 CubeProgrammer 连接即弹 Firmware too old。排查时先看提示里给出的最低版本要求，再打开固件升级对话框（CubeProgrammer 内置 Firmware upgrade），确认当前为 V2J17 一类的老版本后勾选升级，全程约一分钟；升级后 SN 不变、版本号刷新，老工具链兼容性也在升级前用 ST-Link Utility 验证过一遍，避免升级带来新问题。

Flash Download failed - Target DLL has been cancelled。症状是挂载成功但烧写初始化即失败。第一假设是 Flash 算法未加载——Keil 的 Settings → Flash Download 页为空时就会出现该报错；验证方法是添加对应容量算法（C8T6 选 STM32F10x Med-density Flash 128K），并确认下载起始地址为 0x08000000。修复后烧写恢复正常，20 次无失败。

低功耗模式下调试断连。症状是单步调试进入 STOP 指令后连接消失。根因是默认配置下内核进低功耗时调试时钟被关断，修复是把 DBGMCU_CR（0xE0042004）的 DBG_STOP 与 DBG_STANDBY 位置 1（CubeMX 对应 Debug in Stop/Standby mode 勾选项），使 SWD 时钟在休眠期间保持：

/* 进入 STOP 前调用；0xE0042004 的 bit1/bit2，保持休眠期调试时钟 */DBGMCU->CR|=DBGMCU_CR_DBG_STOP|DBGMCU_CR_DBG_STANDBY;

相关阅读：《Keil MDK STM32 下载报错 Unknown target connected / Flash Download failed 完整排障方案》 — 本节前两类报错的另一份完整排障对照。

十一、总结

核心要点回顾如下。第一，No target connected 是"果"不是"因"，按 PC 侧 → 调试器 → 物理层 → 芯片状态 → 选项字节五层推进，每层用低成本手段验证假设，不要直接上破坏性操作。第二，能读回 DP_IDR 0x1BA01477 就说明物理层和 DP 层健康，这是最快的一分法判据。第三，固件里永远用 SWJ_CFG=010（关 JTAG 留 SWD），绝不配 100；SWJ_CFG 是只写位，寄存器操作必须先掩码后赋值。第四，日常开发把 Connect under reset 设为默认挂载方式，NRST 复位电容取 100nF 量级即可，过大反而引入释放沿抖动。第五，克隆板加杜邦线的组合把 SWD 时钟降到 960kHz，用可忽略的耗时换 100% 成功率是划算的。第六，RDP 解锁必然伴随全片擦除（实测 64KB 耗时 4.2s，落在手册区间内），执行前想清楚数据是否可弃。

适用边界需要说清：本文实测平台是 F103，五层排查链与 SWJ_CFG、DBGMCU 的结论适用于 F1 全系；F4/F7/H7 的选项字节地址、RDP 取值（0xAA/0xCC）以及 Level 2 不可逆锁死机制与 F1 不同，解锁前务必查对应参考手册，Level 2 一旦写入没有回头路。已知局限是时钟扫描只覆盖了克隆 V2 加 10cm 线这一种组合，官方调试器、更短线缆或板载 SWD 的读者应重新扫描；另外 470nF 复位电容的失败样本只有一次，机制解释基于波形推断而非统计学结论。扩展方向上，建议下一步研究 J-Link 的 RTT 日志在量产测试中的应用，以及用 OpenOCD 脚本固化本文的五层排查流程。

如需获取本文完整代码和更多实战项目，可开通 CSDN 技术会员。

版本备注

• 硬件平台：STM32F103C8T6 最小系统板（HSE 8MHz，Sysclk 72MHz）+ ST-Link V2 克隆调试器（HW V2，固件 V2J43M28）
• 软件版本：Keil MDK 5.38 + STM32CubeProgrammer 2.16.0 + STM32CubeF1 固件库 1.8.5
• 兼容说明：五层排查链、SWJ_CFG、DBGMCU 结论适用于 STM32F1 全系；F4/F7/H7 选项字节地址（0x1FFFC000/0x1FF0EC00 等）、RDP 取值（0xAA/0xCC）与 Level 2 机制不同，解锁流程需按对应参考手册调整
• API 变更风险：HAL_FLASHEx_OBProgram 在 F1 与 F4 HAL 中 OB_RDP_LEVEL_x 枚举含义不同（F1 仅两级，F4 有 Level 0/1/2）；CubeProgrammer 2.17 起选项字节界面菜单位置有调整；Keil Max Clock 字段默认 4000kHz 需手动改小

参考资料

1. STMicroelectronics，《RM0008 Reference Manual: STM32F101/102/103/105/107》— SWJ_CFG、选项字节与 Flash 编程章节
2. STMicroelectronics，《DS5319: STM32F103x8/xB Datasheet》— NRST 电气特性与复位脉宽
3. STM32 SWD下载出现no target connect解决方法
4. 【建议收藏】STM32-STLINK程序下载失败解决方案汇总
5. ST LINK无法下载程序分析
6. 关于用stm32cubeIDE的时候stlink只能下载一次后就失败的解决方法
7. Keil MDK STM32 下载报错 Unknown target connected / Flash Download failed 完整排障方案