【USB-CAN】APM32F072移植刷入moonglow/kvaser开源固件做嵌入式开发和汽车电子调试的朋友手里几乎都缺不了一个USB-CAN分析仪。原厂工具动辄几百上千而开源方案这几年已经非常成熟生态比想象中好很多。我手里正好有一块基于APM32F072的USB-CAN小板子折腾了一周时间成功把moonglow固件移植刷入并且让它在Windows下被识别为Kvaser设备配合CanKing和CANalyzer使用非常稳定。这篇博文就从选型、硬件、移植、烧录到验证把整个过程和踩过的坑完整记录下来适合手里有APM32F072或者STM32F072板子、想自己搞定USB-CAN工具的朋友参考。1. 为什么要自己折腾USB-CAN固件1.1 USB-CAN分析仪到底解决了什么问题在调试BMS电池包、车身CAN报文采集、UDS诊断、或者做电机控制器通讯的时候一个稳定好用的CAN总线分析工具是刚需。CAN总线不像串口那样可以直接拿USB转TTL模块去抓数据它的物理层是差分信号需要CAN收发器转成逻辑电平再配合协议层软件才能看到具体的报文ID和数据内容。所以USB-CAN分析仪本质上就是一个USB转CAN的桥接设备核心是MCU内部的CAN控制器加一颗CAN收发器再通过USB接口把收到的CAN帧传给上位机。市面上的USB-CAN工具价格差异很大便宜的一百来块贵的几千上万。便宜的通常只能用厂家自己封闭的上位机稳定性也一般贵的比如Kvaser、Vector的CANalyzer软件生态确实好但硬件价格确实劝退很多人。开源USB-CAN固件项目的出现正好把这个问题解决了用一颗几十块的MCU加一颗几块钱的收发器刷上开源固件就能兼容主流驱动协议直接使用成熟的上位机软件性价比和可玩性都很高。1.2 为什么选择APM32F072这颗芯片选芯片不是拍脑袋。APM32F072是极海半导体推出的一款基于Cortex-M0内核的MCU最大的特点是和意法半导体的STM32F072做到了Pin-to-Pin兼容。这意味着原本为STM32F072设计的开源固件、PCB封装、引脚定义在APM32F072上几乎可以无缝复用硬件底子完全一样。这颗芯片的资源给USB-CAN这种应用刚好够用内置USB Device控制器支持USB 2.0 Full-Speed内置两个CAN控制器CAN1和CAN2支持CAN 2.0B主频最高48MHzFlash最大128KBRAM 16KB。USB-CAN分析仪本质上就是USB和CAN两个外设之间的数据搬运工48MHz的主频处理这个任务绰绰有余。选择APM32F072还有一个非常现实的原因供货稳定、价格便宜。经历过芯片短缺的人都知道ST芯片的供货周期和现货价格有时很离谱。而APM32F072作为国产替代方案货源充足单价低做个人项目或者小批量产品都很合适。实际测试下来USB、CAN、定时器这些外设的使用感受和ST原厂几乎一致官方提供的标准外设库也基本兼容。1.3 开源固件生态对比moonglow、candlelight、canable市面上针对STM32F072的USB-CAN开源固件有好几个最常听到的是candlelight_fw、moonglow、canable。这些项目之间的关系需要梳理清楚因为新手最容易在这里搞混。candlelight_fw是candleLight开源项目里的固件部分基于ST官方USB库和CAN驱动实现核心功能是把设备枚举为一个USB设备Windows下通过Zadig安装WinUSB驱动后配合candlelight的上位机或者开源工具如BUSMASTER使用。它定义了一套自己的通信协议SocketCAN在Linux下可以直接识别但在Windows下的软件生态相对少一些。moonglow是另一个非常有名的USB-CAN固件同样基于STM32F072但它的关键特性是模拟Kvaser Leaf Light的通信协议。Kvaser是CAN分析仪领域的老牌厂商它的驱动和软件生态非常成熟moonglow把Kvaser的协议模拟出来之后Windows下安装Kvaser官方驱动就能把设备识别成Kvaser Leaf Light然后直接使用Kvaser CanKing、CANalyzer这些软件无需额外定制上位机这对做汽车电子诊断的人来说非常方便。canable更准确的说是硬件平台的品牌名搭配candlelight固件出货后来也支持刷入moonglow固件。所以从固件层面看candlelight和moonglow是两条主要的软件路线前者走candlelight协议后者走Kvaser协议。从我个人的使用场景来看我用Kvaser的软件比较多而且手头有一批旧项目用的就是Kvaser驱动所以moonglow方案更适合我。如果你的工作流依赖Linux下的SocketCAN那candlelight可能是更好的选择。这个决策在后面驱动安装和软件选择上会有非常明显的区别。2. 硬件准备与板级改造细节2.1 主板、收发器、连接器清单列表搞清了软件路线硬件就简单多了。我的板子核心是APM32F072CBT6这是一颗LQFP48封装的MCU48个引脚资源刚好满足USB-CAN设计。如果你手里只有最小系统板也可以照这个思路自己连线原理上没有区别。物料清单大致如下APM32F072CBT6核心板或最小系统板CAN收发器TJA1050或者SN65HVD230前者是5V供电后者支持3.3V供电USB Type-C或Micro-USB接口用于连接电脑120欧姆终端电阻两个CAN总线调试必备3.3V稳压芯片比如AMS1117-3.3给MCU供电指示灯、按键用于状态显示和固件烧录模式切换若干电容电阻典型值参考数据手册这里要注意的是APM32F072内置的是USB Device控制器所以只需要外部接一个USB座子D和D-直接连到MCU的PA11和PA12引脚不需要外部USB转串口芯片。很多新入行的朋友会习惯性地找CH340或者CP2102在这里完全不需要USB信号是MCU自己产生的。2.2 APM32F072关键引脚与接线速查表从我画板子时的引脚分配来看整个系统的接线逻辑非常清晰下面这张表可以作为接线参考功能模块MCU引脚说明USB D-PA11USB Full-Speed数据负端USB DPA12USB Full-Speed数据正端CAN1 TXPB9CAN1发送引脚CAN1 RXPB8CAN1接收引脚CAN收发器TXDPB9连接到TJA1050的TXDCAN收发器RXDPB8连接到TJA1050的RXD晶振PF0/PF18MHz外部晶振必须使用复位NRST外部复位按键BOOT0BOOT0拉高进入系统Bootloader电源3.3V/GND稳压输出给MCUCAN_H收发器CANH连接到CAN总线高CAN_L收发器CANL连接到CAN总线低需要特别注意的是USB的D引脚上需要加一个1.5k欧姆的上拉电阻到3.3V用于告诉主机这是一个Full-Speed设备。这个电阻在STM32F072内部已经集成通过USB外设的配置寄存器可以打开内部上拉但从稳妥角度出发我习惯在板子上预留一个外部上拉电阻的位置万一内部上拉配置有问题可以直接飞线。CAN收发器这边TJA1050的RS引脚需要接到3.3V或通过电阻分压设定斜率模式否则高速模式下的振铃会影响通信质量。SN65HVD230的VREF引脚需要外接电容到地这也是很多人容易漏掉的细节。2.3 硬件改造中的三个关键注意事项第一是晶振问题。APM32F072内部的HSI振荡器精度在室温下还能接受但USB Full-Speed的位同步要求48MHz时钟误差在0.25%以内内部RC振荡器的精度和温度稳定性很难保证所以USB-CAN设计中必须使用外部8MHz晶振再通过PLL倍频到48MHz。我遇到过很多次USB枚举不稳定、一会儿识别一会儿丢失的情况最后发现都是因为有人偷懒省了晶振。第二是CAN总线终端电阻。CAN总线的两端必须各接一个120欧姆终端电阻用来匹配传输线阻抗防止信号反射。如果只是单独调试一个节点可以在CAN_H和CAN_L之间跨接一个120欧姆电阻。实测下来缺失终端电阻时总线空闲电平不稳定会导致大量错误帧这个问题在短线缆时不容易发现线一长就立刻暴露。第三是供电电流。USB-CAN设备从USB口取电时USB规范标准端口的供电能力是500mAAPM32F072正常工作电流只有几十毫安加上CAN收发器也就一百毫安以内看上去没问题。但如果你的板子上还带了LED灯、蜂鸣器、额外传感器就要小心总电流了最好加一个自恢复保险丝保护USB口否则短路烧掉电脑主板上的USB HUB控制器就得不偿失了。3. 固件移植与编译烧录全流程3.1 moonglow源码结构与核心文件解读moonglow固件的源码托管在GitHub上项目结构比较精简核心代码分为几个部分USB协议栈、CAN驱动、应用逻辑。拿到源码后第一步先熟悉目录结构不要急着编译。仓库里主要目录和文件的作用如下src/存放所有源文件包括main.c、usb_desc.c、can.c、protocol.cinc/存放头文件Makefile或CMakeLists.txt构建脚本bootloader/存放独立的Bootloader工程firmware/存放应用固件工程moonglow固件的架构是典型的Bootloader加App模式。Bootloader负责通过USB DFU协议接收新固件并写入FlashApp则是实际运行的USB-CAN应用逻辑。这种设计带来的最大好处是升级固件不需要连接SWD调试器只需要把设备切换到DFU模式用dfu-util命令就能通过USB刷写新固件。移植到APM32F072时最核心的问题在于原版针对STM32F072的HAL库调用需要替换成APM32F0xx的标准外设库。APM32官方提供了完整的F0系列标准外设库API风格和ST早期标准库几乎一致所以替换工作量不大主要集中在时钟配置、GPIO初始化、CAN外设初始化这几个模块。3.2 时钟树与系统时钟配置的关键修改点时钟配置是整个移植过程中最容易出问题的地方也是决定USB能否正常工作的关键。APM32F072的系统时钟来源可以是HSI、HSE或者PLL而USB外设的48MHz时钟必须来自PLL输出。原版moonglow代码针对STM32F072的时钟配置是8MHz外部晶振作为HSEPLL倍频6倍得到48MHz系统时钟同时PLL的另一个输出给USB提供48MHz时钟。APM32F072的时钟树结构和ST完全一致所以理论上这个配置可以直接复用。实际修改时需要关注的地方是时钟源使能顺序。极海官方标准外设库中RCC配置的函数命名和ST不同例如ST的是RCC_HSEConfig和RCC_PLLConfigAPM32库可能是RCC_ConfigHSE和RCC_ConfigPLL。编译时会报出未定义符号逐个对照数据手册修正即可。这里分享一个排查时钟问题的经验USB枚举失败、Windows反复提示无法识别的USB设备时优先检查时钟。把PLL配置打印出来看实际的系统时钟频率或者用示波器测一下PA8引脚的MCO输出判断时钟是否在48MHz附近。如果偏差大于0.25%USB通信质量会非常差。3.3 标准外设库替换与外设初始化适配原版moonglow使用的是ST的HAL库而APM32官方提供的是标准外设库类似于ST Standard Peripheral Library两者的API风格差异比较大。HAL库使用句柄和回调函数初始化流程是HAL_CAN_Init(hcan)标准外设库则直接操作寄存器初始化流程是CAN_Init(CAN1, CAN_InitStructure)。我移植时采取的策略是保留原版的逻辑框架只把底层外设调用替换为APM32标准外设库的对应API。具体来说GPIO初始化把HAL_GPIO_Init替换为GPIO_ConfigPin设置模式和复用功能USB初始化APM32F072的USB IP核和ST一致USB描述符和端点配置代码基本不用改CAN初始化重点配置波特率预分频器、位时间、同步跳转宽度中断处理APM32的CAN中断向量和ST相同中断服务函数名需要按照APM32库的命名规则修改这个过程看似繁琐但其实需要动的文件就那么几个。我建议在替换完每个外设的初始化后先编译一次确认没有链接错误再逐个外设测试。不要想着一次全部改完再调那样出了问题很难定位。3.4 Bootloader刷写与应用固件烧录实战APM32F072芯片出厂时自带ROM Bootloader可以通过BOOT0引脚选择启动模式。当BOOT0拉高时芯片从系统存储器启动此时可以通过USART1或者USB DFU接口烧录程序。这是我最推荐的Bootloader烧录方式因为它不需要额外的SWD调试器只需要一根USB线和电脑就能完成。具体操作流程如下将BOOT0跳线设置为高电平BOOT1保持低电平用USB线连接板子和电脑上电此时芯片进入系统Bootloader模式电脑上打开设备管理器应该能看到一个STM Device in DFU Mode或者类似的设备使用dfu-util工具烧录moonglow的Bootloader固件烧录完成后将BOOT0跳线恢复为低电平重新上电板子进入应用Bootloader状态此时按住板上的按键再插入USB线进入DFU下载模式使用dfu-util烧录应用程序固件命令示例dfu-util -d 0483:df11 -a 0 -s 0x08000000:leave -D moonglow_bootloader.bin dfu-util -d 0483:df11 -a 0 -s 0x08004000:leave -D moonglow_app.bin这里要特别注意应用固件烧录的起始地址。Bootloader占了Flash起始地址应用固件必须从偏移地址开始通常是0x08004000或者0x08008000具体取决于Bootloader占用的Flash大小。如果偏移地址不对固件刷进去后设备无法正常运行。如果你手头有ST-Link或者J-Link也可以用SWD接口直接烧录命令如下openocd -f interface/stlink.cfg -f target/stm32f0x.cfg -c program moonglow_bootloader.bin 0x08000000 verify reset exit openocd -f interface/stlink.cfg -f target/stm32f0x.cfg -c program moonglow_app.bin 0x08004000 verify reset exitSWD方式是烧死之后最好的恢复手段建议有条件的话备一个ST-Link。我用几块钱的国产ST-Link V2都能正常识别APM32F072兼容性很好。4. 驱动安装、设备识别与通信验证4.1 Windows下安装Kvaser驱动并识别设备moonglow固件刷入后设备插入电脑如果之前安装过Kvaser驱动系统会直接识别为Kvaser Leaf Light。如果没有驱动设备管理器里会看到一个未知设备需要手动安装驱动。Kvaser官方驱动可以从官网下载安装包会自动匹配设备ID。moonglow固件在USB描述符中模拟了Kvaser的VID和PID所以安装过程非常顺利不需要额外的修改。安装完成后在设备管理器的通用串行总线设备里能看到Kvaser Leaf Light的字样此时说明驱动已经绑定成功。这里有一个容易踩的坑如果你之前给设备安装过WinUSB或者libusb驱动再装Kvaser驱动时可能会冲突。解决办法是在设备管理器里右键设备选择更新驱动手动选择Kvaser驱动或者先在设备管理器里卸载旧驱动并勾选删除驱动程序软件再重新安装Kvaser驱动。另外一个技巧是安装Kvaser官方软件套装包括CanKing和Kvaser Driver这个套装里自带驱动和上位机装完一套全部解决。CanKing安装后打开软件会自动扫描连接的Kvaser设备能看到设备型号和序列号界面简洁功能对于抓取CAN报文完全够用。4.2 自环测试与双设备通信验证方法设备识别成功后第一件事是做回环测试不需要任何外部CAN设备把CAN_H和CAN_L直接短接在一起或者接一个120欧姆终端电阻。这是因为CAN收发器在发送数据的同时也会监听总线如果总线上的数据和自己发送的数据一致说明收发链路正常。在CanKing软件中设置波特率为500kbps发送一个标准帧比如ID为0x123数据字节为0x11 0x22 0x33 0x44 0x55 0x66 0x77 0x88如果能收到相同的数据说明单节点回环测试通过。这里要注意的是回环测试只能验证发送链路和接收链路的基本逻辑不能代替真实总线测试因为真实总线上同时还有其他节点在竞争总线仲裁。双节点测试可以准备两块USB-CAN板子插在同一台电脑或两台电脑上一块发送、一块接收。发送端和接收端都设置为相同的波特率发送端周期性发送报文接收端检查收到的报文ID和数据内容是否匹配。实际测试时还可以把其中一个节点的终端电阻去掉观察是否出现CAN错误帧这能帮你理解终端电阻在总线通信中的实际作用。4.3 用CanKing和BUSMASTER做报文抓取与发送CanKing是Kvaser自带的免费软件界面非常简洁适合快速验证。打开后选择设备型号设置波特率点击Start就能看到总线上的所有报文ID和数据内容可以按ID过滤、按数据内容过滤还支持日志记录把抓到的报文保存为csv或log文件留着后续分析。如果你需要更复杂的过滤逻辑和信号解析BUSMASTER是一个不错的选择。它在Windows下可以识别Kvaser设备支持加载DBC文件对CAN报文做信号级解析这意味着你可以直接看到某个物理量的电压、温度、转速等具体数值而不是原始十六进制数据。从我的实际体验来看moonglow固件刷入后在BUSMASTER下的使用体验和原厂Kvaser设备几乎没有差别。帧发送周期稳定时间戳精度在亚毫秒级别对于绝大多数调试场景完全够用。如果要做BMS调试这种对时间同步要求不高的场景开源方案确实足够可靠。5. 常见问题与排查技巧实录5.1 设备无法识别、枚举失败的排查方法USB-CAN设备最常见的故障是插上电脑后没有反应设备管理器里连未知设备都没有。这个问题首先要确认的不是软件而是硬件供电。用万用表测一下板子的3.3V电压是否正常如果电压偏低检查稳压芯片是否损坏或者电容是否焊接正确。电源正常但主机仍然没有检测到USB设备问题大概率出在USB D和D-线上的信号。用示波器查看PA11和PA12引脚在上电瞬间是否有电平跳变如果没有检查引脚是否被复用成了USB功能以及内部上拉电阻是否打开。这里要说一下很多人在这个环节忽略了一个细节USB线一定要用数据线不是充电线。很多老的Micro-USB线只接了VCC和GND没有D和D-插上去自然没有任何反应。排除了上述问题后如果设备管理器出现了未知设备或黄色感叹号那就是驱动安装的问题了。更新驱动为Kvaser驱动或者在设备属性里手动指定驱动路径一般都能解决。5.2 CAN通信不稳定、丢帧乱码的现象与处理CAN通信出现丢帧、乱码、错误帧时排错的优先级如下先检查波特率配置再检查终端电阻最后查接线质量。波特率问题是排查重点。CAN总线上的所有节点必须使用相同的波特率且允许的误差范围很小。moonglow固件源码中默认的波特率可以通过配置文件修改常见的波特率是125kbps、250kbps、500kbps和1Mbps。我建议把波特率固定为500kbps作为调试用这个速率在大部分车载网络中都能看到。如果发送端是500kbps接收端误设成250kbps你会看到大量错误帧和CRC错误。终端电阻问题也很常见。CAN总线只有两个端节点需要各接一个120欧姆电阻中间节点不需要。如果所有节点都没有接终端电阻总线空闲时电平漂移会导致错误帧如果电阻接多了总线负载过重信号幅值会衰减。调试时最简单的做法是只在自己这块板子上跨接一个120欧姆电阻如果网络中有其他设备也有终端电阻很容易出现信号质量问题。接线方面要注意的是CAN_H和CAN_L是一对双绞线尽量避免平行走线或使用飞线。实际调试中飞线超过一米就可能出现信号完整性问题表现为偶发丢帧和总线错误。关于固件差分升级这是一个相对进阶的话题。因为moonglow固件本身占用Flash很小后续如果想开发新功能每次整包烧录也挺耗时。可以参考一些开源项目的方案设计差分升级机制只用Bootloader比较固件差异并局部更新Flash扇区这样可以缩短升级时间、降低失败概率。不过对于一般调试用途整包烧录已经完全够用差分升级更多是一个值得留意的优化方向。5.3 固件刷死后的恢复技巧与预防措施刷固件最怕的就是设备变砖好在APM32F072的BOOT0引脚给了我们充足的恢复空间。即使应用固件完全损坏只要Bootloader区域完好按住板上的按键插入USB线进入Bootloader的DFU模式就可以重新烧录应用固件。如果连Bootloader也刷坏了那就需要SWD调试器上场。用ST-Link连接到板子的SWDIO、SWCLK、GND在OpenOCD里执行全片擦除命令openocd -f interface/stlink.cfg -f target/stm32f0x.cfg -c init; halt; stm32f0x unlock 0; exit擦除完成后先烧录Bootloader再烧录应用固件设备就恢复了。这里建议大家在成功刷写完一个可用固件后立刻备份一份Flash的完整镜像可以用dfu-util -U命令导出以后万一搞挂了直接用备份恢复。预防措施上我个人的习惯是每次烧录新固件前先用整片读回的方式备份当前固件。这样即使新固件有问题也能快速回到稳定版本。另外给设备做一个简单的外壳避免带电插拔时短路这些看似不起眼的细节能省下不少返工时间。6. 开源USB-CAN方案的生态价值与扩展方向6.1 从Kvaser兼容到CANopen、UDS诊断协议栈moonglow固件最大的价值不仅仅在于省下了买Kvaser设备的钱更在于它开放了整个协议栈的源码你可以在它的基础上自由定制。比如在固件层增加CANopen协议支持把设备变成一个小型CANopen主站或从站或者加上UDS诊断协议栈配合Python脚本做自动化诊断测试。我后续计划在moonglow固件基础上增加一层过滤规则把不关心的CAN ID直接在MCU内部丢弃减少USB带宽占用。在高负载总线环境下这能显著提升USB传输效率。原版固件是全部数据都往USB传总线负载高时容易丢帧加上硬件过滤之后稳定性会更好。另一个扩展方向是增加云端数据上传功能。USB-CAN设备接入电脑后通过Python脚本把抓到的CAN报文转发到MQTT服务器然后手机端实时查看车辆状态或设备运行参数。这种玩法在智能硬件研发、车队管理、设备远程运维中很有价值。当然这已经不完全属于USB-CAN固件的范畴但它确实是开源方案带来的想象空间。6.2 注意事项USB带宽、总线负载与实时性平衡即便moonglow固件稳定性很好用的时候也要注意USB-CAN工具的固有能力边界。USB Full-Speed的理论带宽是12Mbps扣除协议开销实际有效数据吞吐量大约在8Mbps左右。CAN总线最高速率1Mbps单路CAN的数据量远小于USB带宽所以瓶颈通常不在USB而在上位机对数据的处理和存储上。如果同时挂载两路CAN都用1Mbps高速率满负载运行上位机软件来不及处理时丢帧就不可避免。这种情况下可以通过提高上位机软件的处理优先级、增大USB传输缓冲、或者缩小过滤范围来解决。硬件的实时性上限就在那里软件优化只能把实际效果逼近理论值不能突破物理限制。6.3 踩坑总结与配套工具建议整体折腾下来我的体会是APM32F072确实可以作为STM32F072的低成本替代方案moonglow固件的移植难度远低于预期真正花时间的是USB驱动调试和CAN物理层问题排查。如果你也想复刻这个方案我建议准备好以下几样工具一个ST-Link调试器用于固件救砖一台带USB 2.0口的电脑兼容性比USB 3.0口更稳一块万用表查供电和接线问题必备一台示波器有条件的话强烈建议备上排查USB信号和CAN物理层波形直接高效。调试过程中我最大的感受是USB-CAN开源固件虽然是技术活但真正考验人的是耐心。USB枚举不上、CAN总线上全是错误帧、固件刷进去跑不起来这些问题没有一个能靠运气蒙混过去逐一排查、对比波形、核对寄存器配置才是解决问题的正道。搞通了之后手里多了一个稳定可靠的USB-CAN工具以后再遇到CAN调试需求就不用到处借设备了。