Zephyr CANopenNode示例项目在STM32G0B1RE上的存储配置与CAN通信故障排查请求

嘿，我来帮你一步步拆解并解决STM32G0B1RE上Zephyr CANopenNode遇到的这两个头疼问题：存储配置失败和CAN通信发送报错。先理清楚背景：你已经在CubeMX环境下验证了CAN通信的读写正常，切换到Zephyr的CANopenNode示例后，因为STM32G0B1RE没有片内EEPROM，触发了存储写入失败；改Flash分区和ROM存储后还是不行，换RAM存储又出现CAN发送错误（err -114）。下面逐个解决：

一、搞定CANopenNode的Flash存储配置（替代缺失的EEPROM） #

首先得明确：Zephyr版的CANopenNode并没有直接依赖硬件EEPROM，它是通过Zephyr Settings子系统来模拟CANopenNode里的“EEPROM”存储区域的。所以核心是让Settings子系统正确挂载到你定义的Flash分区上，步骤如下：

1. 完善prj.conf的存储相关配置
   打开项目的prj.conf，添加/修改这些配置，确保Settings子系统和Flash存储正常工作：

   # 启用Settings子系统，用于CANopen存储
   CONFIG_SETTINGS=y
   CONFIG_SETTINGS_FLASH=y
   # 指定我们在DTS里定义的storage分区
   CONFIG_SETTINGS_FLASH_PARTITION="storage"
   # 启用CANopen存储功能，禁用EEPROM（因为芯片没有）
   CONFIG_CANOPENNODE_STORAGE=y
   CONFIG_CANOPENNODE_STORAGE_EEPROM=n
   CONFIG_CANOPENNODE_STORAGE_ROM=y
   # 允许Flash写入（STM32G0的MPU默认限制）
   CONFIG_MPU_ALLOW_FLASH_WRITE=y
   # 确保Flash驱动启用
   CONFIG_FLASH=y
   

2. 修正代码里的存储调用逻辑
   原示例代码里调用的是canopen_storage_save(CANOPEN_STORAGE_EEPROM)，现在我们用Flash（对应CANopen的ROM存储类型），所以要改成：

   #ifdef CONFIG_CANOPENNODE_STORAGE
   ret = canopen_storage_save(CANOPEN_STORAGE_ROM);
   if (ret) {
       LOG_ERR("failed to write to Flash storage");
   }
   #endif /* CONFIG_CANOPENNODE_STORAGE */
   

3. 验证DTS分区配置的正确性
   你已经定义了storage_partition，这里再确认几个细节：

   • 分区的reg地址和大小要和STM32G0B1RE的Flash布局匹配（G0B1RE有128KB Flash，你的分区最后32KB给storage是合理的）
   • 确保分区的label是storage，和CONFIG_SETTINGS_FLASH_PARTITION的配置一致

如果只是想先验证CAN通信，也可以暂时关闭存储功能（CONFIG_CANOPENNODE_STORAGE=n），这样就不会再弹出存储失败的报错，先把通信问题解决了再回头调存储。

二、解决CAN发送错误（err -114 = -EBUSY） #

错误码-114对应的是EBUSY，意思是CAN总线忙、发送队列满，或者CAN控制器没有正确初始化。结合你在CubeMX上能正常通信，大概率是Zephyr的FDCAN配置有问题，排查步骤：

1. 确认FDCAN的时钟和波特率配置
   STM32G0的FDCAN时钟源配置要和实际硬件匹配，同时确保波特率和PC端脚本一致：

   • 在prj.conf里添加：

     CONFIG_CAN_BITRATE=500000  # 和你的PC端脚本波特率保持一致
     CONFIG_CANOPENNODE_BITRATE=500000
     CONFIG_CANOPENNODE_NODE_ID=1  # 节点ID也要和PC端匹配
     

   • 修正DTS里的FDCAN时钟配置（简化成Zephyr标准写法）：

     &fdcan1 {
         clocks = <&rcc STM32_CLOCK_BUS_APB1 0x00001000>,
                  <&rcc STM32_SRC_PLL_Q FDCAN_SEL(1)>;
         pinctrl-0 = <&fdcan1_rx_pc4 &fdcan1_tx_pc5>;
         pinctrl-names = "default";
         status = "okay";
         bus-speed = <500000>;
     };
     

2. 检查CAN收发器的引脚配置
   虽然CubeMX里正常，但Zephyr的引脚默认配置可能有差异，比如RX引脚的上拉：
   在DTS里给FDCAN引脚添加电平配置：

   &fdcan1_rx_pc4 {
       bias-pull-up;  // CAN RX引脚通常需要上拉
   };
   &fdcan1_tx_pc5 {
       bias-push-pull;
   };
   

3. 启用详细日志排查
   打开更详细的CAN和CANopen日志，方便定位问题：

   CONFIG_CAN_DEBUG=y
   CONFIG_CANOPENNODE_LOG_LEVEL_DBG=y
   CONFIG_LOG_LEVEL_DBG=y
   

   这样你能看到CAN控制器的初始化状态、错误帧信息，以及CANopen节点的初始化流程，更容易找到总线忙的原因。

4. 为什么用RAM存储会出问题？
   你切换到CANOPEN_STORAGE_RAM后出现CAN发送错误，是因为RAM存储的CANopen配置会在节点初始化时无法加载正确的参数（比如节点ID、波特率、对象字典默认值），导致CANopen节点没有正常进入运行状态，CAN发送队列被阻塞，最终触发EBUSY错误。RAM存储只适合临时测试，完全不适合固件升级场景，所以一定要用Flash存储。

三、最后总结的解决流程 #

1. 先关闭存储功能（CONFIG_CANOPENNODE_STORAGE=n），确保CAN通信能正常工作，排除硬件和FDCAN配置问题；
2. 等CAN通信正常后，再启用存储功能，配置Settings子系统挂载到Flash分区，修正存储调用的参数；
3. 测试存储功能，确认对象字典能正确保存到Flash，重启后能正常加载；
4. 最后再集成MCUboot的CAN升级功能（确保MCUboot也能访问同一个Flash分区）。

内容来源于stack exchange