STM32F103 FreeRTOS芯片没反应你可能买到“假芯片”了前阵子调试一块STM32F103C8T6的最小系统板现象很诡异J-Link能连上芯片ID能读到程序下载也提示成功可FreeRTOS任务就是跑不起来——点灯任务没反应串口打印一个字符都不出。起初我以为是优先级配置写崩了、堆栈开小了或者时钟初始化有问题前前后后折腾了两天代码翻来覆去改了好几版。后来实在没辙把芯片拆下来换了一片同一个工程直接跑起来了。问题不在代码在这颗芯片本身——严格来说是假芯片。这个经历让我意识到很多人遇到STM32F103没反应的第一反应是查代码、查配置、查焊接唯独没有怀疑芯片本身。但在ST官方2022年就宣布STM32F103系列进入不推荐用于新设计的状态之后市面上这颗芯片的翻新片、打磨片、国产替代片鱼龙混杂芯片本身出问题的概率比很多人想象得高得多。这篇文章就以我自己的实际排查过程为主线把假芯片的特征、鉴别手段、以及确认芯片没问题之后FreeRTOS上电就跑通的几个前提一次性讲清楚。1. 先复盘那颗不干活的芯片问题到底出在哪先说结论那颗芯片能被调试器识别但内部Flash容量、设备ID、内核ID都和ST官方的C8T6参数对不上。这就解释了为什么程序下载成功却运行异常——有一部分指令根本没被正确执行准确地说芯片内部可能连完整的Cortex-M3内核都没有或者Flash容量严重缩水导致程序写入后只有前一部分落进真实存储区。1.1 程序下载成功和程序正常运行是两回事很多人习惯把下载成功等同于芯片没问题这是个误区。下载成功只代表调试器通过SWD协议和芯片内部的调试访问端口完成了握手然后往Flash里写了一串数据。这个过程走的是芯片自己的调试接口就算内核本身有缺陷只要调试接口还能工作下载动作就能完成。但FreeRTOS启动之后就完全是另一码事了。调度器要切换任务栈、要操作NVIC中断控制器、要执行SVC和PendSV异常这些全靠Cortex-M3内核的底层机制。如果芯片内部用的是兼容性不够好的内核或者Flash容量被改小导致代码溢出运行阶段就会出各种奇怪问题死循环、HardFault、任务不切换、外设寄存器写进去读出来不对。我当时那颗芯片有个很典型的特征程序下载后如果只跑一个不带RTOS的裸机点灯居然也能闪烁。但只要一跑FreeRTOS必死无疑。原因很简单裸机程序代码量小可能就几KB全部落在了真实Flash范围内FreeRTOS工程随便编译一下都是二三十KB超过了假芯片的真实容量后面的代码其实没写进去一执行到超出范围的中断向量就直接崩溃。1.2 为什么假芯片能通过ST-Link/J-Link的识别这里要解释一下调试器的识别机制。ST-Link或者J-Link连接STM32时会读取目标芯片的IDCODE寄存器这个寄存器在芯片出厂时由ST写入记录了设备型号。但假芯片的厂商在Copy的时候直接把正品芯片的IDCODE一起抄了过来或者用一块能响应同样IDCODE的MCU冒充。所以调试器显示Detect: STM32F103C8根本不能说明什么只能说明对方在IDCODE这一层做了伪装。真正能暴露问题的是ST官方提供的校验机制。在STM32F103的参考手册里有几个关键寄存器DBGMCU_IDCODE0xE0042000、设备唯一ID0x1FFFF7E8起96位、Flash容量寄存器0x1FFFF7E0。正品芯片的DBGMCU_IDCODE值、Flash容量值、唯一ID的年份编码段都有一定规律而假芯片在这些寄存器上的表现经常会露馅。1.3 排查第一步排除一切软件因素在怀疑芯片之前我建议你还是先做一遍常规软件排查。顺序如下检查FreeRTOS的configTOTAL_HEAP_SIZE是否设置合理太小会导致任务创建失败但注意任务创建失败在标准库版本的FreeRTOS里有时候不会报错只是任务不运行。检查启动文件是否正确。STM32F103C8T6是64KB Flash用的启动文件应该是startup_stm32f10x_md.s。很多人从网上拷工程用的hd.s大容量在C8T6上也能编译通过但实际运行会出问题。检查外部晶振是否起振。FreeRTOS的时基依赖于SysTick但只要系统时钟正常SysTick就会正常。如果你用的是HSE外部晶振晶振没焊好会出现能下载、不能运行的问题。检查PA13/PA14是否被程序意外配置成普通GPIO。SWD引脚被复用后调试器连接会变得不稳定甚至出现连接一次之后再也连不上的情况。这四步都排除掉之后如果芯片还是没反应再往下查硬件本身。2. 解剖假芯片从内核身份ID到Flash容量的完整验证过程我在确认软件没问题后做了下面这套验证流程。每一条都有明确的寄存器依据不需要贵重的专业设备一个ST-Link和一个串口模块就能完成。这也是我推荐所有怀疑芯片有问题的同行去做的标准流程。2.1 第一步读设备ID和内核ID核对ST官方定义STM32F103系列调试接口开放了大量只读寄存器都能通过调试器直接访问。最常用的是下面几个寄存器地址作用正品F103C8T6典型值DBGMCU_IDCODE0xE0042000设备识别码0x20036410Rev Z等Flash容量寄存器0x1FFFF7E0Flash大小KB0x00000040即64KB芯片唯一ID起始0x1FFFF7E896位唯一ID无法伪造的随机值第一步用J-Link Commander或者STM32CubeProgrammer读一下DBGMCU_IDCODE。如果你拿到的是正品这里应该是一个和官方枚举值对得上的数字。ST在RM0008参考手册里列出了F103系列各型号的DEV_ID值0x410是F103中容量系列的标准值后面跟着的是RevID。如果你的芯片读出来DEV_ID是0x411甚至0x414那就要高度警惕了——那不是F103C8T6该有的值。第二步读Flash容量寄存器。STM32F103C8T6应该读出0x40也就是64KB。如果你读出来是0x2032KB甚至是别的值可以基本断定这颗芯片不是原厂C8T6很可能是拿更低容量的型号打磨后冒充的。这一条非常准因为Flash容量寄存器是出厂固化的一般造假者不会去改它改了反而容易露馅。2.2 第二步用CoreSight调试组件扫描内核Cortex-M3内核的ROM表地址在0xE00FF000调试器可以通过这个地址扫描出芯片内部CoreSight组件的分布。正品STM32F103的ROM表结构里能看到Cortex-M3 ROM、Debug ROM、DWT、BPU等标准组件。如果你用J-Link的命令行工具执行mem32 0xE00FF000 4会读到一组特征明显的地址。假芯片如果用的是其他家的M3或者M0内核ROM表的布局会完全不同。我有一个朋友测过一颗国产GD32F103冒充的芯片它的ROM表里有些地址的排列顺序和ST不完全一致仔细对比官方手册就能发现差异。对于不熟悉寄存器级的同行这一步可能有点门槛但如果你真想确认芯片真伪这个方法是核弹级的确凿证据。2.3 第三步跑一个全内存读写测试假设前面两步都通过了还能不能有其他猫腻有。有些翻新片是正品芯片但已经经历过高温焊接或长期存储内部Flash的某个扇区可能已经写不进去了。程序下载时调试器没报错但运行到那个坏扇区就会卡死。验证方法是写一小段测试代码对每一页Flash执行擦除-写入-读取-比对。STM32F103C8T6共有64页每页1KB。如果某一页写入后读出的数据和写入的数据不一致说明这页有问题。这种按页遍历的测试能找出绝大部分Flash有坏块的芯片。我见过的情况是有些翻新片只有后半段Flash坏掉前半段正常所以跑小Demo没问题跑大工程就挂和FreeRTOS这种动辄二三十KB的场景简直是天作之合。2.4 第四步核对唯一ID的年编码段STM32的96位唯一ID格式公开在应用笔记里其中包含晶圆坐标、批次号、年份编码等字段。正品芯片的年份编码不可能晚于生产日期如果一颗全新芯片的ID表明它是2015年生产的那你拿到的多半是库存芯片甚至翻新片。这个方法需要对照ST的应用笔记AN3364虽然不能直接证明是假货但可以给你一个采购溯源上的参考。我把这套流程走完之后基本可以100%确认那颗芯片是假货。而且它的DEV_ID读出来是0x410不假但Flash容量寄存器只有0x20——也就是说这是一颗32KB的芯片打磨成64KB来卖。32KB跑FreeRTOS加一堆任务编译出来的镜像都奔着40KB去了怎么可能正常工作。3. 顺手做一次芯片心电图上电时序、复位、时钟与BOOT配置在把锅甩给芯片之前有一个环节特别容易被忽略就是最小系统电路的硬件状态。假芯片问题确实存在但也不排除有些没反应其实是因为电路设计或者焊接工艺造成的。这里我总结一套自己的检查顺序建议遇到问题都过一遍成本很低但能帮你少走弯路。3.1 电源不是电压对就行这么简单STM32F103需要三组供电VDD2.0V~3.6V、VDDA模拟供电、VBAT备份电池供电。很多最小系统板把VDDA和VDD直接连一起问题不大但关键要看电源的纹波和上电斜率。用示波器看3.3V的上电波形如果上升沿坡度太缓超过几十毫秒芯片内部的POR上电复位电路可能无法正确触发导致芯片上电后处于一种未定义状态。这时候你按复位键有时候能恢复有时候不能表现就是时而能跑、时而死了。FreeRTOS对复位时序没有额外的苛刻要求但如果连裸机都偶尔不跑先查电源别查调度器。还有一个高频坑有些假芯片的功耗比正品高不少如果板子用的是低压差线性稳压器比如AMS1117-3.3它的最大输出电流是1A按理说够用。但有些翻新片的内核电路已经被老化损坏短路电阻下降上电瞬间电流冲击特别大电源被拉垮芯片自然起不来。测一下整板电流如果待机比你预期的正常值高出两三倍以上多半有猫腻。3.2 复位电路和BOOT引脚的状态要板级验证STM32F103的NRST引脚内置POR复位电路外部电容不是必须的但绝大多数官方参考设计都加了100nF左右的电容。如果电容漏电或者虚焊复位引脚电压会被拉低到门限附近芯片反复复位表现出来就是程序下载成功但运行几毫秒后又从头开始你以为任务没跑其实是被打断复位了。BOOT0和BOOT1引脚也要实测电压。正常从Flash启动的要求是BOOT00接地BOOT1任意。如果BOOT0被外部电路意外拉高芯片上电后会进入系统存储器引导模式程序根本不会从你的Flash启动。这个事我在不少自制板上见过有些是飞线接错了有些是引脚间距太近焊锡连锡了。串口没输出、点灯没反应、调试器又“一切正常”——就差这一根引脚。3.3 外部晶振不起振排查法FreeRTOS工程默认用的是HSE锁相环倍频到72MHz或者HSI直接跑。如果用HSE晶振不起振的典型症状是芯片完全无反应因为SystemInit里等待HSE就绪会卡死。在标准库的SystemInit函数里如果你定义了SYSCLK_FREQ_72MHz系统会一直等HSE就绪起不来就卡在while循环里。排查方法用示波器探头点OSC_IN引脚正常起振时能看到8MHz正弦波。看不到波形就查晶振负载电容、焊接是否虚焊、晶振本体是否损坏。如果是廉价晶振建议直接换一个。另一个技巧是把工程改成HSI启动如果HSI模式下能跑起来而HSE模式不能跑那问题基本锁定在外部晶振电路。注意假芯片对晶振起振条件更挑剔。因为打磨片的内核可能不是原厂ST的内部振荡器放大器的驱动能力和正品有差异配上质量差的晶振就会出现正品能起振、假芯片死都不振的情况。我遇到过一颗芯片在同一个板子上换上正品晶振正常起振换回假芯片示波器上就是一条直线。所以晶振问题也可以反向佐证芯片真伪。3.4 把工程切成最小验证集如果上面的硬件检查都没问题但FreeRTOS仍然不跑我强烈建议你做一个最小验证集工程只保留一个LED翻转任务关闭一切无关外设初始化关闭中断关闭低功耗模式使用HSI内部时钟。这个工程应该控制在10KB以内。如果最小验证集能跑说明芯片基础功能正常问题在复杂工程里。这时再逐步加回外设、加回任务二分定位。如果最小验证集都不跑那芯片本身或者四周围电路一定有问题这时候再走芯片真伪鉴别流程。这个策略能帮你把“软件问题”和“硬件问题”快速切分不至于在一个可能有问题的主板上反复编译两三天。4. 正品芯片无误之后FreeRTOS上电就跑通的几个前提确认芯片是正品之后接下来才是真正考验FreeRTOS工程能力的时候。同样的源码在正品芯片上能不能一次跑通取决于几个关键配置。这些配置我在多个项目里反复踩过坑整理成清单建议对照检查。4.1 FreeRTOS的启动文件与中断向量优先级设置FreeRTOS在Cortex-M3上正常运行依赖两个核心中断SysTick时基 PendSV任务切换 SVC启动第一个任务。这三个异常都在arm架构内部不受外部外设影响。其中最容易出错的是NVIC中断优先级分组。Cortex-M3支持最多8位优先级但STM32F103只实现了4位也就是16级优先级。FreeRTOS的configKERNEL_INTERRUPT_PRIORITY和configMAX_SYSCALL_INTERRUPT_PRIORITY这两个宏的值必须对应到硬件可用的优先级片段上。在STM32F103的标准库工程里通常调用NVIC_PriorityGroupConfig(NVIC_PriorityGroup_4)也就是全部4位都用作抢占优先级没有子优先级。此时硬件优先级范围是0~15数值越小优先级越高。FreeRTOS的要求是configKERNEL_INTERRUPT_PRIORITY必须设置为最低优先级即15。configMAX_SYSCALL_INTERRUPT_PRIORITY建议设置为5或更低数值更大才能保证FreeRTOS的临界区不被外部中断干扰。如果你用了别的分组方式比如分组2那么优先级分布是2位抢占2位子优先级情况会复杂很多F103上直接建议用分组4。4.2 堆大小与任务栈分配不能拍脑袋FreeRTOS的任务栈分配是一个需要算清楚的事情不是随手填一个256或者512就完事。每个任务创建时会从FreeRTOS的堆里分配任务栈任务栈大小以字为单位4字节。一个典型的计算方法是先估算任务里用到的最大局部变量数组和函数调用链路的深度。比如你的任务里有一个char buf[128]的局部数组那就是32字再加上函数调用可能用到的栈帧空间包括printf这类可变参数函数的栈消耗一个任务至少需要128字到256字才稳妥。而configTOTAL_HEAP_SIZE这个值决定所有任务栈和内核对象能用的总内存。STM32F103C8T6只有20KB SRAM通常在工程里设为12KB到15KB比较合理。如果你开三个任务每个任务256字1KB加上队列、信号量、定时器等内核对象12KB的堆完全够用。太高了会导致链接失败或启动时堆初始化失败。要注意的是FreeRTOS自带的heap_4.c实现里堆大小定义在configTOTAL_HEAP_SIZE但底层实际利用的是静态数组ucHeap[configTOTAL_HEAP_SIZE]这个数组一般放在.bss段。如果编译后发现RAM超了优先减小堆大小而不是削减任务栈因为任务栈不够的后果是任务跑飞而堆不够的后果是创建任务返回NULL至少还在可控范围。4.3 标准库版本的SysTick处理STM32F103最常见的是标准外设库FreeRTOS的组合。这里有一个很经典的坑你在其他外设工程里可能会调用SysTick_Config()函数来产生毫秒延时但如果同时跑FreeRTOSSysTick的中断服务函数会被FreeRTOS接管你再去配置SysTick或者修改它的中断优先级等于和调度器抢时钟源。正解是FreeRTOS里的延时用vTaskDelay()不要用HAL_Delay()或者自己写的Delay_ms()循环。因为在FreeRTOS调度器启动后SysTick中断已经被FreeRTOS的xPortSysTickHandler()占据了。你如果又写了一个SysTick_Handler中断函数两个Handler同时存在链接器会报重复定义或者只有其中一个生效。信号灯、点灯任务这类短延时用vTaskDelay配合时间片轮转就够了。4.4 中断服务函数的FreeRTOS语义在FreeRTOS里中断服务函数里调用FreeRTOS API有严格限制。比如在UART接收中断里如果你调用了xQueueSendFromISR()必须在退出中断前调用portYIELD_FROM_ISR()来判断是否有更高优先级的任务被唤醒。很多人在裸机程序里习惯直接在中断里做逻辑处理移植到FreeRTOS后还保留这种风格就会出现很诡异的现象外部中断来了标志位置了但对应的处理任务迟迟不执行。这是因为在Cortex-M3上FreeRTOS利用PendSV异常实现上下文切换。如果中断里没有触发PendSV调度器就一直运行当前任务即使你已经把信号量给了更高优先级的任务它也不会真正切换过去。必须调用portYIELD_FROM_ISR(pxHigherPriorityTaskWoken)执行一次上下文切换请求。4.5 启动文件与FreeRTOS的初始化顺序一个常见的错误是在main函数里先把所有外设都初始化完再调用vTaskStartScheduler()而外设初始化里又开启了和FreeRTOS互斥的全局中断。标准库的默认定时器初始化一般不会开全局中断但如果你在创建任务之前就配置了UART中断并且NVIC_EnableIRQ()了中断可能在调度器还没有完成基础初始化时就触发导致不可预期行为。推荐的做法是main函数里先做时钟初始化、GPIO初始化和基础外设初始化然后创建任务最后才调用vTaskStartScheduler()。确保在调度器启动之前FreeRTOS需要的SVC和PendSV异常处于默认状态不要有任何外部中断在此之前触发。5. 从假芯片事件里沉淀的采购与调试清单经历了这次假芯片风波后我把采购和调试流程都沉淀成了固定动作。每次新来一批芯片我先抽几颗做快速验证用不上全套鉴别流程但几个关键点必须过。5.1 采购端的快速筛查检查项操作方法通过标准外观看激光打标、引脚是否氧化字迹清晰、无打磨痕迹调试器识别ST-Link连接读IDCODE与官方参数一致Flash容量读0x1FFFF7E00x00000040C8T6唯一ID读0x1FFFF7E8起12字节随机且不重复实测电流空载3.3V供电待机电流在合理范围烧录大镜像下载一个带FreeRTOS的Demo运行稳定不跑飞这个表格我打印出来贴在工位上新到芯片就对照着过一遍十分钟内完成。尤其是Flash容量这条简直是假芯片照妖镜。5.2 调试FreeRTOS跑飞问题时的检查顺序当你确定芯片真伪没问题代码还是跑飞我的调试顺序是开启FreeRTOS的堆栈溢出检测功能把configCHECK_FOR_STACK_OVERFLOW宏设为2然后在vApplicationStackOverflowHook里点亮一个独立的警示LED或者设置全局标志位。这是定位任务栈溢出最快的手段。用vTaskList()把所有任务的运行状态和栈高水位线打印出来通过串口输出到PC端。这个函数会显示每个任务的栈剩余最小值如果某个任务的高水位线逼近满值就加大那个任务的栈。检查中断优先级分组和FreeRTOS的优先级配置是否匹配。不匹配时FreeRTOS会静默死掉调度器好像卡住一样。检查是否在中断上下文里调用了xQueueSend非FromISR版本这会直接触发高优先级中断下的死锁。最后再怀疑芯片。用前面说的Flash容量读取法快速排除别一开始就花一整天去调代码。5.3 测试所有功能前先做一遍长时间稳定性测试很多问题不是上电就能发现的需要跑一段时间才暴露。FreeRTOS的多任务系统尤其需要长时间运行来暴露内存碎片、任务优先级反转、资源竞争等问题。我建议在正式交付前至少连续运行48小时监控温度、电流和关键串口日志。我那次假芯片问题其实早该在收到货后的抽检环节就被拦截下来结果因为偷懒跳过了静电测试和Flash容量检查直接浪费了两个人天。6. 一颗芯片引发的思考别急着优化代码先确认硬件说了实话这次经历让我对程序下载成功这个信号彻底失去了以前的信任感。调试器说连接正常只代表调试链路通程序下载完成只代表一串字节写入了某个存储区域甚至芯片的型号识别都可能只是一层伪装。真正的硬件是否在按Cortex-M3的规定执行每一条指令只有运行起来才知道。有人可能会说假芯片这种事情毕竟少见何必这么较真。但STM32F103系列因为生命周期长、用量大是目前市场上翻新片和打磨片的重灾区。尤其从2022年之后原厂新片越来越少渠道里流通的大多是库存料或者回收料。你在淘宝、闲鱼甚至某些授权代理商不到万分之一的概率碰到假货不会心疼但这个概率落在项目交期上就是灾难。个人建议做产品前先花十分钟做一次芯片身份验证。调试FreeRTOS无反应的故障时检查软件配置和电路设计固然重要但一定记得在怀疑清单里加上一条确认你面前这颗芯片真的是它标称的那颗芯片。有时候问题不在代码里而在芯片的身份里。最后分享一个小经验如果你手头没有高档的芯片测试仪最简单可靠的假芯片鉴别方式就是读Flash容量寄存器。我后来习惯了在新项目建工程的时候第一步就写一段代码把芯片型号参数和Flash容量通过串口打印出来既方便调试也顺便确认芯片身份。这个习惯帮我拦下了三次假芯片事故每次都省掉了后面铺天盖地的排查时间。
STM32F103无反应？学会Flash容量寄存器鉴别假芯片，FreeRTOS才能跑通
STM32F103 FreeRTOS芯片没反应你可能买到“假芯片”了前阵子调试一块STM32F103C8T6的最小系统板现象很诡异J-Link能连上芯片ID能读到程序下载也提示成功可FreeRTOS任务就是跑不起来——点灯任务没反应串口打印一个字符都不出。起初我以为是优先级配置写崩了、堆栈开小了或者时钟初始化有问题前前后后折腾了两天代码翻来覆去改了好几版。后来实在没辙把芯片拆下来换了一片同一个工程直接跑起来了。问题不在代码在这颗芯片本身——严格来说是假芯片。这个经历让我意识到很多人遇到STM32F103没反应的第一反应是查代码、查配置、查焊接唯独没有怀疑芯片本身。但在ST官方2022年就宣布STM32F103系列进入不推荐用于新设计的状态之后市面上这颗芯片的翻新片、打磨片、国产替代片鱼龙混杂芯片本身出问题的概率比很多人想象得高得多。这篇文章就以我自己的实际排查过程为主线把假芯片的特征、鉴别手段、以及确认芯片没问题之后FreeRTOS上电就跑通的几个前提一次性讲清楚。1. 先复盘那颗不干活的芯片问题到底出在哪先说结论那颗芯片能被调试器识别但内部Flash容量、设备ID、内核ID都和ST官方的C8T6参数对不上。这就解释了为什么程序下载成功却运行异常——有一部分指令根本没被正确执行准确地说芯片内部可能连完整的Cortex-M3内核都没有或者Flash容量严重缩水导致程序写入后只有前一部分落进真实存储区。1.1 程序下载成功和程序正常运行是两回事很多人习惯把下载成功等同于芯片没问题这是个误区。下载成功只代表调试器通过SWD协议和芯片内部的调试访问端口完成了握手然后往Flash里写了一串数据。这个过程走的是芯片自己的调试接口就算内核本身有缺陷只要调试接口还能工作下载动作就能完成。但FreeRTOS启动之后就完全是另一码事了。调度器要切换任务栈、要操作NVIC中断控制器、要执行SVC和PendSV异常这些全靠Cortex-M3内核的底层机制。如果芯片内部用的是兼容性不够好的内核或者Flash容量被改小导致代码溢出运行阶段就会出各种奇怪问题死循环、HardFault、任务不切换、外设寄存器写进去读出来不对。我当时那颗芯片有个很典型的特征程序下载后如果只跑一个不带RTOS的裸机点灯居然也能闪烁。但只要一跑FreeRTOS必死无疑。原因很简单裸机程序代码量小可能就几KB全部落在了真实Flash范围内FreeRTOS工程随便编译一下都是二三十KB超过了假芯片的真实容量后面的代码其实没写进去一执行到超出范围的中断向量就直接崩溃。1.2 为什么假芯片能通过ST-Link/J-Link的识别这里要解释一下调试器的识别机制。ST-Link或者J-Link连接STM32时会读取目标芯片的IDCODE寄存器这个寄存器在芯片出厂时由ST写入记录了设备型号。但假芯片的厂商在Copy的时候直接把正品芯片的IDCODE一起抄了过来或者用一块能响应同样IDCODE的MCU冒充。所以调试器显示Detect: STM32F103C8根本不能说明什么只能说明对方在IDCODE这一层做了伪装。真正能暴露问题的是ST官方提供的校验机制。在STM32F103的参考手册里有几个关键寄存器DBGMCU_IDCODE0xE0042000、设备唯一ID0x1FFFF7E8起96位、Flash容量寄存器0x1FFFF7E0。正品芯片的DBGMCU_IDCODE值、Flash容量值、唯一ID的年份编码段都有一定规律而假芯片在这些寄存器上的表现经常会露馅。1.3 排查第一步排除一切软件因素在怀疑芯片之前我建议你还是先做一遍常规软件排查。顺序如下检查FreeRTOS的configTOTAL_HEAP_SIZE是否设置合理太小会导致任务创建失败但注意任务创建失败在标准库版本的FreeRTOS里有时候不会报错只是任务不运行。检查启动文件是否正确。STM32F103C8T6是64KB Flash用的启动文件应该是startup_stm32f10x_md.s。很多人从网上拷工程用的hd.s大容量在C8T6上也能编译通过但实际运行会出问题。检查外部晶振是否起振。FreeRTOS的时基依赖于SysTick但只要系统时钟正常SysTick就会正常。如果你用的是HSE外部晶振晶振没焊好会出现能下载、不能运行的问题。检查PA13/PA14是否被程序意外配置成普通GPIO。SWD引脚被复用后调试器连接会变得不稳定甚至出现连接一次之后再也连不上的情况。这四步都排除掉之后如果芯片还是没反应再往下查硬件本身。2. 解剖假芯片从内核身份ID到Flash容量的完整验证过程我在确认软件没问题后做了下面这套验证流程。每一条都有明确的寄存器依据不需要贵重的专业设备一个ST-Link和一个串口模块就能完成。这也是我推荐所有怀疑芯片有问题的同行去做的标准流程。2.1 第一步读设备ID和内核ID核对ST官方定义STM32F103系列调试接口开放了大量只读寄存器都能通过调试器直接访问。最常用的是下面几个寄存器地址作用正品F103C8T6典型值DBGMCU_IDCODE0xE0042000设备识别码0x20036410Rev Z等Flash容量寄存器0x1FFFF7E0Flash大小KB0x00000040即64KB芯片唯一ID起始0x1FFFF7E896位唯一ID无法伪造的随机值第一步用J-Link Commander或者STM32CubeProgrammer读一下DBGMCU_IDCODE。如果你拿到的是正品这里应该是一个和官方枚举值对得上的数字。ST在RM0008参考手册里列出了F103系列各型号的DEV_ID值0x410是F103中容量系列的标准值后面跟着的是RevID。如果你的芯片读出来DEV_ID是0x411甚至0x414那就要高度警惕了——那不是F103C8T6该有的值。第二步读Flash容量寄存器。STM32F103C8T6应该读出0x40也就是64KB。如果你读出来是0x2032KB甚至是别的值可以基本断定这颗芯片不是原厂C8T6很可能是拿更低容量的型号打磨后冒充的。这一条非常准因为Flash容量寄存器是出厂固化的一般造假者不会去改它改了反而容易露馅。2.2 第二步用CoreSight调试组件扫描内核Cortex-M3内核的ROM表地址在0xE00FF000调试器可以通过这个地址扫描出芯片内部CoreSight组件的分布。正品STM32F103的ROM表结构里能看到Cortex-M3 ROM、Debug ROM、DWT、BPU等标准组件。如果你用J-Link的命令行工具执行mem32 0xE00FF000 4会读到一组特征明显的地址。假芯片如果用的是其他家的M3或者M0内核ROM表的布局会完全不同。我有一个朋友测过一颗国产GD32F103冒充的芯片它的ROM表里有些地址的排列顺序和ST不完全一致仔细对比官方手册就能发现差异。对于不熟悉寄存器级的同行这一步可能有点门槛但如果你真想确认芯片真伪这个方法是核弹级的确凿证据。2.3 第三步跑一个全内存读写测试假设前面两步都通过了还能不能有其他猫腻有。有些翻新片是正品芯片但已经经历过高温焊接或长期存储内部Flash的某个扇区可能已经写不进去了。程序下载时调试器没报错但运行到那个坏扇区就会卡死。验证方法是写一小段测试代码对每一页Flash执行擦除-写入-读取-比对。STM32F103C8T6共有64页每页1KB。如果某一页写入后读出的数据和写入的数据不一致说明这页有问题。这种按页遍历的测试能找出绝大部分Flash有坏块的芯片。我见过的情况是有些翻新片只有后半段Flash坏掉前半段正常所以跑小Demo没问题跑大工程就挂和FreeRTOS这种动辄二三十KB的场景简直是天作之合。2.4 第四步核对唯一ID的年编码段STM32的96位唯一ID格式公开在应用笔记里其中包含晶圆坐标、批次号、年份编码等字段。正品芯片的年份编码不可能晚于生产日期如果一颗全新芯片的ID表明它是2015年生产的那你拿到的多半是库存芯片甚至翻新片。这个方法需要对照ST的应用笔记AN3364虽然不能直接证明是假货但可以给你一个采购溯源上的参考。我把这套流程走完之后基本可以100%确认那颗芯片是假货。而且它的DEV_ID读出来是0x410不假但Flash容量寄存器只有0x20——也就是说这是一颗32KB的芯片打磨成64KB来卖。32KB跑FreeRTOS加一堆任务编译出来的镜像都奔着40KB去了怎么可能正常工作。3. 顺手做一次芯片心电图上电时序、复位、时钟与BOOT配置在把锅甩给芯片之前有一个环节特别容易被忽略就是最小系统电路的硬件状态。假芯片问题确实存在但也不排除有些没反应其实是因为电路设计或者焊接工艺造成的。这里我总结一套自己的检查顺序建议遇到问题都过一遍成本很低但能帮你少走弯路。3.1 电源不是电压对就行这么简单STM32F103需要三组供电VDD2.0V~3.6V、VDDA模拟供电、VBAT备份电池供电。很多最小系统板把VDDA和VDD直接连一起问题不大但关键要看电源的纹波和上电斜率。用示波器看3.3V的上电波形如果上升沿坡度太缓超过几十毫秒芯片内部的POR上电复位电路可能无法正确触发导致芯片上电后处于一种未定义状态。这时候你按复位键有时候能恢复有时候不能表现就是时而能跑、时而死了。FreeRTOS对复位时序没有额外的苛刻要求但如果连裸机都偶尔不跑先查电源别查调度器。还有一个高频坑有些假芯片的功耗比正品高不少如果板子用的是低压差线性稳压器比如AMS1117-3.3它的最大输出电流是1A按理说够用。但有些翻新片的内核电路已经被老化损坏短路电阻下降上电瞬间电流冲击特别大电源被拉垮芯片自然起不来。测一下整板电流如果待机比你预期的正常值高出两三倍以上多半有猫腻。3.2 复位电路和BOOT引脚的状态要板级验证STM32F103的NRST引脚内置POR复位电路外部电容不是必须的但绝大多数官方参考设计都加了100nF左右的电容。如果电容漏电或者虚焊复位引脚电压会被拉低到门限附近芯片反复复位表现出来就是程序下载成功但运行几毫秒后又从头开始你以为任务没跑其实是被打断复位了。BOOT0和BOOT1引脚也要实测电压。正常从Flash启动的要求是BOOT00接地BOOT1任意。如果BOOT0被外部电路意外拉高芯片上电后会进入系统存储器引导模式程序根本不会从你的Flash启动。这个事我在不少自制板上见过有些是飞线接错了有些是引脚间距太近焊锡连锡了。串口没输出、点灯没反应、调试器又“一切正常”——就差这一根引脚。3.3 外部晶振不起振排查法FreeRTOS工程默认用的是HSE锁相环倍频到72MHz或者HSI直接跑。如果用HSE晶振不起振的典型症状是芯片完全无反应因为SystemInit里等待HSE就绪会卡死。在标准库的SystemInit函数里如果你定义了SYSCLK_FREQ_72MHz系统会一直等HSE就绪起不来就卡在while循环里。排查方法用示波器探头点OSC_IN引脚正常起振时能看到8MHz正弦波。看不到波形就查晶振负载电容、焊接是否虚焊、晶振本体是否损坏。如果是廉价晶振建议直接换一个。另一个技巧是把工程改成HSI启动如果HSI模式下能跑起来而HSE模式不能跑那问题基本锁定在外部晶振电路。注意假芯片对晶振起振条件更挑剔。因为打磨片的内核可能不是原厂ST的内部振荡器放大器的驱动能力和正品有差异配上质量差的晶振就会出现正品能起振、假芯片死都不振的情况。我遇到过一颗芯片在同一个板子上换上正品晶振正常起振换回假芯片示波器上就是一条直线。所以晶振问题也可以反向佐证芯片真伪。3.4 把工程切成最小验证集如果上面的硬件检查都没问题但FreeRTOS仍然不跑我强烈建议你做一个最小验证集工程只保留一个LED翻转任务关闭一切无关外设初始化关闭中断关闭低功耗模式使用HSI内部时钟。这个工程应该控制在10KB以内。如果最小验证集能跑说明芯片基础功能正常问题在复杂工程里。这时再逐步加回外设、加回任务二分定位。如果最小验证集都不跑那芯片本身或者四周围电路一定有问题这时候再走芯片真伪鉴别流程。这个策略能帮你把“软件问题”和“硬件问题”快速切分不至于在一个可能有问题的主板上反复编译两三天。4. 正品芯片无误之后FreeRTOS上电就跑通的几个前提确认芯片是正品之后接下来才是真正考验FreeRTOS工程能力的时候。同样的源码在正品芯片上能不能一次跑通取决于几个关键配置。这些配置我在多个项目里反复踩过坑整理成清单建议对照检查。4.1 FreeRTOS的启动文件与中断向量优先级设置FreeRTOS在Cortex-M3上正常运行依赖两个核心中断SysTick时基 PendSV任务切换 SVC启动第一个任务。这三个异常都在arm架构内部不受外部外设影响。其中最容易出错的是NVIC中断优先级分组。Cortex-M3支持最多8位优先级但STM32F103只实现了4位也就是16级优先级。FreeRTOS的configKERNEL_INTERRUPT_PRIORITY和configMAX_SYSCALL_INTERRUPT_PRIORITY这两个宏的值必须对应到硬件可用的优先级片段上。在STM32F103的标准库工程里通常调用NVIC_PriorityGroupConfig(NVIC_PriorityGroup_4)也就是全部4位都用作抢占优先级没有子优先级。此时硬件优先级范围是0~15数值越小优先级越高。FreeRTOS的要求是configKERNEL_INTERRUPT_PRIORITY必须设置为最低优先级即15。configMAX_SYSCALL_INTERRUPT_PRIORITY建议设置为5或更低数值更大才能保证FreeRTOS的临界区不被外部中断干扰。如果你用了别的分组方式比如分组2那么优先级分布是2位抢占2位子优先级情况会复杂很多F103上直接建议用分组4。4.2 堆大小与任务栈分配不能拍脑袋FreeRTOS的任务栈分配是一个需要算清楚的事情不是随手填一个256或者512就完事。每个任务创建时会从FreeRTOS的堆里分配任务栈任务栈大小以字为单位4字节。一个典型的计算方法是先估算任务里用到的最大局部变量数组和函数调用链路的深度。比如你的任务里有一个char buf[128]的局部数组那就是32字再加上函数调用可能用到的栈帧空间包括printf这类可变参数函数的栈消耗一个任务至少需要128字到256字才稳妥。而configTOTAL_HEAP_SIZE这个值决定所有任务栈和内核对象能用的总内存。STM32F103C8T6只有20KB SRAM通常在工程里设为12KB到15KB比较合理。如果你开三个任务每个任务256字1KB加上队列、信号量、定时器等内核对象12KB的堆完全够用。太高了会导致链接失败或启动时堆初始化失败。要注意的是FreeRTOS自带的heap_4.c实现里堆大小定义在configTOTAL_HEAP_SIZE但底层实际利用的是静态数组ucHeap[configTOTAL_HEAP_SIZE]这个数组一般放在.bss段。如果编译后发现RAM超了优先减小堆大小而不是削减任务栈因为任务栈不够的后果是任务跑飞而堆不够的后果是创建任务返回NULL至少还在可控范围。4.3 标准库版本的SysTick处理STM32F103最常见的是标准外设库FreeRTOS的组合。这里有一个很经典的坑你在其他外设工程里可能会调用SysTick_Config()函数来产生毫秒延时但如果同时跑FreeRTOSSysTick的中断服务函数会被FreeRTOS接管你再去配置SysTick或者修改它的中断优先级等于和调度器抢时钟源。正解是FreeRTOS里的延时用vTaskDelay()不要用HAL_Delay()或者自己写的Delay_ms()循环。因为在FreeRTOS调度器启动后SysTick中断已经被FreeRTOS的xPortSysTickHandler()占据了。你如果又写了一个SysTick_Handler中断函数两个Handler同时存在链接器会报重复定义或者只有其中一个生效。信号灯、点灯任务这类短延时用vTaskDelay配合时间片轮转就够了。4.4 中断服务函数的FreeRTOS语义在FreeRTOS里中断服务函数里调用FreeRTOS API有严格限制。比如在UART接收中断里如果你调用了xQueueSendFromISR()必须在退出中断前调用portYIELD_FROM_ISR()来判断是否有更高优先级的任务被唤醒。很多人在裸机程序里习惯直接在中断里做逻辑处理移植到FreeRTOS后还保留这种风格就会出现很诡异的现象外部中断来了标志位置了但对应的处理任务迟迟不执行。这是因为在Cortex-M3上FreeRTOS利用PendSV异常实现上下文切换。如果中断里没有触发PendSV调度器就一直运行当前任务即使你已经把信号量给了更高优先级的任务它也不会真正切换过去。必须调用portYIELD_FROM_ISR(pxHigherPriorityTaskWoken)执行一次上下文切换请求。4.5 启动文件与FreeRTOS的初始化顺序一个常见的错误是在main函数里先把所有外设都初始化完再调用vTaskStartScheduler()而外设初始化里又开启了和FreeRTOS互斥的全局中断。标准库的默认定时器初始化一般不会开全局中断但如果你在创建任务之前就配置了UART中断并且NVIC_EnableIRQ()了中断可能在调度器还没有完成基础初始化时就触发导致不可预期行为。推荐的做法是main函数里先做时钟初始化、GPIO初始化和基础外设初始化然后创建任务最后才调用vTaskStartScheduler()。确保在调度器启动之前FreeRTOS需要的SVC和PendSV异常处于默认状态不要有任何外部中断在此之前触发。5. 从假芯片事件里沉淀的采购与调试清单经历了这次假芯片风波后我把采购和调试流程都沉淀成了固定动作。每次新来一批芯片我先抽几颗做快速验证用不上全套鉴别流程但几个关键点必须过。5.1 采购端的快速筛查检查项操作方法通过标准外观看激光打标、引脚是否氧化字迹清晰、无打磨痕迹调试器识别ST-Link连接读IDCODE与官方参数一致Flash容量读0x1FFFF7E00x00000040C8T6唯一ID读0x1FFFF7E8起12字节随机且不重复实测电流空载3.3V供电待机电流在合理范围烧录大镜像下载一个带FreeRTOS的Demo运行稳定不跑飞这个表格我打印出来贴在工位上新到芯片就对照着过一遍十分钟内完成。尤其是Flash容量这条简直是假芯片照妖镜。5.2 调试FreeRTOS跑飞问题时的检查顺序当你确定芯片真伪没问题代码还是跑飞我的调试顺序是开启FreeRTOS的堆栈溢出检测功能把configCHECK_FOR_STACK_OVERFLOW宏设为2然后在vApplicationStackOverflowHook里点亮一个独立的警示LED或者设置全局标志位。这是定位任务栈溢出最快的手段。用vTaskList()把所有任务的运行状态和栈高水位线打印出来通过串口输出到PC端。这个函数会显示每个任务的栈剩余最小值如果某个任务的高水位线逼近满值就加大那个任务的栈。检查中断优先级分组和FreeRTOS的优先级配置是否匹配。不匹配时FreeRTOS会静默死掉调度器好像卡住一样。检查是否在中断上下文里调用了xQueueSend非FromISR版本这会直接触发高优先级中断下的死锁。最后再怀疑芯片。用前面说的Flash容量读取法快速排除别一开始就花一整天去调代码。5.3 测试所有功能前先做一遍长时间稳定性测试很多问题不是上电就能发现的需要跑一段时间才暴露。FreeRTOS的多任务系统尤其需要长时间运行来暴露内存碎片、任务优先级反转、资源竞争等问题。我建议在正式交付前至少连续运行48小时监控温度、电流和关键串口日志。我那次假芯片问题其实早该在收到货后的抽检环节就被拦截下来结果因为偷懒跳过了静电测试和Flash容量检查直接浪费了两个人天。6. 一颗芯片引发的思考别急着优化代码先确认硬件说了实话这次经历让我对程序下载成功这个信号彻底失去了以前的信任感。调试器说连接正常只代表调试链路通程序下载完成只代表一串字节写入了某个存储区域甚至芯片的型号识别都可能只是一层伪装。真正的硬件是否在按Cortex-M3的规定执行每一条指令只有运行起来才知道。有人可能会说假芯片这种事情毕竟少见何必这么较真。但STM32F103系列因为生命周期长、用量大是目前市场上翻新片和打磨片的重灾区。尤其从2022年之后原厂新片越来越少渠道里流通的大多是库存料或者回收料。你在淘宝、闲鱼甚至某些授权代理商不到万分之一的概率碰到假货不会心疼但这个概率落在项目交期上就是灾难。个人建议做产品前先花十分钟做一次芯片身份验证。调试FreeRTOS无反应的故障时检查软件配置和电路设计固然重要但一定记得在怀疑清单里加上一条确认你面前这颗芯片真的是它标称的那颗芯片。有时候问题不在代码里而在芯片的身份里。最后分享一个小经验如果你手头没有高档的芯片测试仪最简单可靠的假芯片鉴别方式就是读Flash容量寄存器。我后来习惯了在新项目建工程的时候第一步就写一段代码把芯片型号参数和Flash容量通过串口打印出来既方便调试也顺便确认芯片身份。这个习惯帮我拦下了三次假芯片事故每次都省掉了后面铺天盖地的排查时间。
