AT32F4xx调试引脚复用：JTAG/SWD被占用如何排查与恢复

做嵌入式开发这些年，AT32F4xx系列用得越来越多，但这个系列有个特别容易让新手栽跟头的点——GPIO复用，尤其是JTAG/SWD引脚。很多人辛辛苦苦把板子画好、程序写出来，结果上电后调试器死活连不上，弹出的报错要么是“Could not stop Cortex-M device! Please check the JTAG cable.”，要么是“SWD/JTAG Communication Failure”，排查半天最后发现是GPIO配置把调试引脚给“抢”走了。今天我不打算照着手册念一遍 API，而是围绕AT32F4xx的实际工程经验，把调试端口的引脚定义、复用原理、配置时机、恢复手段一次讲透，顺便把GD32、STM32以及Zynq这类平台上容易混淆的JTAG用法也捋清楚。

1. 先说结论：AT32F4xx的调试引脚到底是不是被“白嫖”了

1.1 引脚表里看到的不是全部

AT32F4xx的数据手册里，PA13、PA14、PA15、PB3、PB4这几个引脚看起来都非常正常，旁边写着一堆复用功能，比如SPI、TIM、UART等等。很多人的第一反应是：既然能复用，那我直接在GPIO配置里把这些脚配成输出总行了吧？结果通电一看，电平纹丝不动，或者调试器直接失联。

问题的关键在于，你在引脚表上看到的“AF功能列表”并不是全部真相。这三个引脚在芯片内部还有一个更高优先级的身份——JTAG/SWD调试引脚。默认情况下，调试外设的优先级比普通GPIO复用更高。换句话说，复位之后这几个引脚属于调试器，不属于你的应用代码。除非你在程序里显式地修改调试端口配置，否则无论怎么操作GPIO寄存器，这几个脚都不会按你的想法输出。

这里有一个经验之谈：凡是涉及到“默认复用”的引脚，一定要去参考手册里查它最原始的输入输出状态，而不仅仅是数据手册的引脚定义表。AT32F4xx的参考手册里会有一张JTAG/SWD复用表，它才是排查这类问题的第一依据。

1.2 默认状态下，这几个引脚究竟属于谁

以AT32F4xx为例，调试接口的默认映射关系大概是这样的：

这些引脚在系统复位后默认被调试模块接管。如果你只是想用SWD两线调试，那PA13和PA14必须保留；PA15、PB3、PB4则可以通过“关闭JTAG、保留SWD”的方式释放出来。如果你连SWD都不用了，五个引脚全部可以释放，但代价是下次没法通过常规调试口下载程序。

很多人在这一步犯的错误是：用SWD调试器下载程序，却只关了SWD，保留了JTAG，导致PA15或PB3仍然不能作为普通IO使用。反过来，也有人为了释放全部引脚，把SWD也关了，结果程序一烧进去，调试器再也连不上，最后只能拆板子走ISP恢复。

1.3 “关闭JTAG”和“关闭SWD”是两个不同的动作

“关闭JTAG”不等于“关闭所有调试功能”，更不等于“所有调试引脚都能当GPIO用”。在AT32F4xx里，调试端口配置一般是靠SYSCFG（系统配置控制器）里的SWJ_CFG字段控制的，而这个字段通常支持几种模式：

• 默认模式：JTAG和SWD都使能，PA13/PA14/PA15/PB3/PB4全部被调试功能占用。
• 关闭JTAG、保留SWD：PA15/PB3/PB4可以释放，PA13/PA14继续作为SWD调试引脚。
• 完全禁用调试端口：PA13/PA14也释放，整个调试接口不再工作。

具体宏定义和寄存器位因芯片型号而略有差异，但概念完全一致。我在多个AT32F4xx项目里都建议“非必要不关闭SWD”，因为调试口一旦全关，后续排查问题会非常痛苦。

2. 重新认识JTAG/SWD：引脚定义、协议与时序的底层逻辑

2.1 JTAG五线接口和SWD两线接口的区别

JTAG是IEEE 1149.1标准定义的边界扫描测试接口，通常包含TCK、TMS、TDI、TDO四根信号线，外加可选的nTRST复位线。SWD是ARM针对Cortex-M系列定义的一种串行调试接口，只需要SWDIO和SWCLK两根线。SWD的引脚少、占用资源少，所以现代MCU调试基本都默认走SWD，JTAG只是兼容旧调试器和高端调试场景时才会用到。

在AT32F4xx上，PA13同时承担SWDIO和JTMS，PA14同时承担SWCLK和JTCK，PA15是JTDI，PB3是JTDO/TRACESWO，PB4是NJTRST。这就解释了为什么“关闭JTAG”这条命令只释放了PA15、PB3、PB4，而PA13和PA14还留在调试器手里——因为SWD还需要它们。如果你连SWDIO、SWCLK都释放了，调试器就彻底没办法跟芯片通信了。

