1. 从一次“诡异”的IO口失效说起

最近在调试一块基于STM32F103的板子时，遇到了一个让我排查了大半天的“灵异事件”。我的设计里需要用到PA13和PA14这两个引脚来控制两个LED指示灯，原理图检查了好几遍，代码里也正常配置了GPIO输出模式，上电后却发现这两个灯死活不亮。用万用表一量，电压纹丝不动，仿佛这两个引脚“焊死”在了高阻态。起初我怀疑是硬件焊接问题或者芯片损坏，但换了几片芯片、重新焊接后问题依旧。直到我翻开了那份被很多人忽略的芯片数据手册的“引脚定义”章节，才恍然大悟——我踩中了STM32特殊功能引脚复用这个经典大坑。

PA13和PA14，在STM32的世界里，它们默认的身份并非普通的GPIO，而是SWD调试接口的SWDIO和SWCLK信号线。芯片上电复位后，这两个引脚被硬件映射给了调试模块，用于连接ST-Link等调试器。如果你不进行任何特殊处理，就直接把它们当成普通IO口来配置和使用，那么你的代码操作（比如拉高拉低）根本无法作用到实际的引脚电平上，因为它们被“劫持”了。

这个问题绝非个例。除了SWD调试引脚，STM32家族中还有不少引脚身兼数职，比如用作JTAG接口（PA15, PB3, PB4）、BOOT配置引脚（BOOT0, BOOT1）、晶振引脚（OSC_IN/OSC_OUT）、甚至一些电源或模拟功能专用引脚。在资源紧张、需要“榨干”每一个引脚功能的小型项目中，将这些特殊引脚“解放”出来作为普通IO使用，是很多工程师都会面临的需求。然而，这个过程并非简单地调用HAL_GPIO_Init()就能搞定，它涉及到对芯片底层复用功能控制器（AFIO/SYSCFG）的深入理解和正确操作。本文将结合我的踩坑经历，系统性地拆解STM32特殊引脚作为普通IO使用的完整流程、核心原理以及那些手册里不会明说的注意事项，帮你彻底搞懂并安全地使用这些“特殊”的引脚。

2. 识别你的目标：哪些是“特殊”引脚？

在动手之前，第一要务是明确你打算使用的引脚到底“特殊”在哪里。盲目操作可能导致芯片无法调试、无法启动甚至功能异常。我们可以将常见的特殊引脚分为以下几大类：

2.1 调试接口引脚（SWD/JTAG）

这是最常被误用的引脚组。STM32通常支持SWD（2线）和JTAG（5线）两种调试协议。

• SWD引脚:
  • PA13: SWDIO (串行数据输入输出)
  • PA14: SWCLK (串行时钟)
  • 注意: 即使你只使用SWD，这两个引脚在复位后默认也是被调试功能占用的。
• JTAG引脚:
  • PA15: JTDI (JTAG数据输入)
  • PB3: JTDO (JTAG数据输出) / TRACESWO
  • PB4: JNTRST (JTAG复位)
  • PA13: 同上，也属于JTAG的JTMS脚。
  • PA14: 同上，也属于JTAG的JTCK脚。
  • 注意: 在默认的“JTAG+SWD”模式下，PA13, PA14, PA15, PB3, PB4这五个引脚都会被占用。

2.2 启动配置引脚（BOOTx）

这些引脚决定了芯片上电或复位后从哪里开始执行程序。

• BOOT0(以及某些型号的BOOT1): 通常是一个独立的引脚。通过上下拉电阻配置，选择从主Flash、系统存储器（ISP）或SRAM启动。
• 关键点: 一旦芯片正常从Flash启动运行后，理论上你可以将这些引脚重新配置为普通IO。但必须非常小心，因为任何意外的复位或电压波动导致引脚电平变化，都可能改变启动模式，使程序跑飞。一般不建议将BOOT引脚复用为普通IO，除非你的应用对引脚资源极度渴求且能确保启动配置的稳定性。

2.3 外部高速/低速晶振引脚（OSC_IN/OSC_OUT）

• OSC_IN / OSC_OUT: 通常对应PF0/PF1(HSE) 或PC14/PC15(LSE)。
• 关键点: 如果你想使用内部RC振荡器（HSI/LSI）而节省外部晶振，理论上可以释放这些引脚。但操作比调试引脚更复杂，因为涉及到时钟树的配置。你必须在代码中先禁用外部晶振（HSE/LSE），并确保系统时钟源已切换到内部RC，之后才能去配置这些引脚为GPIO。错误操作会导致系统无时钟而死机。

2.4 其他特殊功能引脚

