扫码关注
下载器一拔，板子怎么就不工作了？
MCU烧录成功，连着ST-LINK调试时LED、串口和外设都正常；拔掉下载器、单独供电后，板子却没反应。不能直接说芯片坏了。调试器可能改变供电、复位和程序执行条件，也可能只是让一个原本存在的问题暂时没有暴露。
连着ST-LINK正常，拔掉就没动静
做STM32或其他MCU小板，常会碰到这种尴尬场景：单步调试没问题，Run起来也能看到LED闪；代码烧进Flash后，把ST-LINK线拔掉，板子却像没有程序一样。重新插回下载器，又能工作。明明软件没有改，怎么结果不一样？
这时候先把“下载成功”和“独立启动成功”分开。下载工具显示烧录完成，说明它完成了某一次写入和校验流程，并不能自动保证板子脱离调试环境后，电源、复位、时钟和应用程序依然满足运行条件。尤其是自己画的最小系统板，不能直接套用开发板经验。
另外也要确认症状到底是哪一种：拔掉整根USB线后就不亮，还是板子独立供电没有问题、只要关闭Debug Session程序就停？前者更容易涉及供电路径，后者则值得关注调试模式、程序行为和启动条件。这两种现象不宜混在一起查。
板子真的还在供电吗？
有些Nucleo开发板本身就能通过ST-LINK的USB接口给目标MCU供电。调试时插着电脑，板上的电源灯、3.3V都正常；把线拔掉，如果没有配置独立电源，目标MCU自然也会停。ST官方用户手册把不同供电入口、选择跳线和限制都写得很清楚。
自己做的板子还可能出现另一种情况：目标板电源设计有问题，调试线上的信号或保护通路意外让某个节点带电。不能把这种“被带起来的电压”当成正规的供电方式。尤其要弄清ST-LINK的VTref在对应探针上是电压检测端还是另有定义，不要凭接口名称就认定它在给目标板供电。
比较简单的办法是在两种状态下都量MCU的VDD、NRST以及外部供电入口。若断开调试器后VDD就消失或明显下跌，那就没有必要先追应用代码。再核对电源选择跳线、LDO输出、公共地，以及独立电源是否真的接到板上。
复位脚一直高，就代表启动正常？
即使VDD稳定，程序也未必能正常进入应用。上电复位波形太慢、外部复位电路被某个接口牵动、启动配置脚状态不符合预期，都可能造成独立运行和连接调试器时表现不同。要看的是上电过程，不只是稳定以后拿万用表量一个高电平。
调试环境可能先把芯片复位、停住，再由工具执行下载或启动；而设备真正独立上电时，外设、电源轨、时钟和MCU会按另一套时序起步。比如外部存储器或电源管理芯片还没准备好，软件就开始访问它，连接下载器时由于启动被拖慢，问题恰好不容易出现。
如果板子复位之后偶尔能跑、完全冷启动时不行，抓一下VDD、NRST与一根能代表程序启动的GPIO波形，通常比反复按下载键更容易区分问题方向。当然，不同MCU的启动脚、时钟配置和复位门槛都要以具体型号手册为准。
程序会不会离不开调试器？
有一种情况是硬件都没有异常，程序却在等待调试环境。常见例子是Semihosting：它允许目标程序通过调试器使用电脑的输出或文件资源。有的工程为了在IDE窗口打印信息，启用了相关库和调用，脱离调试器后却没有处理这些依赖。
ST官方资料说明，Semihosting依赖调试通道；社区里也能看到“Debug正常、单独运行不正常”的讨论。并不是所有printf都会导致这个问题，UART重定向打印和Semihosting是两种不同做法。不要一见到printf就删除，应该检查实际使用的运行库及输出路径。
还有一种差异来自调试器对看门狗、低功耗状态或断点的处理。在调试状态下某些计时可能被暂停，实际脱机运行时却照常计时。程序如果存在初始化超时、长时间等待或异常重启，就可能表现成“下载器一拔就死机”。这些功能是否被暂停，同样取决于芯片和调试配置。
排查时可以先做一个极简的独立运行固件，确认单独供电、复位和GPIO都正常，再逐步恢复外设初始化与日志功能。要是极简程序也不行，就继续查硬件和启动；要是极简程序能跑、原工程不行，范围才真正缩小到软件配置和执行路径。