2.2 从协议和时序看懂“为什么不能随便复用”

调试器连接一颗Cortex-M4芯片的过程，大致是：上电复位后先让目标进入调试状态，再发送JTAG或SWD的切换序列，读取IDCODE，然后才能读写内存、设置断点、下载程序。这一整个过程都是靠调试引脚上的特定时序来完成的。

如果这时你把PA15配置成了普通GPIO输出，并且往里面推了一个高电平，那么调试器想发JTAG数据时，这个引脚的电平就不是由调试器控制的，而是被你的GPIO输出顶住了。轻则握手失败，重则直接把调试器挂死，出现“Could not stop Cortex-M device”这类报错。

我用一个生活类比来解释：调试接口就像你家门口的门铃。GPIO复位配置就像把门铃按钮旁边贴了个盖板，快递员到了按不响门铃，自然没法通知你取件。更麻烦的是，你自己也进不去门了，除非找到备用钥匙。这颗芯片的备用钥匙就是ISP引导程序或“连接时复位”模式。

2.3 常见报错的硬件/软件原因

• “Could not stop Cortex-M device! Please check the JTAG cable.”：这是J-Link常见的报错，说明调试器已经识别到芯片，但在“停止内核”这一步失败了。90%的原因是目标内核没有正常进入调试状态，背后可能是时钟没配好、引脚被复用成GPIO、或者复位电路有问题。
• “SWD/JTAG Communication Failure”：IAR、Keil等IDE里很常见的报错，通常发生在连接阶段。硬件接线、供电、调试速率、上一次烧录的程序禁用调试口，都可能触发。
• “RDDI-DAP Error”：CMSIS-DAP调试器常见报错，PA13/PA14电平被外部电路拉死或程序里关闭了调试端口是主要原因。
• “Flash Download failed - Cortex-M4”：下载算法、Flash型号、链接脚本的问题，但有时候也是因为调试口不稳定导致握手失败。

软件层面的第一嫌疑永远是：程序初始化里是否动了调试端口配置。硬件层面则要检查接线、供电、复位电路以及调试时钟频率。

3. 实操：AT32F4xx上如何安全地释放调试引脚

3.1 环境准备与工程配置

我以AT32F403A/AT32F4xx系列为例，上手前先准备好三样东西：

• 一块AT32F4xx开发板或自研板子，确认PA13/PA14附近有SWD调试排针。
• 一个支持SWD的调试器，常见的是DAP-Link、J-Link、ST-Link。
• 一套完整的AT32标准外设库，建议从官网或GitHub下载最新版，不要用网上乱转的旧工程。

打开Keil或IAR之后，先不要急着写GPIO代码，把调试器设置选成SWD模式，然后把下载速度先降到1MHz左右。很多连接失败是调试线太长或者环境干扰导致的，1MHz跑通之后再逐步提高速度，省得后面越改越乱。

3.2 代码实现：关闭JTAG、保留SWD

假设你只想释放PA15、PB3、PB4，同时继续用SWD调试PA13和PA14，这是最推荐的方案。初始化顺序必须在所有GPIO配置之前完成，最好放在main函数最开始的位置。

下面是AT32F4xx标准外设库风格的一段示例，函数名因库版本略有差异，但思路是通用的：

#include "at32f4xx.h" int main(void) { // 开启SYSCFG时钟，GPIO配置也依赖它 RCC_APB2PeriphClockCmd(RCC_APB2Periph_SYSCFG, ENABLE); // 关闭JTAG-DP，保留SW-DP GPIO_PinRemapConfig(GPIO_Remap_SWJ_JTAGDisable, ENABLE); // 之后PA15、PB3、PB4可以正常配置为GPIO RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_GPIOA | RCC_AHB1Periph_GPIOB, ENABLE); GPIO_InitTypeDef gpio; GPIO_StructInit(&gpio); gpio.GPIO_Pin = GPIO_Pin_15; gpio.GPIO_Mode = GPIO_Mode_OUT; gpio.GPIO_OType = GPIO_OType_PP; gpio.GPIO_Speed = GPIO_Speed_2MHz; GPIO_Init(GPIOA, &gpio); GPIO_SetBits(GPIOA, GPIO_Pin_15); while(1) { } }

如果你使用的库函数名称不一样，比如没有GPIO_PinRemapConfig，就去找芯片头文件里跟“SWJ”相关的宏和SYSCFG寄存器。用寄存器方式也完全可以：

SYSCFG->CFGR1 &= ~SYSCFG_CFGR1_SWJ_CFG; SYSCFG->CFGR1 |= SYSCFG_CFGR1_SWJ_CFG_JTAGDIS; // 实际宏名以头文件为准