• PC13, PC14, PC15 (RTC引脚): 在部分系列中，这些引脚连接到了RTC的电源域，驱动能力弱，且PC13常作为Tamper引脚。用作普通IO时可能有输出电流限制。
• VBAT引脚: 为RTC和备份寄存器供电，绝对不能作为普通IO使用。
• NRST复位引脚: 这是输入引脚，用于外部复位。绝对不能配置为输出。

> 重要提示：在规划PCB和代码前，务必查阅你所使用型号的《数据手册》(Datasheet)中的“Pinouts and pin descriptions”章节，以及《参考手册》(Reference Manual)中关于“系统配置控制器”和“复用功能”的部分。这是唯一权威的来源。

3. 核心原理：复用功能重映射与调试端口解除

理解了哪些引脚特殊，接下来就要弄明白STM32是如何管理这些引脚功能的。核心在于两个概念：复用功能重映射和调试端口配置。

3.1 复用功能重映射（以定时器、串口等为例）

对于大部分外设（如USART2、TIM2_CH1等），其功能可以映射到多个不同的引脚上。这是通过AFIO（F1系列）或SYSCFG（F4/F7/H7等系列）模块中的重映射寄存器控制的。例如，STM32F103的USART1默认在PA9/PA10，但可以重映射到PB6/PB7。这种重映射是为了PCB布线的灵活性。

3.2 调试端口配置（解决SWD/JTAG占用问题）

调试引脚（PA13, PA14, PA15, PB3, PB4）的占用状态，是通过配置AFIO/SYSCFG模块中的“调试端口复用功能重映射”寄存器来控制的。这个寄存器决定了这些引脚是处于“调试功能”还是“GPIO功能”。

以STM32F1系列（AFIO模块）为例，关键寄存器是AFIO_MAPR(复用重映射和调试I/O配置寄存器)。其中与调试相关的位域是：

• SWJ_CFG[2:0]: 这3位控制着JTAG/SWD的启用状态和引脚释放程度。

常用的配置模式有：

1. 000: JTAG-DP + SW-DP 使能，且全部引脚被占用（PA15, PB3, PB4, PA13, PA14）。这是复位后的默认状态。
2. 001: JTAG-DP禁用，SW-DP使能。此时释放了JTAG专用的PA15, PB3, PB4，它们可以作为普通IO使用，但SWD的PA13和PA14仍被占用。
3. 010: JTAG-DP和SW-DP都禁用。此时释放所有调试引脚（PA15, PB3, PB4, PA13, PA14），它们都可以作为普通IO使用。
4. 100: JTAG-DP禁用，SW-DP使能，并且释放PB4（NJTRST）作为普通IO，其他调试引脚功能不变。

> 核心矛盾与风险：如果你想使用PA13和PA14作为GPIO，就必须选择模式010（禁用所有调试功能）。但这意味着你将无法再通过SWD或JTAG接口对芯片进行在线调试和程序烧录！因为调试器赖以通信的物理引脚已经被你“关掉了”。这是一个不可逆的操作（直到下次系统复位且代码未执行到禁用指令前）。

因此，标准的操作流程必须是：

1. 在还能通过SWD调试的情况下，编写代码，在程序初始化阶段（main函数开头）先解除调试引脚的占用。
2. 将代码编译下载到芯片。
3. 此后，由于调试接口已被禁用，你将无法再次通过SWD连接芯片进行调试或更新程序。
4. 如果后续需要修改程序，你必须通过其他方式（如串口ISP）来擦除整个芯片，恢复默认状态（调试接口使能），才能重新用SWD连接。

对于STM32F4/F7/H7等系列，原理类似，但寄存器换成了SYSCFG->CFGR1等，位域名称可能是SWJ_CFG。

4. 手把手实战：以STM32F103释放PA13/PA14为例

下面我们以最常见的STM32F103C8T6（BluePill板）为例，演示如何将PA13和PA14用作普通GPIO输出控制LED。我们使用HAL库和STM32CubeIDE环境。

4.1 步骤一：CubeMX图形化配置（关键步骤）

很多人喜欢直接写代码，但在这个问题上，使用STM32CubeMX进行可视化配置更安全、更直观。

1. 新建工程，选择你的芯片型号。
2. 引脚分配视图:
   • 找到PA13和PA14。你会发现它们默认显示为SYS_JTMS-SWDIO和SYS_JTCK-SWCLK，并且被锁定了（颜色不同）。
   • 在左侧的System Core->SYS模块下，进行关键配置：
     • Debug: 在下拉菜单中，选择“Serial Wire”。注意，这里不是我们要的最终状态，但先这样选。
     • 更重要的配置在下面：实际上，CubeMX会根据你后续对引脚的功能选择，自动计算并设置AFIO_MAPR寄存器。所以，我们直接去配置引脚功能。
