STM32F103假芯片识别实战：FreeRTOS频繁崩溃的排查与鉴别方法

前阵子帮朋友调试一块STM32F103C8T6 FreeRTOS的项目板板子是网上买的“全新原装”芯片丝印清清楚楚可代码一烧进去就是没反应。SWD 能连上程序能下载但点灯不亮串口不出数据进了调试模式一看PC 指针到处乱跳。折腾两天后我越来越觉得不对劲这块芯片可能根本不是我以为的那颗 STM32。这不是标题党。STM32F103 是地球上出货量最大的 MCU 之一同时也是被仿冒、翻新、打磨重标最严重的芯片。很多开发者买到的所谓“STM32F103C8T6”实际可能是 GD32、APM32甚至旧片重印、低配冒充高配的换标片。它们大部分裸机代码能跑却会在 FreeRTOS 这种强依赖时钟、中断优先级、Flash 时序的环境里疯狂翻车。文章我会把完整的排查过程写一遍从最小系统验证、PA8 时钟输出、芯片 ID 读取到 FreeRTOS 具体卡死问题的定位。如果你也在被“芯片没反应”折磨这篇应该能帮你少走不少弯路。1. 先搞懂“没反应”到底是什么状态1.1 从一次翻车现场说起那块板的项目需求不复杂使用 STM32F103 标准库 std v3.5基于 FreeModbus v1.6 移植 Modbus RTU 从站跑在 FreeRTOS 上通过 RS232 与上位机通信节点还要控制几个继电器和指示灯。听起来是典型的老工程改造代码量不大。问题出现在我把 FreeRTOS 内核加进去后裸机点灯正常串口回环正常但只要vTaskStartScheduler()一执行整个系统就像死了一样。我最初的判断是“任务栈不够”但砍到只剩一个空任务还是没反应。后来我用 J-Link 单步发现程序卡在 SystemInit 之前甚至有些时候芯片连 SWD 都会丢。最让我警惕的是这块板子我在硬件上用万用表量过供电正常复位引脚正常BOOT0 也拉了低晶振波形也能看到。代码层面的事我几乎试了个遍最后才把嫌疑放到芯片本身。事实证明项目用的“STM32F103C8T6”大概率是一颗打磨后重新印字的兼容芯片。1.2 假芯片不等于坏芯片但更坑很多人听到“假芯片”第一反应是芯片点都点不亮。但更坑的情况恰恰相反假芯片大多能跑只是“能跑”和“可靠跑”是两回事。市面上常见的假 STM32F103 有几类打磨重标片把其他品牌芯片上的字磨掉印上 ST 的 Logo 和型号。这类芯片里比较典型的就是 GD32F103 系列内核同样是 Cortex-M3但外设寄存器、Flash 接口、时钟树和 ST 原厂有差异。翻新片从旧板子上拆下来洗脚、整脚、重新印字成色看起来像全新。低配高标用 STM32F103C8T664KB Flash打磨后标成 STM32F103RCT6256KB Flash卖给做批量产品的客户。GD32 本身是合格的国产 MCU不是不能用。但问题在于如果你以为自己在用 ST 原厂芯片实际上跑的是 GD32 或者更杂的兼容片那么所有基于原厂数据手册做的硬件设计、功耗估算、Flash 擦写次数规划、ADC 校准和 FreeRTOS 时序配置都需要重新验证。这种“你以为你以为的”状态反而比芯片完全坏掉更危险。1.3 为什么 FreeRTOS 对假芯片更敏感裸机点灯只需要 GPIO 翻转对时钟精度、Flash 读取速度、中断优先级都不敏感。但 FreeRTOS 不一样它依赖精确的 SysTick 心跳、任务切换用的 PendSV 和 SVC 异常以及临界区中断屏蔽策略。任何一个环节和假设不一致系统就可能全盘崩溃。假芯片最常在三个方面暴露问题第一是内部 HSI 和 HSE 时钟精度。有些翻新片内部 RC 振荡器的校准值已经被擦除8MHz 实际可能只有 7.2MHz 或者 8.5MHz。FreeRTOS 的 tick 是从 SYSCLK 分频出来的时钟不准直接导致任务周期漂移、串口波特率偏差。第二是 Flash 读取等待周期。ST 手册要求 72MHz 主频下配置 2 个等待周期但兼容芯片的 Flash 性能可能更差或更好标准初始化代码一跑轻则偶尔取指错误重则 HardFault。第三是中断优先级。Cortex-M3 的中断优先级实现各家可能有细微差别FreeRTOS 对“哪些中断能调用 API”有严格划分兼容芯片一旦优先级行为不一致调度器启动就会异常。所以如果项目里用了 FreeRTOS芯片是不是正品往往不是“能不能用”的问题而是“什么时候崩”的问题。2. 拿到板子别急着写代码先把“硬件身份”验了2.1 最小系统三大自查供电、复位、启动模式很多“芯片没反应”的板子仔细查下来根本怪不到芯片头上而是最小系统没搭好。我无论多急拿到新板子都会先过一遍这三个点。供电是第一步。用万用表测 VDD 对 GND应该在 3.3V 左右同时要测 VDDA、VREF如果有引出是否在同一个电源平面上。STM32F103 对模拟电源和数字电源的压差有要求如果 VDDA 比 VDD 低太多芯片内部上电时序会异常。再看电流空载时整板电流应该在几毫安到十几毫安如果上电瞬间到了上百毫安先不要写代码先查电源芯片或某个电容大概率已经短路。复位是第二步。NRST 引脚正常应该被上拉到 3.3V按下复位按键时能拉低到 0V松开后恢复。别小看这个引脚如果复位电容漏电或者外部复位芯片配置不对芯片会一直处于复位状态程序当然跑不起来。示波器抓一下复位引脚的上升沿最好看到干净的上电复位脉冲。启动模式是第三步也是新手最容易翻车的地方。BOOT0 必须通过电阻下拉到 GND才能从主 Flash 启动。如果 BOOT0 悬空或者被干扰拉高芯片会进入系统存储器启动模式也就是内置 Bootloader用户程序自然不会被执行。BOOT1 在从主 Flash 启动时无所谓但在调试异常时也建议拉低。这三点查完才能往下谈软件。2.2 用万用表和示波器看“芯片醒没醒”确认最小系统没问题后下一步是看芯片是否真的“醒”了。如果板子上有外部晶振用示波器探头点在 OSC_IN 或 OSC_OUT 上正常能看到正弦波。但注意示波器探头有寄生电容直接点晶振可能会导致振荡停振所以看波形时尽量用 10x 探头并且减少触碰时间。比直接测晶振更稳的方法是测 PA8 的 MCO 时钟输出。STM32F103 的 PA8 可以复用为 MCO 引脚把内部时钟输出到外部。上电默认情况下 PA8 是什么都不输出的必须写一段极简代码配置 RCC 和 GPIO才能让 PA8 输出 SYSCLK、HSI、HSE 或 PLLCLK/2。这个测试的意义在于不管芯片表面印着什么字只要 PA8 输出的频率符合你配置的预期说明芯片内部的时钟树是活的启动文件至少跑过了一大半。如果你的示波器带宽不够或者手边只有万用表也可以换一种思路把 MCO 配置成较低频率的 HSI 输出看看有没有电压摆动。如果 PA8 上完全没有任何信号再排查晶振、启动文件和芯片供电。这类“由外到内”的验证顺序比一上来就烧 FreeRTOS 工程可靠得多。2.3 一个很土但很有效的操作手摸芯片温度很多年轻工程师不太信这种土办法但实战里手摸芯片温度真的能发现不少问题。芯片上电且没有运行用户程序时待机功耗应该很低外壳温度在通电几分钟内基本不会明显升高。如果芯片上电没几秒就烫手先怀疑两件事一是电源极性接反或者有引脚短路二是芯片内部已经损坏比如翻新片内部有物理损伤漏电流异常大。反过来如果芯片一点温度都没有也不一定是好事可能芯片根本没有上电或者内部电源没有建立起来。有一次我调试一块板子SWD 死活连不上程序下载不了最后手摸到芯片背面发烫拆下来一量发现是 PCB 上 3.3V 和 GND 之间某颗去耦电容短路。如果当时不摸这一下可能还会在软件层面浪费时间。芯片温度这个指标说土确实是土但排查“没反应”问题时能给出非常快的方向判断。3. 不拆芯片也能识破伪装三个软件级鉴别手段3.1 用 PA8 的 MCO 输出读“身体时钟”前文已经提到 PA8 可以输出 MCO 时钟这一步用好了不拆芯片也能判断芯片的时钟体质。我通常会在裸机工程里写一个专门的测试函数先配置外部 8MHz HSE等待 HSE 就绪然后配置 PLL 为 9 倍频得到 72MHz SYSCLK再把 MCO 输出源设置为 PLLCLK/2。这样一来PA8 上应该看到约 36MHz 的方波。如果 PA8 输出频率明显不对比如输出的是 8MHz 甚至 4MHz说明 PLL 没有正确锁定或者外部晶振没有起振。这类问题在假芯片上很常见因为兼容芯片的 HSE 起振时间、反馈电阻参数、负载电容要求和 ST 原厂不是完全一致有些翻新片内部振荡器电路老化起振特别慢甚至要几十毫秒才能稳定。如果你的代码在 HSE 就绪后立刻去操作 PLL就可能因为时序太紧导致配置失败。还有一个容易被忽略的点MCO 引脚配置为复用推挽输出时GPIO 速度要设为 50MHz否则高频方波会被整形得很难看。用示波器看 PA8 时如果波形上升沿特别缓别急着怀疑芯片先查 GPIO 速度和示波器带宽。3.2 读芯片 ID 和 Flash 容量软件级鉴别最直接的办法是读芯片内部的 ID 和 Flash 容量寄存器。STM32F103 的 Flash 容量寄存器地址在0x1FFFF7E0读取后得到的数值单位是 KB。比如 C8T6 读出来应该是 64RCT6 读出来应该是 256。如果芯片丝印写 256KB读出来的却是 64那就是低配换标片基本实锤。另一个关键是芯片唯一 IDUID地址在0x1FFFF7E8附近一共 96 位。你可以写一小段代码读取这些寄存器再通过串口打印出来。真芯片的 UID 通常看起来没有规律而且每一片都不一样。如果一批板子读出来的 UID 全是一模一样的或者都是全 F、全 0那这批芯片的身份就非常可疑了。在 Keil 里也可以用调试器直接看这些地址。进入调试状态后在 Memory 窗口输入0x1FFFF7E0观察 Flash size 和 UID 区域的值比写代码更快。但要注意如果你用的是国产兼容芯片有些厂家会刻意让这些寄存器的值和 ST 原厂一致所以这个手段只能算“报警器”不能算“定案依据”。3.3 用 J-Link Commander 快速核对 DBGMCU_IDCODE串口打印和 Keil 内存窗口都需要先把程序跑起来如果芯片连程序都跑不了就需要用调试器直接读取内核信息。J-Link Commander 是个很有用的工具安装 J-Link 驱动后打开命令行连接芯片后执行mem32 0xE0042000 4就能看到 DBGMCU_IDCODE 寄存器的内容。这个寄存器的低 16 位是设备 ID。ST 原厂不同系列对应不同值比如常见的 STM32F103 中容量和高容量芯片读出来的 DEV_ID 通常能对应上原厂手册里的编号。如果读出来的值和你的型号对不上或者是一个从未见过的新编号那就要仔细想想到底是什么芯片在里面了。J-Link Commander 还有一个好处它可以在不加载任何用户程序的情况下直接读取目标板信息连接速度也很快。如果你和我一样手边备有 J-Link建议新批次芯片到货后先全部扫描一遍把 ID、Flash 大小、UID 记录到表格里比对是否一致。这个习惯可以让你在项目后续开发中少踩很多坑。4. FreeRTOS 被“假芯片”带崩的典型病状与真正原因4.1 任务调度器启动即 HardFault在 FreeRTOS 的报障记录里最经典的现象就是“裸机一切正常vTaskStartScheduler()一跑立刻死机”。很多人第一反应是任务栈溢出但真正的原因往往更基础中断优先级配置和 FreeRTOS 对 Cortex-M3 的要求不一致。Cortex-M3 内核允许对 NVIC 中断优先级进行分组可以分成“抢占优先级”和“子优先级”。FreeRTOS 官方移植要求使用全抢占优先级模式也就是NVIC_PriorityGroup_4所有优先级位都作为抢占优先级。STM32 标准库里默认有时是NVIC_PriorityGroup_2如果你没在 main 函数里重新设置FreeRTOS 在开启调度器时可能会错误地配置 PendSV 和 SysTick 的优先级从而导致启动即 HardFault。在假芯片上这个问题会更容易暴露。因为有些兼容芯片对优先级寄存器的行为不是 100% 复刻你以为写进去的是第 5 级优先级实际可能变成了第 2 级进而触发了 FreeRTOS 的断言“configASSERT”或者 Crash。如果你已经改过优先级分组还是崩可以先把所有中断服务函数全部置空只保留 SysTick、PendSV、SVC看系统能否跑起来再逐个打开中断定位。4.2 SysTick“打架”标准库延时与 FreeRTOS 心跳很多 STM32F103 工程里都自带一个基于 SysTick 的 delay_ms 函数。裸机下没问题但 FreeRTOS 也要用 SysTick 作为系统心跳。如果不做处理两个模块都会去配置 SysTick最终谁后写谁生效整个调度器就废了。典型表现是FreeRTOS 任务能创建但vTaskDelay根本不生效任务无限循环占用 CPU或者任务看起来在跑但周期完全不对。排查方法很简单在 FreeRTOS 环境下不要在应用任务里调用基于 SysTick 的自写延时函数统一用vTaskDelay或vTaskDelayUntil。如果一定要保留一个低层延时给驱动用建议改用 DWT 计数器或者定时器避免占用 SysTick。假芯片对 SysTick 的影响主要集中在时钟源精度上。如果板子外部 8MHz 晶振没有起振代码又没能正确切换到 HSI芯片会以内部 RC 振荡器运行。此刻 FreeRTOS 心跳可能不是 1ms而是 0.8ms 或者 1.3ms。此类问题很难通过看代码找出来必须用一个 GPIO 翻转任务接示波器看实际翻转周期。如果周期和预期差得离谱优先检查时钟。4.3 串口 Modbus 波特率对不上先怀疑时钟回到我开头的项目STM32F103 FreeRTOS FreeModbus v1.6 RS232。上位机发送读保持寄存器 0x03 功能码从站要么没回复要么回复乱码。这种情况的排查路径一般是先串口回环再查波特率。把 FreeModbus 暂时放一边写一个最简单的串口回环程序上位机发ABCMCU 收到后原样发回。如果回显内容不对先用逻辑分析仪抓 MCU 的 TX 引脚看输出波形每一 bit 的实际宽度。拿 9600 波特率举例一位的宽度应该是约 104us如果你量出来是 110us 甚至 130us波特率就偏了上位机自然解不对。波特率偏差的来源有很多最常见的是外部晶振频率不标准或者芯片内部 PLL 倍频后的时钟和预期不一致。假芯片如果用的晶振负载电容和原设计不匹配振荡频率也会跑偏。还有一种情况是 RS232 电平转换芯片用了不良品比如假 MAX3232导致输出波形畸变。所以遇到乱码不要一上来就调程序先把物理层确认了再回到代码层。在 FreeRTOS 环境里跑 FreeModbus定时器中断优先级也要单独确认。Modbus RTU 的 3.5 字符超时需要由定时器中断产生这个中断的优先级必须高于configMAX_SYSCALL_INTERRUPT_PRIORITY且中断服务函数里不能调用可能阻塞的 FreeRTOS API。否则从站会频繁丢失一帧数据通信成功率极低。4.4 堆栈溢出检查别省FreeRTOS 里任务栈分配不足会导致栈区被踩踏轻则任务运行异常重则死机。这种问题在调试阶段非常隐蔽因为任务刚创建时栈可能够用运行一段时间后调用层级加深瞬间爆栈。开启方法是在FreeRTOSConfig.h里设置configCHECK_FOR_STACK_OVERFLOW为 1 或 2同时实现vApplicationStackOverflowHook钩子函数。当检测到栈溢出时FreeRTOS 会调用这个钩子你可以在里面点亮一个错误 LED 或者直接进入死循环。第二个选项更严格会检查任务栈的红火蚁区域是否被破坏代价是每次上下文切换多花几个周期调试阶段完全可以接受。还有一个和假芯片相关的坑兼容芯片如果 Flash 等待周期不够偶尔会取到错误指令表现和栈溢出非常相似PC 指针跳到不存在的地址调试器里看调用栈全是乱码。这时候不要只盯着任务栈可以尝试把芯片主频降到 36MHz 跑一下如果问题消失说明 Flash 读取时序有隐患再回头查芯片身份。5. 一套可以“抄作业”的 FreeRTOSSTM32F103 排查流程5.1 先把裸机 demo 跑稳再上 RTOS无论多着急我都建议先跑一个裸机 demo。不是看不起 RTOS而是“先跑起来”和“跑得对”是两件事。裸机 demo 至少要做完这几步GPIO 点灯、外部晶振PLL 到 72MHz、串口打印、外部中断、定时器 PWM。每一步都稳定后再往上叠加 FreeRTOS。最简单的点灯代码如下使用标准库 v3.5 和 Keil 工程#include stm32f10x.h void Delay(volatile uint32_t n) { while (n--) { __NOP(); } } int main(void) { GPIO_InitTypeDef gpio; RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOC, ENABLE); gpio.GPIO_Pin GPIO_Pin_13; gpio.GPIO_Mode GPIO_Mode_Out_PP; gpio.GPIO_Speed GPIO_Speed_50MHz; GPIO_Init(GPIOC, gpio); while (1) { GPIO_WriteBit(GPIOC, GPIO_Pin_13, Bit_RESET); Delay(1000000); GPIO_WriteBit(GPIOC, GPIO_Pin_13, Bit_SET); Delay(1000000); } }如果这段代码在板上跑不起来先不要碰 FreeRTOS回头查最小系统。裸机点灯是最低门槛它都过不了说明问题在硬件或者在芯片本身。5.2 最小 FreeRTOS 工程配置要点裸机 demo 稳定后新建一个最小 FreeRTOS 工程。强烈建议不要直接在原有裸机工程里加文件因为旧工程里可能藏着各种中断、延时函数排查时会互相干扰。新建工程更干净。关键的配置项如下#define configCPU_CLOCK_HZ 72000000UL #define configTICK_RATE_HZ 1000 #define configTOTAL_HEAP_SIZE (10 * 1024) #define configMINIMAL_STACK_SIZE 128 #define configCHECK_FOR_STACK_OVERFLOW 2注意configCPU_CLOCK_HZ必须和实际 SYSCLK 一致。如果你在SystemInit里把时钟配成了 72MHz那这里就是 72000000。如果芯片实际工作在 HSI 8MHz但你在配置文件里写的是 72MHzFreeRTOS 的时间计算会全部错误。Keil 工程里需要添加tasks.c、queue.c、list.c、port.c和heap_4.c。如果你没有动态创建/删除任务的需求heap_1.c也能用但我个人习惯直接用heap_4.c因为它在释放内存时不会产生严重碎片况且项目后期很难保证不删任务。5.3 二分法定位屏蔽任务、增量恢复最小 FreeRTOS 工程能跑之后再把业务任务一个一个加回去。这个过程是典型的二分法先只保留一个空任务循环调用vTaskDelay确认调度器正常然后加入第二个任务如果第二个任务一加就崩就注释掉它看看是不是它申请的资源或者调用的外设有问题。HardFault 定位我有个很实用的办法在HardFault_Handler里加一行断点指令调试时能直接停到异常发生的地方。void HardFault_Handler(void) { __asm(bkpt #0); while (1) { } }Keil 调试器停在bkpt后打开 Call Stack 窗口基本能看出是哪个任务、哪个函数触发了 HardFault。如果调用栈全是乱码多半是栈溢出或者函数指针被改写。再配合工程生成的.map文件可以查 PC 地址落在哪个函数区域。这个方法比在代码里到处加 printf 高效得多。6. 假芯片鉴别实战清单与采购避坑6.1 外观、丝印、批次怎么看软件鉴别已经很成熟了但我依然会把外观检查放在第一步因为它成本最低。用放大镜或者手机微距镜头看芯片表面的丝印ST 原厂激光打标的字体通常清晰、锐利、深浅均匀。打磨重印的芯片字体边缘经常发糊笔画发虚甚至能看到原先激光打标烧灼留下的残留痕迹。再看引脚。全新原装芯片的引脚应该整齐、光亮、无氧化。翻新片经过拆焊、洗脚、整脚后引脚根部容易残留助焊剂痕迹或者有细微的划痕。同一批采购的 10 片芯片如果丝印生产周期、批号、原点位置完全混乱就值得警惕。原厂同一批次芯片的丝印高度一致很少出现两片参差不齐的情况。还可以用无水酒精轻轻擦拭丝印区域。原厂激光打标不容易被擦掉但二次印刷的油墨可能一擦就淡。注意不要用力过猛擦坏了不好退货。6.2 用官方工具“照妖”外观检查只能排除一部分真正的“照妖镜”还是软件读取。用 ST-Link 连接 SWD 四线打开 STM32CubeProgrammer点击 Connect左侧会显示芯片的 Device ID、Flash size、UID 等信息。需要重点关注三个方面Device ID 是不是 ST 常见编号Flash size 和丝印型号是否一致UID 是否像批量打磨片那样重复。比如 STM32F103C8T6 的 Flash 是 64KB如果显示 256KB 或者 128KB说明芯片极大概率被换标过。如果 UID 读取全是FF或者00也不是正常状态。再多说一句有些兼容芯片刻意模仿了 ST 的 ID 寄存器和 Flash 大小寄存器读出来的值和原厂几乎一模一样。这时候就要结合前面 PA8 时钟输出、高温稳定性、高低温测试综合判断。没有任何一个单一手段能 100% 鉴别所有假芯片但把几个手段组合起来用基本能筛掉 90% 的坑。6.3 万一买到假芯片怎么办如果确认买到了假芯片首先第一时间停止大批量使用保留好聊天记录、订单号和芯片实物照片。然后联系供应商退货。注意措辞不要说“这是假芯片”而要说“这批芯片经调试器读取设备 ID 和 Flash 容量与订购型号不符需要贵司确认”。如果项目已经在量产阶段发现真相后也不要心存侥幸。即使假芯片能跑 FreeRTOS也很难保证在宽温度、电压波动、长时间运行下的稳定性。掉电保存数据失败、Flash 写入异常、串口通信偶发超时这些和芯片内部模拟电路、Flash 工艺密切相关。宁可停线换料也不要带着风险出货。如果你买到的是 GD32 这类“兼容芯片”而且你本身就有意使用它那也不要直接拿 ST 标准库的二进制烧进去完事。GD32 的 Flash 操作和 ST 系列存在差异最好使用厂家自己的库和启动文件。把它当成另一种 MCU 来开发而不是 STM32 的免费平替。6.4 常用问题排查速查表现象可能原因排查思路程序下载成功但灯不亮BOOT0 异常、GPIO 时钟未使能、芯片换标查 BOOT0 电平、检查 RCC_APB2PeriphClockCmd、读芯片 IDSWD 连接失败引脚被占用、芯片锁死、供电问题复位时按住复位键连接降低 SWD 速率检查 3.3VFreeRTOS 启动即 HardFault中断优先级分组不对、栈不足、任务函数阻塞设置 NVIC_PriorityGroup_4开启栈溢出检测空中断二分SysTick 不准确裸机 delay 占用 SysTick、HSE 未起振删除自写 SysTick 延时用逻辑分析仪量 GPIO 翻转周期串口 Modbus 乱码晶振偏差、RS232 电平芯片不良串口回环、逻辑分析仪量波特率、换 MAX3232掉电保存数据失败假芯片 Flash 工艺差异、掉电检测电路不完善示波器测掉电电压曲线增加掉电中断提前保存PWM 占空比到不了 100%比较值等于 ARR 时输出翻转异常、输出极性配置不对检查 TIM_OCPolarity尝试强制高电平核对重载值这张表不是标准答案却是实实在在踩过坑后的总结。遇到问题时先对照现象选可能的成因不要一头扎进代码里反复调试。最后再说一点我的个人习惯新到的芯片批次不管供应商吹得多好我都会先抽 3 片做三件事——读 UID、跑一次 72MHz 裸机串口回环、再跑一遍 FreeRTOS 多任务压测全部通过才允许入库。听起来挺麻烦但比起整机发到现场后客户说“没反应”这点时间真的不算什么。如果你也被“明明能下载、就是不跑代码”折磨相信我别急着怀疑编译器先怀疑芯片本身。