这里最关键的是：哪怕你后面根本不用JTAG，只要你继续想用SWD，就千万不要把这个字段配成完全禁用模式。很多工程师调完程序后忘了改这里，结果过几天要升级固件时，调试器连不上，只能干瞪眼。

3.3 代码实现：完全禁用调试端口

只有在你确定产品已经量产、再也不想通过SWD/JTAG联调时，才建议完全禁用调试端口。代码写法跟上面类似，只是把参数换成完全禁用SWJ，常见写法是：

GPIO_PinRemapConfig(GPIO_Remap_SWJ_Disable, ENABLE);

一旦烧进这个固件，PA13和PA14也会被释放成普通IO，调试器在下一次上电后将无法识别芯片。这个时候要恢复，只有几种办法：

• 把BOOT0引脚拉高，让芯片进入ISP引导模式，通过串口或DFU擦除整片Flash。
• 使用支持“Connect under Reset”的调试器，在目标复位期间抢时间去连接。
• 如果板子上留了一根复位线引出，且调试器支持高低电平触发复位连接，还可以反复试。

我在自研板子上吃过一次亏。当时为了多控一个LED，把PA13和PA14都当成GPIO用了，代码一烧进去，接着要调下一个功能就彻底连不上。最后只能焊了一根线到BOOT0，再用串口ISP擦除。从那以后我给自己定了一条规矩：产品设计时一定要预留ISP恢复通道，否则不要在早期开发阶段完全禁用SWD。

3.4 验证与回退方案

配置写完之后，怎么判断到底有没有成功释放引脚？最直接的办法是写一段最简单的GPIO翻转代码，比如让PA15输出一个方波，然后用万用表或示波器看电平变化。如果PA15能正常翻转，说明JTAG已经关闭、该引脚已经释放成功。

同时，验证SWD是否仍然可用。烧录后重启板子，在IDE里重新连接调试器，如果能正常识别芯片型号并读取到IDCODE，说明PA13/PA14仍然承担着SWD调试功能。如果连接失败，优先检查SWJ_CFG寄存器值是否被意外改成了完全禁用。

我个人的习惯是：每次烧录新的固件，都在调试器设置里启用“Reset and Run”，同时把连接失败自动重试次数调大一点。这样即便引脚配置有误，调试器通常也能在一次复位窗口里抢到连接机会，不至于一失败就彻底锁死。

4. 常见问题与排查技巧实录

4.1 “Could not stop Cortex-M device!”怎么破

这个报错我在AT32F4xx和STM32F4xx上都遇到过，处理思路基本一致。先在硬件上过一遍：SWDIO、SWCLK、GND三根线是否真的接触良好，杜邦线是否太长，目标板供电是否稳定。然后打开调试器设置，把连接速度从默认速率降到1MHz，很多诡异问题都是因为线材在高速下不稳定。

如果降速没用，就检查代码。回忆一下上一次烧录的程序里有没有调用过类似GPIO_Remap_SWJ_Disable的接口。如果有，那这颗芯片现在很可能已经处于半锁死状态。尝试“Connect under Reset”：调试器在目标复位期间持续尝试握手，因为刚上电时SWJ功能还是默认使能的，有机会抓住那一小段时间。

还有一个容易忽略的点：外部电路把SWDIO或SWCLK钳位在了错误电平。比如PA14上接了去耦电容到地，导致上升沿太慢，调试器无法正常采样；再比如PA13挂了上拉电阻，上拉阻值太强也会影响通信质量。这种情况硬件上可以加串阻，或者把调试速度降得更低。

4.2 排查流程速查表

这个表格值得收藏。很多问题不是“换根线”那么简单，但大多数情况下，照着这个顺序排查，半小时内基本能定位到原因。

4.3 几个非常容易忽略的坑

第一个坑是PA13和PA14上外接负载。有些开发板为了省事，把PA13和PA14同时接到了按键或LED上，按键接地、LED对地有几百欧电阻，这种电路在低频调试时可能还能用，但在高频SWD下就会拉低信号、拉高上升沿，出现间歇性连接失败。

第二个坑是初始化顺序。有人把GPIO_PinRemapConfig放在了GPIO_Init之后，结果PA15已经被初始化成GPIO输出，电平直接顶住JTAG信号，等到执行关闭JTAG的代码时，硬件层面已经乱了。正确顺序一定是在所有GPIO配置之前修改调试端口字段，最好紧跟系统时钟初始化。

第三个坑是低功耗模式。如果程序进过STOP或STANDBY模式，且没有开启调试唤醒功能，内核可能会自动关闭调试端口。用SWD调试低功耗项目时，要么在调试时屏蔽低功耗代码，要么开启调试器相关的DBGMCU时钟，让内核在调试模式下保持运行。