3. 配置PA13和PA14为GPIO_Output:
   • 直接在PA13引脚上点击，选择“GPIO_Output”。此时，CubeMX会弹出一个警告窗口，这是最关键的一步！
   • 警告内容：大致意思是“你正在将一个用于调试的引脚配置为GPIO，这可能导致调试器失去连接。你确定吗？”
   • 选择“Yes”。对PA14进行同样的操作。
4. 观察自动变化:
   • 完成上述操作后，你再回到SYS下的Debug选项。会发现它可能自动变成了“Disable”或者仍然是“Serial Wire”，但旁边有注释。CubeMX已经帮你在生成的代码里写好了禁用调试端口的配置。
5. 生成代码:
   • 配置好时钟树等其他必要选项。
   • 点击“Generate Code”。CubeMX会在main.c的MX_GPIO_Init()函数调用之前，自动插入配置调试端口的代码。

4.2 步骤二：分析生成的代码（理解背后原理）

打开生成的main.c，在main函数中，在MX_GPIO_Init()调用之前，你应该能看到类似这样的代码（具体位置和函数名可能因CubeMX版本略有不同）：

/* 禁用调试端口，释放PA13, PA14, PA15, PB3, PB4 */ __HAL_AFIO_REMAP_SWJ_DISABLE();

跳转到这个宏的定义（通常在stm32f1xx_hal_gpio_ex.h），可以看到它本质上就是操作了AFIO->MAPR寄存器：

#define __HAL_AFIO_REMAP_SWJ_DISABLE() MODIFY_REG(AFIO->MAPR, AFIO_MAPR_SWJ_CFG, AFIO_MAPR_SWJ_CFG_DISABLE)

而AFIO_MAPR_SWJ_CFG_DISABLE的值就是0x00000004，对应SWJ_CFG=010，即完全禁用JTAG和SWD。

> 我的踩坑心得：早期我尝试不通过CubeMX，直接手动在代码里写__HAL_AFIO_REMAP_SWJ_DISABLE()，但有时顺序不对。必须确保在初始化GPIO（HAL_GPIO_Init()）之前，就先执行禁用调试端口的操作。因为GPIO初始化会配置引脚的模式、速度等，如果此时引脚还被调试功能占用，你的GPIO配置可能无法正确写入，或者写入后不生效。CubeMX生成的代码顺序是正确的。

4.3 步骤三：编写应用代码并烧录

1. 在main函数的while(1)循环中，添加你的LED闪烁逻辑：

   while (1) { HAL_GPIO_TogglePin(GPIOA, GPIO_PIN_13 | GPIO_PIN_14); HAL_Delay(500); }

2. 首次烧录与最终警告:
   • 像往常一样，点击CubeIDE的“Debug”或“Run”按钮，通过ST-Link（连接着SWDIO和SWCLK）将程序烧录到芯片中。
   • 程序开始运行，__HAL_AFIO_REMAP_SWJ_DISABLE()立即生效，PA13和PA14被释放，LED开始闪烁。
   • 但是，此时如果你尝试停止调试、再次点击“Debug”，IDE会报错！提示无法连接目标芯片。这是预期行为！因为调试接口已经被你的程序禁用了。
3. 后续编程的解决方案:
   • 方案A（推荐，用于产品阶段）：你的产品程序固化后，本来就不需要调试。如果需要更新程序，使用串口ISP（Boot0拉高，通过USART1烧录）或者DFU等方式。烧录一个不包含禁用调试接口指令的新程序，即可恢复SWD功能。
   • 方案B（开发调试技巧）：在代码中不要立即禁用调试接口，而是通过一个条件编译或者按键触发来执行。例如：

     #define DISABLE_DEBUG 0 // 1-发布版本禁用调试， 0-开发版本保持调试 int main(void) { // ... 初始化代码 #if DISABLE_DEBUG __HAL_AFIO_REMAP_SWJ_DISABLE(); #endif // ... 其他初始化 while(1) { // 或者通过按键来触发禁用 if(HAL_GPIO_ReadPin(KEY_GPIO_Port, KEY_Pin) == GPIO_PIN_RESET) { __HAL_AFIO_REMAP_SWJ_DISABLE(); // 禁用后最好有个指示，比如点亮一个灯 } // ... 主循环代码 } }

     这样，在开发阶段，你可以保持SWD连接进行调试。当需要测试GPIO功能时，再通过按键触发禁用。准备发布时，将宏DISABLE_DEBUG改为1。

