STM32F103芯片没反应？从最小系统到FreeRTOS排查指南

1. 现象描述焊好板子芯片却“装死”先交代一下背景最近在做STM32F103C8T6 FreeRTOS的小项目板子是自己画的最简系统3.3V供电、8MHz晶振、复位电路、BOOT0下拉、SWD下载口。元件到齐后我先焊了两块满怀期待地接上ST-Link结果Keil直接报了No target connected换了另一块还是老样子。折腾了一晚上测电压、量晶振、查复位全都正常最后换了一颗芯片一次点亮。问题就出在那两颗“新”芯片上。这年头买STM32F103尤其是C8T6这种量大管饱的型号踩到翻新片、打磨片、低容量冒充高容量的概率比我以往想的要高得多。市面上所谓“全新原装”的价格从三四块到十几块都有如果只看便宜很容易拿到体质参差不齐的散新片或者翻新片现象千奇百怪有的无法识别、有的能识别但烧不进代码、有的烧进去跑几秒就死、有的温度一高就复位。这篇文章不打算重复手册上的基础电气参数我想从一个实际踩坑者的角度把“芯片没反应”这件事从头到尾捋一遍怎么确认问题、怎么区分电路问题还是芯片问题、怎么识别假芯片、怎么避免在FreeRTOS项目里把软件问题误判成硬件问题。后面还会讲一些跟FreeRTOS移植相关的坑因为很多时候芯片没反应不是芯片死了而是软件卡死在启动阶段表象和坏芯片几乎一样。如果你是刚接触STM32F103的新手或者正准备做FreeRTOS小项目这篇文章应该能帮你在排查时少走弯路。2. 最小系统接线先别怪芯片先检查这几处芯片通电后没反应第一步永远是确认最小系统是否真的“最小”。不要急着怀疑买到假芯片先花十分钟把硬件底子夯实。2.1 电源引脚VDDA和VDD一个都不能落STM32F103内部模拟电路和数字电路分开供电对于LQFP48封装的C8T6VDD引脚24、36、48接3.3VVDDA引脚9也要接3.3VVSSA引脚8接地。很多自画板子只接了VDD漏了VDDA芯片上电后ADC或内部复位电路工作不正常表现出来就是整个芯片不启动或者偶尔能启动、偶尔死机。我测过一块板子VDDA悬空时按下复位键偶尔能跑起来但LED点亮的瞬间电压会掉到2.8V以下然后芯片就死了看起来像是负载能力不足实际上就是VDDA缺电导致的内部LDO工作异常。电容也不能省VDD引脚处至少放一个100nF的陶瓷电容VDDA处最好再并一个1μF以上的电容如果条件允许加一个10Ω电阻隔离一下数字电源的纹波。这些电容的位置要尽量靠近引脚高频退耦才有意义不要图省事放在板子角落。2.2 VCAP引脚容易被忽略的“内部稳压器输出”F103系列有个专门的VCAP引脚LQFP48封装下是引脚47这个引脚是内部1.8V稳压器的输出必须外接一个2.2μF的陶瓷电容到地。这颗电容不能用钽电容或者电解电容凑合ESR特性不对可能导致内部稳压器振荡芯片上电后直接废掉。我第一次画板子就踩过这个坑——VCAP电容用了一个10μF的电解电容结果芯片电流异常大发热严重程序永远跑不起来。后来查了官方勘误手册和数据手册明确建议VCAP接2.2μF陶瓷电容电容耐压6.3V以上即可。这个位置对Layout也有要求走线要短地回路要直接不要绕一圈回到GND。2.3 NRST和BOOT0悬空状态不可靠NRST引脚内部有上拉但不要指望这颗上拉能应付所有场景。如果NRST走线过长或者附近有强干扰源复位脚被拉低导致芯片反复复位在调试器看来就是“连接不上”。我的习惯是NRST接一个100nF电容到地再并联一个10kΩ上拉到3.3V双重保险。BOOT0必须明确接GND或3.3V。F103的BOOT0内部没有上下拉悬空时电平不确定如果恰好被拉高到1.2V以上上电后芯片会进入系统存储器Bootloader模式用户Flash里的程序不会执行。现象就是芯片能被ST-Link识别、能烧录但复位后程序不跑。这个坑和“假芯片”的表现几乎一样容易误判。BOOT1PB2不要强拉保持浮空或通过电阻上拉到GND都行。BOOT1只是在BOOT0为高时参与启动模式选择正常用不到但不建议直接接VCC或GND避免以后需要用串口ISP下载时改线麻烦。2.4 晶振能不能跑不只是起振问题8MHz晶振对F103来说不是必须的内部HSI也能启动但外接晶振配合PLL倍频到72MHz是绝大多数项目的标配。芯片“没反应”时很多人第一反应就是拿示波器去勾晶振引脚结果发现没波形就判断晶振坏了——这里有个误区芯片没正常启动时外部晶振本来就不会起振量不到波形不能反推“晶振坏了”。正确做法是用示波器量OSC_INPD0/PH0取决于封装同时按住复位键再松开看波形是否出现一个从无到有的起振过程。起振后振幅一般在0.5V到3.3V之间如果只有几十毫伏的微弱振荡多半是负载电容选得不对。F103匹配的负载电容一般是10~20pF我用过18pF起振时间大约几百微秒稳定输出没有问题。如果示波器探头带宽不够或者探头电容太大很多10x探头输入电容约15pF会导致晶振停振这也是一个隐性坑。更稳妥的办法是程序上先用内部HSI跑通确认芯片核心逻辑正常后再切外部晶振。3. 识别“假芯片”从外观到内部特征的甄别清单确认最小系统无误、电源稳定、复位正常之后如果芯片还是不响应那就踏入“假芯片排查”的核心地带了。STM32F103的仿冒和翻新问题在业界不是新闻尤其是C8T6这个料号出货量太大导致市场上流通的“渠道货”鱼龙混杂。3.1 外观辨别丝印、封装、引脚光泽先看丝印。原装ST的丝印通常由四行组成第一行是ST的Logo加产品型号比如STM32F103C8T6第二行是封装代码和温度等级如“L QFP48 7”第三行是日期代码如“934”代表2019年第34周第四行是批次号。打磨片或者翻新片的丝印往往只有一行型号没有批次信息或者字体大小不均、深浅不一。用放大镜看翻新片引脚上常有重新镀锡的光泽与本体塑料颜色反差很明显。但这只是初筛现在有些假芯片丝印做得几乎可以乱真所以外观只能作为参考不能作为证据。3.2 内部特征验证RDP、容量ID、UID真正靠谱的手段是直接读芯片内部信息。用ST-Link连接Keil里打开Options - Utilities - Settings在SW Device窗口能看到内核IDCortex-M3默认ID是0x3BA00477如果读出来的ID不是这个基本就是非原装或者非F103。更硬核一点是写一个读取RDPRead Out Protection等级的测试程序。全新原装芯片出厂时RDP等级必然是0Level 0也就是读保护未启用。如果你买到的芯片RDP已经是Level 1说明这颗芯片被擦写过、被烧过读保护大概率是翻新片。要解除Level 1必须全片擦除如果芯片内部代码区有残留内容烧录时可能触发读保护校验不通过导致无法连接。还有一个验证方法是读Flash容量寄存器Base address 0x1FFFF7E0F103C8T6是64KB读出0x40就是正常。有些打磨片用F103C6T632KB冒充C8T6容量寄存器会读出0x20这时候如果按C8T6的Flash大小去烧录代码超过32KB就会烧到不存在的地址表现为“烧录成功但程序跑飞”。UID也是个线索原装F103的UID是96位在0x1FFFF7E8地址读取。同一批次芯片的UID前面几十位相同后几十位各不相同。如果一批芯片UID完全相同或者某位全是FF多半不是原厂流出。注意UID全FF在全新芯片上也可能出现未编程状态但不同于同一批次大量重复。3.3 电气行为温度和功耗会“说实话”翻新片最大的问题不是不能跑而是参数退化。原装F103的静态功耗全外设关闭、72MHz无负载一般在20mA以内翻新片因为内部缺陷电流可能偏高10%甚至更多而且发热部位不均匀。用手摸芯片表面如果发现某一区域明显烫手而负载并不重基本可以断定芯片有问题。另外翻新片对电压纹波的容忍度通常低于原装。原装芯片在3.0V~3.6V都能稳定工作翻新片可能在3.2V以下就不稳定。做交叉验证时不只测芯片供电脚电压还要用示波器看纹波峰峰值。3.3V轨上纹波超过100mV时原装芯片一般还能跑翻新片可能直接复位。3.4 购买渠道与价格底线分享一个我自己的经验STM32F103C8T6的全新原装芯片批量采购的合理价格这几年波动很大但明显低于行情价60%以上的所谓“原装全新”不用看结果直接PASS掉。常见套路是“亲我们的货是原装正品只是没有编带包装散新”散新不能说全部有问题但来路不明的散新片翻新概率极高。优先选择得捷、贸泽、Arrow这些授权分销商量小贵一点但买个放心淘宝/拼多多上买则一定要找支持ST-Link下程序测试的卖家且拆包后尽快测试过了窗口再发现问题就说不清了。我现在手里常备一批“备胎”芯片都是从授权渠道小批量买的出现异常时先换上验证避免把时间浪费在扯皮上。4. 软件层面FreeRTOS项目“没反应”的隐性原因芯片本身没问题ST-Link也能连上但烧完FreeRTOS固件后复位没反应这个现象在初学者项目里非常常见。很多时候不是芯片坏了而是移植配置出了问题导致系统卡死在启动早期。下面几个坑我按出现频率从高到低排一下。4.1 SysTick被FreeRTOS接管后的冲突FreeRTOS运行的前提是系统滴答SysTick归它管理所以FreeRTOS移植完成后你不能再在裸机代码里用SysTick做延时否则节拍计数错乱任务调度直接崩。典型现象代码里调用了HAL_Delay()或者delay_ms()基于SysTick的裸机延时实现然后创建了几个任务启动调度器后一个任务都不跑或者跑了几个毫秒就HardFault。解决办法是所有延时统一用vTaskDelay()或vTaskDelayUntil()裸机版本的延时函数全部替换。如果确实需要阻塞式短延时用DWT计数器或者定时器外设自己实现不要碰SysTick。还有一个容易忽略的点FreeRTOS要求SysTick中断优先级设为最低数值最大PendSV和SVCall优先级也必须是最低优先级。在NVIC中F103的优先级分组建议设为NVIC_PriorityGroup_44位抢占优先级无子优先级然后将PendSV和SVCall设为15SysTick设为15。配置方法NVIC_SetPriorityGrouping(NVIC_PriorityGroup_4); NVIC_SetPriority(SysTick_IRQn, 15); NVIC_SetPriority(PendSV_IRQn, 15); NVIC_SetPriority(SVCall_IRQn, 15);注意FreeRTOS官方推荐所有ISR中调用的API中断优先级不高于configMAX_SYSCALL_INTERRUPT_PRIORITY在F103上通常设为5也就是抢占优先级数值≥5的中断才能调用FromISR结尾的API。如果设置反了中断一进来调用API直接assert失败。4.2 堆栈大小和堆大小不足FreeRTOS每个任务都有独立的栈空间默认大小经常不够用。F103的RAM只有20KBC8T6如果创建多个任务每个任务栈给512字2KB光任务栈就吃掉8KB以上再加上FreeRTOS内核自己的堆heap内存很容易爆。爆内存的表现不一定立刻死机可能是任务创建失败xTaskCreate返回pdFAIL、任务调度后跑一会儿HardFault、或者看起来“芯片没反应”。我的建议是先用最简单的最小工程验证启动只创建两个任务每个任务栈128字一个任务控制LED翻转另一个任务什么都不干只延时。跑通之后再加任务、加栈。排查时打开FreeRTOS的栈溢出检测// FreeRTOSConfig.h 中配置 #define configCHECK_FOR_STACK_OVERFLOW 2 #define configUSE_MALLOC_FAILED_HOOK 1配置为2时内核会在任务切换时检测栈顶的“canary”值是否被破坏如果破坏会调用vApplicationStackOverflowHook。实现这个钩子函数在里面对GPIO置位或者点亮LED就能快速定位哪个任务栈溢出。Heap大小在FreeRTOSConfig.h里的configTOTAL_HEAP_SIZE定义。C8T6建议从8 * 1024开始如果heap够用则不必加大如果任务创建频繁失败优先削减任务栈而不是加大堆。4.3 启动文件与链接脚本不匹配又是一个容易被忽略但是后果惨烈的坑Keil工程的Device型号选错导致链接脚本按错误的内存布局分配地址。很多人在Keil里新建工程时图省事随便选了个STM32F103RB128KB Flash20KB RAM实际上芯片是C8T664KB Flash20KB RAM链接脚本会按128KB Flash分配代码超过64KB后烧录到不存在的地址启动时直接取指失败进HardFault。正确做法是在Keil的Options - Device里明确选择STM32F103C8确保Target页的IROM1地址是0x08000000、大小为0x1000064KBIRAM1地址0x20000000、大小为0x500020KB。如果用Cubemx生成工程也要在Project Manager里确认MCU型号没选错。检查Map文件能快速确认链接结果编译后在Listings目录下打开.map文件查看Memory Map of the image部分确认代码段落在0x08000000~0x0800FFFF范围内。如果地址超出Map文件会出现“ER_IROM1”溢出警告但很多人没注意。4.4 下载配置和复位配置导致的“假死”Keil里常见的一个奇怪现象烧录成功但按复位键后程序不运行点击全速运行后又能跑。这个问题多半出在Debug设置里。Options - Debug - Settings - Flash Download页确认勾选了Reset and Run否则烧录后芯片停留在复位状态必须手动复位。更隐蔽的问题在Utilities页的Settings里Reset选项选成了Hardware Reset还是Software Reset。有些ST-Link的固件版本对F103的硬件复位引脚时序处理不好Hardware Reset模式下烧录完成后的复位动作不完整导致程序没从正确状态启动。我一般改成Software Reset实测稳定很多。如果你用的下载器是J-Link还要注意J-Link的SWD接口速率。速率过高时连接不稳定表现为有时候能识别芯片有时候“No target connected”尤其在你加了防静电电容或者隔离电路后更明显。把SWD速率降到1MHz以内连接成功率会高很多。ST-Link默认速率一般是4MHz如果线缆长了或者用了杜邦线也建议主动降速。5. 实操排查流程从硬件到软件5分钟定位问题上面几节讲了各自独立的坑但真遇到问题时不可能一次性把所有点都过一遍。下面给出我实际使用的排查顺序照着走一遍大多数“没反应”问题都能定位。5.1 Step 1确认芯片最基本供电拿万用表量芯片的VDD和VDDA引脚确认是3.3V左右。再量VCAP正常应该在1.8V左右F103内部1.8V稳压器输出。VCAP电压不正常的话芯片内部逻辑电路没电其他都不用看了。如果你量的VCAP是0V或者接近VDD说明芯片内部稳压器没工作要么是芯片坏了要么是VCAP电容不对导致振荡。5.2 Step 2最小系统“空跑”测试不烧任何程序用示波器量NRST确认复位脚在松开复位按键后能从0V升到3.3V。再量外部晶振如果是8MHz晶振且芯片正常启动OSC_IN/OSC_OUT引脚上应有正弦波或方波。如果没有波形不要先怀疑晶振先检查电源和VCAP。如果一切正常还是不起振可以试试直接烧录一个最简单的GPIO翻转程序用内部HSI不依赖外部晶振。能跑起来就说明问题是外部晶振相关的跑不起来继续往下查。5.3 Step 3检查下载器连接用ST-Link连接SWDIO和SWCLKGND和3.3V也接上。在Keil的Options - Debug - Settings里点“Scan”按钮看是否识别到SW Device。如果识别到了看ID Code的值是不是0x3BA00477。不是的话芯片内核ID不对基本可以断定芯片是假的或者损坏。5.4 Step 4擦除并烧录验证程序烧录前先做一次“Erase Full Chip”把芯片恢复出厂状态。烧录一个最简单的程序——例如用标准库点亮LED不加FreeRTOS。这个程序如果在裸机状态下能跑说明芯片基本没问题。再烧录一个包含任务创建的FreeRTOS最小工程任务0翻转LED任务1空转。如果裸机能跑、FreeRTOS跑不起来按照4.1到4.3的顺序检查配置。5.5 Step 5RDP和UID验证到了这一步还没定位问题就值得做一次彻底的芯片身份验证。写一个测试程序读取下面三个地址的值通过串口输出// Flash size register, 0x1FFFF7E0, read as uint16_t uint16_t flash_size *(volatile uint16_t *)0x1FFFF7E0; // UID, 0x1FFFF7E8, 96-bit uint32_t uid0 *(volatile uint32_t *)0x1FFFF7E8; uint32_t uid1 *(volatile uint32_t *)0x1FFFF7EC; uint32_t uid2 *(volatile uint32_t *)0x1FFFF7F0;同时用ST-Link Utility或者STM32CubeProgrammer读取RDP等级。如果RDP1或者Flash容量不是0x40UID读取异常直接换芯片。5.6 Step 6换一颗芯片交叉验证最后也是最决定性的一招换一颗确认来源的芯片。手头上常备一两颗从授权渠道买的芯片遇到可疑情况直接换上如果换上后所有测试顺利通过那原来的芯片基本可以判定有问题。这个方法简单粗暴但效率极高比用示波器慢慢排查快得多。6. 常见问题速查表现象、原因与解决方案现象可能原因排查方案完全无法连接No target detectedVDD/VDDA缺电、SWDIO/SWCLK接反或虚焊、芯片损坏量电源量VCAP重新焊接SWD更换芯片能识别芯片但烧录时报Flash校验错误Flash容量型号选错、芯片Flash损坏、RDP等级为1检查Keil Device型号、读取容量寄存器、解除读保护烧录成功按复位无反应硬件复位时序问题、BOOT0悬空导致进入BootloaderKeil Download页勾选Reset and RunBOOT0明确下拉接地裸机程序正常FreeRTOS任务不执行SysTick冲突、PendSV/SVCall优先级过高、任务栈溢出检查优先级别设置、打开栈溢出检测、减少任务栈大小烧录后跑一会儿就死机/复位堆栈溢出、任务栈溢出、看门狗未喂、电源纹波大打开FreeRTOS溢出检测、减小任务栈加入堆余量、优化电源滤波外接晶振不起振内部HSI能跑晶振虚焊、负载电容不匹配、探头电容过大用10x探头并检查负载电容、先切HSI跑通芯片发热严重电源接反、VCAP电容类型错误、芯片内部短路立即断电检查电源极性VCAP换2.2μF陶瓷电容多块芯片同一批次均有问题买到了翻新片/打磨片读取RDP状态、UID重复情况更换采购渠道这张表建议收藏碰到类似问题时对照排查比自己一个个试快得多。7. FreeRTOS移植时的几个额外提醒最后补充几个我在FreeRTOS实际项目中踩过的、跟“芯片没反应”表象相关的点。它们不是硬件问题但很容易迷惑人。7.1 串口重定向printf导致卡死很多人习惯在FreeRTOS任务里用printf来打印调试信息但如果串口驱动基于轮询阻塞式发送且没有加互斥锁多个任务同时printf时数据会交错。更严重的情况是如果开启了系统节拍中断而printf的阻塞时间过长超过了一个系统节拍周期内核会认为当前任务让出了CPU调度器切入其他任务这时另一个任务再次printf两者冲突程序进入死锁状态。解决方法是给串口发送加上互斥量Mutex或者用DMA发送队列。如果只是想临时调试可以只在单个任务里加一个vTaskDelay(1)再printf避免并发冲突。我用过一个比较省事的方案单独创建一个“日志任务”其他任务把字符串塞进队列日志任务负责串口输出这样不乱串也不会堵塞其他任务。7.2 中断里调用非FromISR的API这是新手经常踩的坑。形如vTaskDelay、xQueueSend非FromISR版本在中断上下文会被configASSERT拦住如果assert钩子没有实现或者实现里只是空循环表象就是中断一触发整个系统就像死了一样。如果你用了外部中断、定时器中断、串口中断来唤醒任务一定要检查中断服务函数里调用的API是不是带FromISR后缀。7.3 Keil编译器版本带来的兼容性问题热词里提到“Keil如何使用6版本编译器”这里多说一句AC6ARM Compiler 6对代码标准要求更高很多基于AC5语法写的裸机代码比如隐式声明、register关键字、可重入函数声明遗漏在AC6下会直接编译失败或者优化后行为异常。有时候你编译通过但F103跑起来没反应可能不是芯片问题而是编译器版本不同导致的代码语义变化。如果基于标准库v3.5的老工程我建议暂时用AC5v5.06直到确认所有警告清零、行为正常后再切AC6。AC6下优化等级开到-O2时未初始化的局部变量可能导致不可预期行为排查这类问题很痛苦。7.4 用Map文件确认代码段和RAM用量Map文件是排查软件问题的重要手段。当程序跑不起来时打开.map文件看两处一是Memory Map中ER_IROM1和RW_IRAM1的起始结束地址确认没有超出芯片实际资源二是Startup部分确认Reset_Handler被编译进了镜像。如果Reset_Handler被链接器丢弃可能因为中断向量表配置错误程序上电后直接跑飞表现和芯片损坏一模一样。8. 说句心里话做嵌入式这么多年我越来越觉得“芯片没反应”这类问题的排查拼的不是某一招鲜的技巧而是按部就班的耐心。买芯片多花几块钱、多验证一轮、多留一颗备胎排查效率会高很多。最近这波ST芯片渠道混乱假芯片和翻新片防不胜防。我的选择是如果项目对可靠性要求高直接在授权渠道采购别贪那几块钱的便宜如果只是学习验证用也要买“支持烧录测试”的货而且到货后第一时间做RDP和UID验证。真遇到“芯片没反应”的时候先默念三遍电源、复位、时钟。三板斧查完再看芯片真伪。很多时候你以为买到了假芯片结果最后发现是自己VCAP电容贴错了。FreeRTOS项目的“没反应”还可能是软件配置问题建议先裸机验证、再最小RTOS验证、再逐渐加功能一步步缩小范围。希望这篇文章能帮你省下几个加班的晚上。