第四个坑是Bootloader和App的配置不一致。Bootloader里如果没有关闭JTAG、但App里关了，跳转后调试器会直接断开。反过来也一样，看起来像是程序跑飞了，实际上只是调试接口被重新配置了。排查这类问题可以先用Bootloader里单独跑一个空循环，看调试器是否稳定，再决定是否怀疑App代码。

5. 经验迁移：STM32F4、GD32F4与FPGA平台的差异

5.1 STM32F4和GD32F4上的同款配置

AT32F4xx在GPIO复用思路上和STM32F4非常接近，因为大家都基于ARM Cortex-M内核，调试端口映射也沿用ARM标准。在STM32F4上，同样通过SYSCFG->CFGR1里的SWJ_CFG字段控制调试接口，很多老代码里能看到这样的写法：

GPIO_PinRemapConfig(GPIO_Remap_SWJ_Disable, ENABLE);

STM32F4的HAL库没有直接把“禁用SWJ”暴露成一个简单的GPIO配置函数，不少工程师在SystemInit之后直接操作寄存器。GD32F4的库函数命名通常是gpio_pin_remap_config(GPIO_SWJ_DISABLE, ENABLE)，但概念一模一样。

所以以后遇到GD32或STM32F4出现同样问题时，不要把AT32的代码直接编译进去，但要明白它们改的是同一个底层寄存器字段。跨平台迁移时，最稳妥的做法是打开目标芯片的参考手册，找到SWJ_CFG字段，然后照着寄存器位配置。

5.2 Zynq这类FPGA/SoC里JTAG的正常打开方式

网络上经常能看到“Zynq 7020使用JTAG固化Flash时必须使用DDR吗”之类的问题。这里要提醒一下，Zynq是FPGA/SoC，和AT32F4xx这类MCU完全是两回事。Zynq的JTAG既用于FPGA配置，也用于ARM调试和Flash固化，它的JTAG接口在PS和PL之间有不同的工作模式。

在Zynq上如果用JTAG固化QSPI Flash，目标文件通常是BOOT.bin或固化镜像，是否必须用DDR取决于你的方案设计：如果FSBL和BITSTREAM需要暂存在DDR里再写Flash，那DDR就必须初始化；如果是直接把镜像从JTAG端推到QSPI控制器，不经过DDR，那可以不用DDR。这不是GPIO复用的坑，而是系统链路设计的问题。

之所以把这两个场景放在一起说，是因为很多做MCU转FPGA的开发者会把“JTAG引脚被复用”的经验硬套到Zynq上，结果越查越偏。遇到不同平台时，先分辨清楚这个“JTAG”到底承担的是调试链路还是配置链路，再去看对应手册。

5.3 跨平台调试的经验总结

跨平台的经验浓缩成一句话：凡是涉及调试端口的复用，优先级永远高于普通外设，必须在一开始就规划好恢复方案。在MCU平台上是改SWJ_CFG字段，在FPGA平台上是查看配置链路是否绕过DDR，原理不同，但“先保护好调试入口”的思路是一致的。

做产品设计时，我会在原理图上把调试引脚单独拉一排排针，并且不接任何大负载器件。如果必须复用，宁可多引一根BOOT跳线帽，也要给自己留一条后路。这个习惯帮我无数次从“连不上”的恐慌里快速跳出来。

6. 我最后想补充的几点经验

在AT32F4xx上折腾GPIO复用多了，最大的感受是：很多时候不是技术难度高，而是没有把配置顺序和恢复路径想清楚。我现在写项目，几乎是条件反射般地遵守几条规矩：

第一，开项目第一步先在调试器里确认SWD能连接，再写任何应用代码。这个确认动作每次只花十秒钟，但能避免把硬件问题混进软件问题里。第二，第一次调试时永远只关闭JTAG、保留SWD，直到所有联调工作基本结束，才考虑是否完全关闭调试口。第三，每次烧录之后，如果长时间没有交互，芯片进入低功耗前要调试模式相关寄存器做一次备份，方便后面恢复。

还有一个小技巧：如果你手头的J-Link或DAP-Link支持“Connect under Reset”，遇到引脚被复用导致的连接失败，先把调试速度降到最低，再勾选“复位连接”选项，往往能抢在程序启动前掌握芯片。这个方法很老套，但真的能救命。

最后再分享一个很多人不知道的细节：在AT32F4xx参考手册里，SWJ_CFG字段的修改并不是瞬间完成的，建议修改后加几个空指令延时，再进行GPIO初始化。不要太依赖编译器优化，因为一旦优化过度，寄存器写入和GPIO配置之间距离过近，某些芯片内部可能还没来得及真正完成调试端口切换，就出现了偶发性的配置失败。加百来个NOP或者一个短延时，成本可以忽略不计，但能省掉很多“莫名其妙”的调试器失联问题。