5. 其他特殊引脚的处理方法与注意事项

5.1 处理外部晶振引脚（HSE/LSE）

如果你想将OSC_IN/OSC_OUT用作GPIO，流程如下：

1. 在SystemClock_Config()函数中，不要启用HSE或LSE。确保系统时钟源是HSI或MSI（内部RC振荡器）。
2. 在RCC配置中，明确禁用外部晶振。对于HSE：

   __HAL_RCC_HSE_DISABLE(); // 禁用HSE

3. 之后，再像配置普通GPIO一样配置PF0/PF1或PC14/PC15。
4. 特别注意：部分型号的LSE引脚（PC14, PC15）属于备份域，在操作前需要先使能备份域时钟（__HAL_RCC_PWR_CLK_ENABLE();和__HAL_RCC_BKP_CLK_ENABLE();），并取消写保护（HAL_PWR_EnableBkUpAccess();）。操作相对复杂，请严格参考对应型号的参考手册。

5.2 关于BOOT引脚的风险再强调

虽然技术上可行，但强烈不建议将BOOT0/BOOT1用作普通IO，尤其是在电池供电或环境复杂的应用中。一个毛刺导致复位时BOOT0电平变化，就可能让设备无法正常启动，变成“砖头”。如果必须使用，务必在硬件上增加强上拉或下拉电阻，并在软件初始化早期就将其重新配置为输入模式并读取稳定状态，但风险依然存在。

5.3 PC13作为普通输出的限制

PC13常连接板载的LED或用于Tamper功能。用作推挽输出时，其最大输出电流非常小（数据手册标注可能仅几mA）。直接驱动普通LED可能亮度不足或损坏IO口。解决方案是：

• 将其配置为开漏输出，外部接上拉电阻到VDD。
• 或者，仅用作输入或轻负载控制。

6. 调试技巧与问题排查指南

当你按照上述步骤操作后，如果引脚仍然不工作，可以按照以下链路排查：

6.1 确认调试接口是否真正被释放

1. 软件检查：单步调试（在禁用指令执行前），查看AFIO->MAPR寄存器的SWJ_CFG位域值。如果已经是010，说明配置成功。
2. 硬件检查：用示波器或逻辑分析仪测量PA13/PA14引脚。在程序运行后，如果它们不再是周期性的调试信号（上电后SWCLK应有时钟信号），而是跟随你的GPIO操作变化，说明释放成功。如果仍然是调试信号，说明禁用代码未生效。

6.2 排查代码执行顺序

确保禁用调试接口的代码（如__HAL_AFIO_REMAP_SWJ_DISABLE()）在所有GPIO初始化函数（尤其是操作PA13/14的HAL_GPIO_Init()）之前执行。最好的方法就是使用CubeMX生成初始化顺序。

6.3 检查复位后状态

有些工程师喜欢在SystemInit()函数里就进行重映射，但这不一定是最佳位置。确保你的操作在芯片完成基本启动之后。放在main()函数的开头，紧随HAL_Init()之后，是比较稳妥的位置。

6.4 如果芯片“锁死”无法连接SWD怎么办？

这是最常见的后果。解决方法有：

1. 串口ISP：将BOOT0引脚通过电阻拉高到3.3V，复位芯片，芯片会进入系统存储器启动模式。此时通过USART1（PA9/PA10）使用Flash Loader Demonstrator等工具连接，擦除整个芯片。擦除后，调试接口的禁用状态会被清除。
2. 使用NRST复位：在尝试连接SWD的同时，手动触发NRST引脚复位。有时在复位瞬间，调试器能抓住一个短暂的连接窗口并发出擦除命令。可以在CubeIDE的Debug配置中，勾选“Reset and Run”或“Connect under reset”选项尝试。
3. 硬件断电：完全断开芯片电源（包括VBAT），等待几秒后再上电，有时在极上电的瞬间也有连接可能，但概率较低。

> 终极建议：在项目开发板上，为PA13和PA14预留测试点或跳线。即使你在软件中禁用了它们，也可以通过飞线连接调试器。同时，保留一个USART1的串口用于ISP，这是拯救“变砖”芯片最可靠的后路。

将STM32的特殊引脚用作普通IO，是一个在资源与风险之间权衡的过程。它要求开发者不仅会调用库函数，更要理解芯片内部的复用机制和默认状态。通过CubeMX工具可以大幅降低配置难度，但明白其背后的寄存器操作原理，才能在出现问题时有能力排查。记住，动这些引脚之前，永远先看数据手册，并想好退路。