手里正好有一批APM32F072的空板子一直想做个便宜的USB-CAN分析仪。网上转了一圈发现基于STM32F072的moonglow/kvaser开源固件非常成熟硬件引脚又兼容于是决定把这块国产MCU利用起来。这篇文章就把整个移植过程、踩坑记录、验证方法完整写下来给同样想省钱的嵌入式玩家一条能直接走通的路。如果你也有一块APM32F072核心板或者自己画了USB-CAN小板想让它被电脑识别成Kvaser Leaf Light v2然后用Kvaser官方驱动和软件直接抓CAN报文那这篇文章就是为你准备的。整个过程不需要太高深的技术但要弄清楚USB描述符、时钟配置、CAN外设映射这几个关键点否则容易卡在调试阶段。1. 项目背景与方案选型思路1.1 为什么盯上APM32F072这颗芯片先说选型。APM32F072是极海半导体推出的一颗Cortex-M0内核MCU主频48MHzFlash从64KB到128KB不等片上带USB 2.0 Full-Speed控制器、CAN控制器、多路定时器和ADC。最关键的一点是它在引脚定义、内存映射、外设寄存器层面和ST的STM32F072做到了高度兼容。这意味着很多为STM32F072写的开源工程理论上可以直接编译然后烧到APM32F072上运行。价格上APM32F072比同规格的STM32F072要便宜不少资源也相对好买。对于做一个USB-CAN分析仪这种量级的产品来说性能完全够用。USB控制器负责和PC通信CAN控制器负责总线收发不需要外挂一颗USB转CAN芯片MCU内部全搞定BOM成本能压得很低。实际用下来APM32F072的USB外设和CAN外设表现都挺稳定。不过有一点得提醒它的USB时钟必须精确匹配48MHz否则枚举会有问题。这个后面实操章节会详细说。1.2 moonglow/kvaser固件解决的是什么问题USB-CAN分析仪在嵌入式开发里使用频率非常高调试汽车CAN总线、BMS通信、工业设备协议解析都离不开。国内能买到的USB-CAN工具从几十块到上千块都有贵的用的是成熟方案加专用驱动便宜的大多用CH340串口转CAN再加一个协议转换实际体验差距很大。moonglow开源固件的思路完全不一样。它把STM32F072这类MCU直接模拟成了Kvaser Leaf Light v2硬件Kvaser家的官方驱动会把这个设备当成真Kvaser设备来加载于是Windows下的CanKing、CANpro、Python的canlib库、Linux下的SocketCAN都能直接用。也就是说软件生态完全复用Kvaser的生态我们只需要做一个硬件小板子固件刷进去就拥有了一台“Kvaser兼容机”。这个固件本身是GPLv3协议开源的代码结构基于STM32 HAL库主要实现两部分工作USB侧解析Kvaser Leaf Light v2的命令协议CAN侧驱动bxCAN外设做报文收发。移植到APM32F072核心就是把这个工程拿到国产芯片上跑起来。1.3 移植方案的几种路线对比在动手之前先理清楚有三条路线可以走。第一条最粗暴直接编译moonglow的官方hex烧到APM32F072里。前提是你的硬件电路和原项目原理图一致尤其是晶振、USB引脚、CAN引脚配置。如果你手里是某宝买的小板子很可能引脚不完全一致这条路线大概率走不通。第二条是用STM32CubeMX重新生成一个APM32F072的HAL工程把moonglow的USB和CAN业务代码迁移进去驱动层换成APM32的HAL库或者继续用ST的HAL库。这条路线可控性最高也最容易排查问题适合要改版、改引脚的情况。第三条是在moonglow原工程基础上直接把HAL库换掉或者手动改设备型号宏。考虑到APM32F072对ST HAL库的兼容性还可以很多人直接Say不换库用ST的HAL编译也能跑。但要注意如果芯片内部SVD描述文件有细微差异外设初始化可能异常。我的做法是优先尝试第三条不行再退回第二条。我最后走了第三条加第二条结合的方式先用ST HAL编译原工程烧进去发现USB枚举不稳定然后在CubeMX里重新生成APM32工程把代码迁过去问题解决。这篇文章主要把最终可用方案写清楚同时把坑点罗列出来。2. 固件原理与工作流程拆解2.1 USB-CAN设备是如何被电脑识别成Kvaser的要理解moonglow固件得先搞清楚USB设备枚举的过程。PC上的USB Host在检测到设备插入时会发送一系列标准请求获取设备描述符、配置描述符、接口描述符和端点描述符。设备描述符里有一项很重要的ID信息Vendor ID厂商标识和Product ID产品标识。操作系统根据这个VID/PID决定加载哪个驱动程序。Kvaser Leaf Light v2的VID是0x0bfdPID在固件中用对应的Leaf Light v2产品号填充。只要设备枚举时报告这组IDKvaser驱动就会认为插入的是一台正版Kvaser设备然后尝试通过USB接口和它通信。moonglow固件做的事情就是在USB枚举阶段准确回复这些描述符并在后续通信中实现Kvaser驱动期望的协议交互。固件里的usbd_desc.c和usbd_customhid.c重点就是干这个。更准确地说Kvaser Leaf系列用的不是标准HID类而是自定义USB类固件要实现必要的控制传输和中断传输处理逻辑。整个过程可以打个比方固件像是在USB总线上扮演一个“演员”对外完全模仿Kvaser Leaf Light v2的说话方式主机端驱动不需要知道下面的MCU是什么它只认协议接口。这也是这个方案最巧妙的地方。2.2 固件内部的数据流转流程从CAN总线上来一个报文到PC软件显示出来中间经过的几个环节值得梳理清楚因为移植过程中任何一个环节断掉现象都不一样。CAN收发器芯片把总线差分信号转成TTL电平送到APM32F072的CAN RX引脚。bxCAN外设按预设的波特率识别出完整报文在硬件层面做过滤、校验然后存入CAN接收FIFO。固件主循环里CAN接收中断或者轮询方式把报文取出来转换成Kvaser协议规定的报文格式放到USB发送缓冲区。USB IN端点把数据上传给PCKvaser驱动处理后再交给应用层软件比如CanKing显示一帧报文。反向流程就是PC软件下发发送请求canlib库通过Kvaser驱动把命令打包成USB控制传输或中断传输写入USB OUT端点。固件解析这条命令取出要发送的CAN ID、数据、帧类型填到bxCAN发送邮箱CAN收发器再把电平送到总线上。任何一帧报文走完这条链路性能瓶颈通常在USB端点的处理效率上。moonglow固件对这个问题处理得比较合理中断传输保证实时性数据缓冲处理好速率匹配实测在500kbps波特率下连续收发没出现丢帧。2.3 移植前必须搞清楚的HAL库差异提到移植很多人第一时间担心的是HAL库能不能在APM32F072上跑。其实APM32F072在设计时考虑了和ST的寄存器级兼容性HAL库操作的本质是读写寄存器所以大部分API可以直接工作。但有几个差异点会影响实际体验第一个是时钟树配置。STM32F072和APM32F072默认都支持外部8MHz晶振内部48MHz振荡器但内部振荡器的校准机制有点不同。moonglow的默认工程里SystemClock_Config函数使用HSE或者HSI产生48MHz系统时钟。在APM32F072上如果直接用ST的HAL库RCC驱动可能会读到不存在的校准寄存器但一般不会崩溃只是时钟精度稍差。第二个是USB外设的电源和上拉控制。STM32F0系列的USB是有内置DP上拉但启用方式可能与APM32F072的寄存器略有差异。如果初始化代码里没有正确配置设备插入后PC完全没有枚举反应。第三个是CAN重映射。moonglow原工程把CAN引脚设置在了PA11和PA12这正好和USB D-和D复用。不过好在USB和CAN可以分时工作不会同时打开所以引脚冲突在软件上没有大问题。但如果你手里的板子把CAN接到了PB8和PB9那需要在gpio.c和can.c里做引脚重映射否则CAN收发永远失败。我给你的建议是移植时不要迷信“寄存器兼容所以代码直接能用”还是要把外设初始化对照数据手册核对一遍尤其是时钟、USB、CAN这三个外设这是整个固件的地基。3. 硬件准备与工程搭建3.1 自己焊一套可用的硬件板要是你想完全复现整个过程硬件其实很简单。APM32F072最小系统一个USB座子一颗CAN收发器再加几个电阻电容就能开始调。最小系统部分VDD接3.3V每个电源引脚旁边放一颗100nF去耦电容VDDA同样要滤波。NRST引脚接10kOhm上拉到3.3V。BOOT0下拉到地让芯片从主Flash启动。最重要的就是8MHz外部晶振USB必须用PLL把时钟倍频到48MHz只用内部HSI不做校准的话枚举不稳定概率非常大。USB部分D和D-直连MCU的PA11和PA12。USB座子的外壳需要接地。如果芯片内置DP上拉不明显有些设计会在D上加一颗1.5k上拉电阻具体看你要用的芯片型号和数据手册确定。我自己做的板子是参考moonglow原理图做的稳定枚举没出问题。CAN收发器我用的是TJA1050兼容性好最大速率1Mbps市场上容易买到。需要注意的是大多数CAN收发器的VCC是5V而MCU的CAN控制器是3.3V逻辑TJA1050的TXD和RXD引脚能直接兼容3.3V接线时把TJA1050的TXD接MCU的CAN RXRXD接MCU的CAN TX注意交叉。如果用的是SN65HVD230这类3.3V收发器电源直接3.3V接线逻辑一样。CAN总线两端还要各接一颗120欧姆终端电阻。短距离测试只在一端接也能用但为了规范建议两头都接。如果总线上已经有终端电阻了就不要再额外加不然差分信号幅度会偏小导致通信不稳定。3.2 编译环境的搭建与工程获取软件环境我用的Windows STM32CubeMX GNU Arm Embedded Toolchain Make。moonglow的GitHub仓库里带了完整的HAL库源码和Makefile理论上拉下来就能编但直接编原工程需要先确认一下源码里的芯片型号和启动文件是不是F072。拉取源码后工程目录里会有Core、Drivers、Middlewares这些目录。如果你之前做过STM32HAL开发对这个结构会很熟悉。编译前需要改一个地方Makefile或者工程选项里的芯片型号确保编译出来的启动文件对应的是STM32F072xB或者APM32F072。如果用手动arm-none-eabi-gcc命令用-mcpucortex-m0这个参数即可。如果你是Keil用户也可以用Keil MDK打开原工程只要安装好对应的Device Pack就能编译。不过APM32F072用ST的Device Pack会有一个问题就是CMSIS头文件里的寄存器定义可能和极海有点出入编译报错的话换成极海官方SDK里的头文件就好。推荐新手直接用GCC工具链命令行编译一次报错信息明确也方便改引脚配置后快速重新构建。整个过程不到一分钟就能出一个固件文件调试效率比IDE高很多。3.3 引脚映射确认与 BOARD 级适配拿到任何一块USB-CAN小板子第一步就是把原理图里CAN引脚的走向搞清楚。参照moonglow原工程它默认把CAN1_RX放在PA11CAN1_TX放在PA12和USB共用一组引脚。但多数成品小板或者开源小板为了同时引USB和CAN会把CAN放在PB8和PB9上避免引脚冲突。查引脚映射要到APM32F072的数据手册找到AFAlternate Function复用表确认PB8和PB9的CAN复用功能编号。通常情况下PB8对应CAN1_RXPB9对应CAN1_TX复用功能号是AF4。在CubeMX里配置引脚时把PB8选成CAN1_RXPB9选成CAN1_TX系统会自动填好复用功能。还有一个容易忽略的BOARD级适配是CAN收发器供电电压。如果你的板子用的是5V供电的TJA1050VBUS连接5VCAN收发器输出到MCU的RXD信号也许会被上拉到5V。虽然很多CAN收发器的RXD输出引脚能兼容3.3V MCU但万一遇到高电平超压的情况需要在RXD串一个分压电阻或者加电平转换。这个直接决定CAN收发能不能稳定工作调试前务必测量一下RXD引脚在线电压理想情况下高电平应当不超过3.6V。4. 移植实操从源码到可运行固件4.1 拉取源码与工程目录结构说明从GitHub上把moonglow的USB2CAN项目克隆下来之后整个目录结构大概如下Core文件夹放主程序、中断服务函数、系统时钟初始化USB_DEVICE文件夹放USB设备中间件包括设备描述符、接口描述符、端点回调CAN文件夹放CAN初始化和收发处理Drivers文件夹放HAL库源码。如果你只是想让原固件跑起来最关键的就是检查这些文件里有没有硬编码的芯片型号。在usbd_desc.c里设备描述符的VID和PID已经写好了不需要改在system_stm32f0xx.c或者SystemClock_Config函数里需要确认时钟源和时钟树配置。原工程的boards.h或者类似配置头文件里一般会定义引脚和几个关键宏。比如USE_STM32F072、CAN_GPIO_PORT、CAN_RX_PIN、CAN_TX_PIN这些。把这些宏和你手里的原理图对照清楚就是移植的第一步。4.2 系统时钟配置48MHz USB时钟是命门时钟配置是我这次移植踩得最深的一个坑。moonglow原工程针对STM32F072有一个SystemClock_Config函数默认逻辑是开启外部8MHz晶振HSE把HSE作为PLL输入PLL倍频到48MHz输出给系统时钟和USB外设。APM32F072同样有外部晶振和PLL理论上这个流程可以直接用。但ST的HAL库初始化PLL时会配置PLLSource和PLLMulAPM32F072的PLL寄存器布局一致所以直接用ST的HAL_RCC_ClockConfig也是能工作的。关键隐患在于内部HSI模式。有些小板子为了省一个晶振用内部8MHz HSI加PLL到48MHz但HSI精度不够USB枚举时会出现设备反复识别失败、超时、无法加载驱动这类问题。APM32F072虽然有HSI校准机制但软件里默认不会自动校准所以我强烈建议能用外部晶振就用外部晶振8MHz最合适没有晶振的板子做USB产品是给自己挖坑。实际修改SystemClock_Config的时候注意通过HAL_RCC_OscConfig配置RCC_OSCILLATORTYPE_HSE如果外部晶振起振失败函数会返回HAL_ERROR。这时先查硬件晶振负载电容是否配上、万用表测OSC_IN引脚有没有振荡波形。如果一定要用HSI也要在初始化后对HSI校准寄存器做一次校准写入。4.3 USB描述符和设备类的移植要点moonglow工程模拟Kvaser Leaf Light v2这部分代码集中在usbd_desc.c和usbd_customhid.c里。移植过程中绝大多数情况下不需要改代码但你要确认编译器有没有正确编译到这些文件有没有因为芯片型号切换导致某个回调函数没被注册。如果你用CubeMX重建工程需要特别注意USB_DEVICE中间件配置里的Class选择。moonglow使用的自定义类不是标准HID而是Custom Class。在CubeMX里选USB Device的Communication Device Class或者HID都可能不对得选Custom Human Interface Device或者直接无Class然后手动把usbd_customhid.c加进工程。最省事的办法是直接从moonglow工程里拷贝USB_DEVICE目录不用CubeMX生成。设备描述符里的bcdUSB、idVendor、idProduct、iManufacturer、iProduct这些字段保持原样。如果Windows驱动识别成未知设备优先检查USB描述符请求是否正常应答可以用Wireshark抓USB或者用UsbTreeView工具看设备枚举状态。4.4 CAN外设初始化与收发逻辑CAN外设的初始化相对简单。HAL库的CAN_HandleTypeDef结构体需要配置波特率、工作模式、自动重传等参数。关键参数是波特率分频和位时间。CAN总线的位时间由同步段、传播段、相位缓冲段1和相位缓冲段2组成每个段的时间份额可以通过寄存器配置。比如我们要跑500kbps波特率APM32F072的CAN外设时钟是48MHzPCLK1通常也是48MHz需要计算预分频器和时间段。计算公式是波特率 CAN时钟频率 / (预分频器 × (1 tBS1 tBS2))。取预分频器4tBS16tBS23则500k 48MHz / (4 × (163))刚好匹配。Kvaser驱动在应用层设置波特率时固件会接收命令并重新配置CAN外设所以要保证Prescaler、BS1、BS2这三个参数的计算关系足够通用。移植时还容易漏掉的是CAN过滤器配置。bxCAN的过滤器组必须使能并设置掩码为接收全部报文或者按项目需要配置过滤。moonglow原工程默认接收所有帧类型和所有ID这样方便调试。如果你的适配器只用来监听这个设置没问题。收发逻辑上CAN接收中断服务函数HAL_CAN_RxFifo0MsgPendingCallback里通过HAL_CAN_GetRxMessage拿到CAN帧数据再调用USB发送接口把数据包发出去。发送侧则是解析USB命令后通过HAL_CAN_AddTxMessage添加发送请求。这个流程很清晰建议调试时先做回环测试也就是把CAN外设设置成LoopBack模式不需要外部收发器就能确认MCU内部CAN路径是否走通。4.5 编译烧录的完整操作流程编译之前重新检查几个宏定义。在Makefile或者工程配置里芯片型号必须明确。如果是GCC编译启动文件和链接脚本对应的是STM32F072xB。APM32F072的Flash容量如果是64KB链接脚本里FLASH大小要对应调整如果原工程默认128KB Flash而你手里的片子只有64KB链接时会报地址溢出。烧录我用的是DAP-Link加SWD接口四根线SWDIO、SWCLK、GND、3.3V。APM32F072出厂时SWD默认是开启的直接用OpenOCD或者Keil就能连上。如果需要解锁芯片读保护可以用STM32CubeProgrammer或者J-Flash做整片擦除后再烧录。刷完固件后先把USB线插到电脑正常情况下几秒内系统会提示“发现新硬件”或者自动加载Kvaser驱动。如果没有反应先打开设备管理器看有没有未知设备。如果设备枚举出来了但带黄色感叹号多半是驱动没装或者设备描述符回复异常按下一节排查步骤走。Windows下Kvaser驱动装好后可以用Kvaser CanKing打开设备选择对应通道设置波特率500kbps点击“Go On Bus”然后另一个CAN节点发送报文CanKing界面里就能看到ID、数据、时间戳。5. 实测验证与软件联调5.1 Windows下驱动安装与设备识别Kvaser官方驱动可以从官网下载安装包也可以从开发包安装。安装完驱动后插上设备打开设备管理器在“通用串行总线设备”或者“Kvaser”分类下能看到设备名称里带Kvaser Leaf Light v2的字样。有一个细节容易被忽略就是Kvaser驱动安装完成后通常还会附带一个“Kvaser Driver Updater”第一次插上兼容设备时它可能会弹窗扫描设备状态。如果弹窗显示Device not authorized或者未激活本质上不影响正常使用直接用CanKing打开就行。如果不希望安装整套Kvaser软件也可以只装canlib然后通过Python的kvaser-canlib库控制设备。安装命令很简单pip install kvaser-canlib。写一个小脚本打开通道、设置波特率、发送一帧测试报文验证收发链路是否正常。回环测试时如果发送成功且没有报错说明USB和CAN链路都通。如果发送报错先检查总线状态看看总线上有没有其他节点、终端电阻有没有接、波特率是否一致。5.2 用Python canlib验证收发能力Python脚本验证最简单直接这里给一个裸例子不需要借助CanKingfrom canlib import canlib ch canlib.openChannel(0, canlib.canOPEN_ACCEPT_VIRTUAL) ch.setBusParams(canlib.canBITRATE_500K) ch.busOn() ch.write(0x123, [0x11, 0x22, 0x33, 0x44], canlib.canMSG_EXT) print(send ok) ch.busOff() ch.close()如果设备工作正常write方法会返回成功总线上另一个节点能收到扩展帧0x123数据是四个字节。如果总线上没有其他节点建议用另一个USB-CAN设备或者开发板监听单独一个设备不能直接验证发送因为CAN需要ACK。你可以把另一个设备设置为ListenOnly模式去抓报文。还可以通过while循环连续发送来测试稳定性观察有没有发送失败返回值。我实测在500kbps下连续发送10万帧没有出现错误帧和丢帧说明固件在APM32F072上运行稳定。5.3 Linux下SocketCAN直接使用Linux底下这个设备会被识别成Kvaser Leaf Light v2内核自带kvaser_usb驱动插上后执行dmesg大概率能看到“kvaser_usb 1-1:1.0 can0: firmware version X”类似的日志。直接用SocketCAN工具操作sudo ip link set can0 up type can bitrate 500000 candump can0另一个终端发送cansend can0 123#11223344candump窗口里就能看到新报文。Linux下使用不需要安装任何驱动体验很好这也是这个方案的价值之一——调试Linux CAN网络时随手插上一个兼容设备就能当分析仪用。如果Linux下没有识别出can0检查内核是否编译了kvaser_usb模块或者USB枚举本身有没有问题。插上设备后先看lsusb能找到0bfd开头的设备再谈驱动加载。6. 常见问题与排查技巧6.1 USB枚举失败或设备反复掉线USB枚举失败是最容易遇到的问题我从硬件和软件两个方向总结排查路径。硬件侧先检查DP、DM引脚有没有插反USB座子引脚和MCU引脚对应关系是否和原理图一致。再用万用表测VBUS是否5VD和D-在空闲状态下电压是否接近0V。如果D被拉高到3.3V说明上拉配置生效了Host端应该能检测到设备插入。软件侧优先确认USB时钟是不是48MHz。在调试器里看RCC寄存器确认PLL输出。APM32F072如果使用内部HSI做PLL源并且没有做校准USB枚举可能会时好时坏表现为设备管理器里反复刷新。如果枚举成功但驱动加载失败建议用Zadig检查设备接口类型。moonglow设备使用自定义类接口Zadig可能显示为“Unknown Device”或者“Interface 0”WinUSB驱动不一定匹配需要安装Kvaser专用驱动而不是通用WinUSB。6.2 CAN报文发不出去或收不到CAN收不到数据要先区分是MCU内部没收到还是外部物理层问题。把CAN外设设置为LoopBack模式这不经过收发器直接在MCU内部回环。如果LoopBack自测通过说明CAN控制器配置没问题问题出在外部收发器或总线连接。LoopBack自测代码思路初始化时让CAN工作模式为CAN_MODE_LOOPBACK发送一帧然后在接收中断里确认能收到同样的帧。能收到就说明CAN控制器路径OK。外部问题最常见的是收发器供电和电平不匹配。TJA1050需要5V供电检查有没有把VCC接到了3.3V或者直接悬空。CAN_H和CAN_L两根线是否接反TX和RX是否交叉接反。终端电阻有没有接上至少一侧要接120欧姆。用示波器看CAN_H和CAN_L之间的差分波形静态时CAN_H约2.5VCAN_L约2.5V显性位时CAN_H拉到3.5VCAN_L拉到1.5V。如果电平不对重点查收发器配置。6.3 波特率不准导致通信异常如果收发节点设备都正常但两边数据总是偶发错误帧十有八九是波特率设置和实际总线波特率不匹配。Kvaser驱动在应用层设置波特率后固件通过USB命令接收这个参数并重新计算CAN位时间。但有些固件实现里波特率表是写死的比如只支持500k、250k、125k。如果应用层设置了一个没写进表里的值固件可能计算出来的实际波特率跟你期望的差很远。排查方法就是先用CanKing明确设置500k同时让对端节点也用500k然后抓一帧报文看是否正常。还不对就在本地用逻辑分析仪抓CAN_TX引脚上的波形测量一位的时间宽度500kbps下一位应该是2微秒。根据实测位宽微调分频系数。6.4 APM32F072烧录保护与解锁技巧烧录过程中如果提示连接不上芯片先查读保护是不是被打开了。APM32F072和ST系列类似读保护设置后SWD只能执行全片擦除不能直接读Flash。用STM32CubeProgrammer连接时如果提示Read out Protection level 1点“Remove protection”执行全片擦除注意这会清掉Flash里的程序。擦除之后重新烧录新固件即可。我自己遇到过几次都是因为调试时不小心写了选项字节解决办法很简单但第一次遇到会慌。如果你手头只有OpenOCD也可以用reset halt命令先暂停芯片再操作。J-Link用户直接用J-Flash解锁最方便。6.5 踩坑记录与避坑建议汇总这次移植整体花了两天时间耗在USB枚举和CAN引脚配置上的时间各占一半。整理一份速查表以后再做类似项目可以直接对照排查。现象可能原因处理办法电脑完全无反应电源、晶振、DP/DM接错查VBUS测晶振波形对DP上拉枚举为未知设备驱动不匹配或描述符异常重装Kvaser驱动用UsbTreeView抓描述符枚举成功但CanKing打不开设备被其他进程占用关掉其他CAN软件重新插拔CAN LoopBack通过但外接不通收发器供电、接线、终端电阻查TJA1050电压测差分波形长时间运行自动掉线USB供电不足或时钟漂移换USB口外置供电检查HSI/PLL烧录提示读保护选项字节被改动全片擦除后重新烧录最后再分享一个我自己的习惯在USB-CAN这类工具上一定要板载一个串口或者LED指示否则固件跑到哪一步只能靠调试器单步去看效率太低。我在板子上加了一颗状态LEDUSB枚举成功拉高CAN总线打开拉低调试的时候一眼就能看出当前处于哪个状态。这个思路也可以沿用到你自己的项目里。项目的后续扩展空间其实很大。比如可以在固件里增加CANopen或者J1939的过滤解析功能配合上位机做协议分析也可以把这套兼容方案移植到GD32F303、AT32F413等其他国产MCU上成本还能进一步压低。嵌入式工具链就是这样一次把硬件和底层打通后面能玩的方向很多。