文章目录摘要一、问题与排查思路二、SWD 连接握手的底层过程三、挂载方式决策为什么 Under reset 是标配四、分层排查总流程五、故障实测复盘一连接建立层5.1 Unknown target connected——Port 选错5.2 No target connected——接线与供电六、故障实测复盘二SWD 引脚被固件复用七、故障实测复盘三RDP 读保护锁死与选项字节解锁八、量化验证一SWD 时钟频率参数扫描九、量化验证二复位脉宽与挂载成功率十、其余故障速查十一、总结版本备注参考资料摘要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 类故障与第一现场它们的报错入口几乎一样但修复手段完全不同#故障第一现场报错1Port 选错Keil 里保留了默认 JTAGUnknown target connected2接线/供电异常杜邦线接触不良、未共地、VRref 悬空No target connected3固件复用 SWD 引脚第一次能下载之后再也连不上No target connected4RDP 读保护烧过开保护的程序或工具误操作Cannot read memory / 连接后操作全失败5时钟频率过高克隆板 长杜邦线偶发失败校验错误 / No target connected排查思路我总结为五层分层模型从 PC 侧驱动与固件向外推进到物理层接线与供电再进入芯片状态层复位、引脚复用、低功耗最后才是选项字节层RDP。这个顺序的好处是每一步都能用低成本手段验证假设避免一上来就对芯片做破坏性操作。相关阅读《STM32-STLINK程序下载失败解决方案汇总》 — 下载失败常见场景的快速索引可先粗定位再回到本文细查。前置条件与实测环境如下后文所有数据都在这套环境下采集硬件STM32F103C8T6 最小系统板蓝药丸HSE 8MHzSysclk 72MHzST-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半双工工作。调试器与芯片之间的握手是一个多阶段过程每个阶段都有独立的失败窗口这也是同一句报错、不同根因的原因。STM32F103SW-DPST-Link主机STM32F103SW-DPST-Link主机阶段0物理层SWDIO/SWCLK/GND/VDD 就位任一阶段无应答 → No target connectedJTAG-to-SWD 切换序列 0xE79E16bit行复位SWDIO1持续 50 个以上 SWCLK 周期读 DP_IDR地址 0x40x1BA01477Cortex-M3 SW-DP 标识写 DP_CTRL/STAT置 CDBGPWRUPREQ CSYSPWRUPREQCDBGPWRUPACK / CSYSPWRUPACK 回 ACK电源域上电确认SELECT 选 APBANK经 AHB-APCSW/TAR/DRW访问内存空间可读 DBGMCU_IDCODE0xE0042000Flash 操作就绪整个过程有四个关键节点。第一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_IDCODE0xE0042000确认内核身份之后才能执行 Flash 擦写。还有一个容易被忽略的机制用户程序完全可能在复位后几百微秒内就把 PA13/PA14 重新配置成 GPIO。普通连接模式下调试器是在芯片已经跑起用户代码之后才发起握手的一旦 SWD 引脚被固件抢走握手对象就只剩两个被推拉成普通 IO 的引脚——这就是第一次能下载、之后连不上的机制根源后文第六节实测展开。三、挂载方式决策为什么 Under reset 是标配针对用户代码干扰握手的问题CubeProgrammer 和 Keil 都提供了多种挂载方式选型本身就值得分析。我按固件是否复用 SWD 引脚这个最坏场景做了方案对比挂载方式原理引脚被复用场景表现适用性Normal复位释放后直接握手几乎必败用户代码已接管引脚只适合空片或引脚干净的板子Connect under reset先拉低 NRST在复位期间完成握手随后暂停内核复位窗口内引脚保持默认调试态可稳定挂载日常开发默认项BOOT01 进系统 Bootloader走 USART1PA9/PA10串口 ISP与 SWD 无关不受 SWD 引脚状态影响SWD 彻底锁死时的逃生通道我的决策理由有三条。其一under reset 的本质是抢在用户代码运行前把内核暂停——复位期间 SWJ_CFG 处于默认值 000SW-DP 使能PA13/PA14 一定是调试态握手不依赖固件行为这是它可靠性最高的根本原因。其二Normal 模式在干净板子上速度没有优势反而多一个失败窗口统一用 under reset 可以减少心智负担。其三BOOT0 通道要改接线、额外用 USB 转 TTL成本最高只作为最后手段保留。生产环境还要注意一点如果板上 NRST 没有引出到调试座under reset 无从谈起硬件设计阶段就该把 NRST 纳入标准 SWD 接口SWDIO、SWCLK、GND、3.3V、NRST 五线制。相关阅读《stlink 只能下载一次后就失败的解决方法》 — BOOT0/BOOT1 启动模式切换的实操记录与本文第三节的逃生通道呼应。四、分层排查总流程把第一节的五层模型画成流程图排查时从上往下走每层都有明确的判定手段避免遗漏和空转否是否是否是是否RDP ≠ 0xA5RDP 0xA5下载失败/连不上PC 能识别 ST-Link?换 USB 口/换数据线/重装驱动升级调试器固件Keil/CubeProg Port SW?从 JTAG 改为 SWD 模式SWDIO/SWCLK 接线正确且共地?重接: SWDIOPA13, SWCLKPA14确认 3.3V/GND 与 VRrefConnect under reset 可挂载?根因: 固件复用 PA13/PA14检查 SWJ_CFG 配置, 修复代码读选项字节 OBR写回 0xA5 触发全片擦除解锁查供电电压/复位电路/时钟配置/降 SWD 时钟这张图有两个使用要点。第一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 引脚悬空。排查时我用的手段很朴素先目测再测量。万用表蜂鸣档逐线通断确认 SWDIOPA13、SWCLKPA14 没有接反电压档测目标板 VDD 是否在 1.65~3.6V 区间最后测 ST-Link 侧 VRref——这根线把目标板电压回喂给调试器做电平参考悬空时部分克隆板会出现能连上但烧不稳的诡异表现。相关阅读《ST-LINK 无法下载程序分析》 — VRref 输入特性导致下载失败的案例与上文第三种根因同源。三块板子分别用换线、补 GND、接 VRref 解决修复后连续下载 20 次全部成功。这个案例想说明的是No target connected 在物理层的排查成本极低一块万用表两分钟但跳过它直接去折腾软件配置是最常见的浪费。六、故障实测复盘二SWD 引脚被固件复用这是本文信息量最大的一个故障值得单独一节。现象很有迷惑性一块自制的四轴飞控板第一次烧录成功之后无论怎么重插都是 No target connected但 BOOT01 时系统 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 配成了 100SW-DP 一并被关闭。复位释放后用户代码运行到这一行调试端口即告消失——第一次下载能成功是因为当时 Flash 还是空的或旧程序没有这段代码。用逻辑分析仪在 NRST 释放沿后观察 PA14确认它在几毫秒内从调试时钟变成了普通输出电平假设得到验证。根因清楚了修复分两层。代码层必须保留 SWD正确写法是只关 JTAG/** * brief JTAG 引脚释放守卫关 JTAG、留 SWD正确做法 * note AFIO_MAPR.SWJ_CFG[26:24] 010JTAG-DP 关闭、SW-DP 保留。 * 释放 PA15/PB3/PB4PA13(SWDIO)/PA14(SWCLK) 继续归调试端口。 * 绝不要配 100SW-DP 一并关闭否则芯片下载链路锁死。 * warn SWJ_CFG 是只写位读出恒为 0。直接操作寄存器时必须 * 先掩码、后赋值用 | 的读-改-写会把位域写回 000 * 恢复完整 SWJ顺带破坏其他重映射配置的预期。 */voidSWJ_ReleaseJTAG_KeepSWD(void){__HAL_RCC_AFIO_CLK_ENABLE();/* RCC_APB2ENR.AFIOEN1改 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 1AHB-AP 对 Flash 的访问被总线矩阵直接拒绝这解释了连得上但读不了的组合症状。先把 F1 选项字节的机制说清楚。F103 的选项字节位于 0x1FFFF800第一个字节就是 RDP0xA5 表示无保护写入任何其他值都会进入 Level 1Flash 读接口对调试器关闭。写保护 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.OPTWRE1 */{HAL_FLASH_Lock();returnHAL_ERROR;}ob.OptionTypeOPTIONBYTE_RDP;ob.RDPLevelOB_RDP_LEVEL_0;/* 写回 0xA5回到 Level 0无保护 */stHAL_FLASHEx_OBProgram(ob);if(stHAL_OK){/* RDP 变更由硬件自动触发全片擦除并重载选项字节 修改 USER/WRP 等其他选项字节时才需要 HAL_FLASH_OB_Launch() 显式重载 */stHAL_FLASH_OB_Launch();}HAL_FLASH_OB_Lock();HAL_FLASH_Lock();returnst;}实际操作我用 CubeProgrammer 的图形界面完成路径是连接成功后进入 OBOption Bytes页 → Read 确认 RDP 当前值 → 将 RDP 改为 0xA5Level 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 固件 校验统计成功率和平均耗时SWD 时钟成功率20次平均耗时失败表现2400 kHz13/2065%2.1 s3 次连接失败4 次校验错误1800 kHz16/2080%2.3 s4 次连接失败960 kHz20/20100%2.8 s—480 kHz20/20100%3.5 s—100 kHz20/20100%6.9 s—结论很清晰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/PA14SWJ_CFG100每组 20 次挂载方式成功率20次平均挂载耗时备注Normal0/20—用户代码运行即失联Under resetNRST 电容 100nF20/204.1 s推荐配置Under resetNRST 电容 470nF19/204.9 s1 次握手失败重试通过BOOT01 串口 ISP20/209.6 s与 SWD 无关的逃生通道两组数据都对应到理论对照。第一组是复位脉宽数据手册 DS5319 标称 NRST 低电平最小脉宽约 0.1μs而板上 10kΩ 上拉 100nF 电容的 RC 复位实测保持低电平约 1.2ms余量达四个数量级完成 JTAG-to-SWD 切换加 IDCODE 校验在 960kHz 下不足 0.1ms窗口绰绰有余。第二组是那个 470nF 的失败样本τ 提高到约 4.7ms 后NRST 释放沿在阈值附近爬升超过 5msST-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_CR0xE0042004的 DBG_STOP 与 DBG_STANDBY 位置 1CubeMX 对应 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_CFG010关 JTAG 留 SWD绝不配 100SWJ_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 8MHzSysclk 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/2CubeProgrammer 2.17 起选项字节界面菜单位置有调整Keil Max Clock 字段默认 4000kHz 需手动改小参考资料STMicroelectronics《RM0008 Reference Manual: STM32F101/102/103/105/107》— SWJ_CFG、选项字节与 Flash 编程章节STMicroelectronics《DS5319: STM32F103x8/xB Datasheet》— NRST 电气特性与复位脉宽STM32 SWD下载出现no target connect解决方法【建议收藏】STM32-STLINK程序下载失败解决方案汇总ST LINK无法下载程序分析关于用stm32cubeIDE的时候stlink只能下载一次后就失败的解决方法Keil MDK STM32 下载报错 Unknown target connected / Flash Download failed 完整排障方案