企业官网建设流程全解析

简介：《C620电调使用程序说明书1》是一份面向STM32嵌入式开发者与RoboMaster参赛者的PDF技术文档，围绕C620电调驱动M3508电机的Demo程序展开，重点说明PWM与CAN两种控制模式在RM主控板上的实现路径。文档从STM32F427主控、Keil5 μVision与STM32CubeMX/HAL开发环境切入，涵盖固件库安装、硬件连线、工程代码分层、FreeRTOS任务组织，以及CAN滤波器初始化、接收中断、PID参数整定与转速闭环、PWM脉宽调速和宏切换控制方式等关键内容。资源包仅含1个PDF文件，约905KB，篇幅紧凑，便于按章节查阅。已有3366人学习，适合希望理解电调通信协议、控制框架与调试要点的读者，可据此对照Demo程序梳理CAN/PWM控制流程、电流闭环与转速闭环差异，并留意接线互斥和动力电池供电等实践细节。

1. 先别急着插电：C620 电调 Demo 的安装顺序反着来会翻车

STM32 软件/插件这条线，最容易让人误判的地方，是把 STM32CubeMX 当成一个普通安装包，装完就以为环境齐了。C620 电调驱动 M3508 电机这套 Demo 环境，表面上是 Keil5 打开工程、点下载、按键调速，实际前面压着四层依赖：Java 运行库、CubeMX、对应系列的 HAL 固件包、Keil5 的器件支持包。任何一层缺了，现象都不是“报个明确错误”，而是 CubeMX 起不来、固件库勾选框不绿、生成代码缺外设驱动、编译到一半找不到头文件。更麻烦的是硬件侧还有一条硬规则：CAN 信号线和 PWM 信号线不能同时接，接错不会温柔提示，直接表现成电调控制失常。这套环境适合已经拿到主控开发板、C620 电调和 M3508 电机，想照着 Demo 把 CAN 与 PWM 两种控制方式都跑一遍的人；新手能按顺序走通，熟手更该关注固件包和宏切换这两个容易反复踩的点。

2. 环境清单与 CubeMX 安装：Java 运行库、Keil5 和 HAL 固件包缺一不可

我一般不会先开 CubeMX，而是先把机器上的依赖列清楚。这套 Demo 的控制板主控 MCU 是 STM32F427，开发环境是 Keil5，外设初始化代码由 STM32CubeMX 配合 STM32F4 系列 firmware package 生成。听起来是三个东西，实际安装时要按“Java 运行库 → CubeMX → 固件包 → Keil5 与器件支持包”的顺序走。顺序反了也能装，但排错时会多绕很多路，尤其是 CubeMX 双击没反应时，很多人第一反应是重装 CubeMX，实际是 JRE 没装好或者 PATH 里挂了多个 Java。

先把清单落成表，装之前逐项确认。下表里的“是否必需”不是建议，是这套 Demo 能生成、能编译、能下载的最低要求。

2.1 先过 Java 运行库这一关：CubeMX 打不开多半卡在这里

CubeMX 需要 Java 平台，原文写得很明确：确保已经安装好 JRE。这个“确保”不能靠感觉，装完一定要在命令行验证。Windows 下我通常开 PowerShell 或 CMD，执行两条检查：一条看 Java 能不能被调用，一条看当前用的是哪个 Java 路径。很多机器上装过多个 IDE，PATH 里残留了旧 Java，CubeMX 启动时就会卡住或者闪退。

# 检查 Java 是否可用，以及当前生效的 Java 路径 java -version where java

java -version输出的是当前命令行能调用的 Java 版本信息；where java在 Windows 下会列出 PATH 中所有 java.exe 的位置。如果第一条命令报“不是内部或外部命令”，说明 JRE 没装或者没进 PATH；如果where java列出多个路径，优先保留与 CubeMX 安装说明匹配的那个，别让旧版本抢在前面。装 JRE 时我一般不改默认安装路径，装完重启一次命令行窗口再验证，避免环境变量没刷新。

提示：CubeMX 安装包和 JRE 是两件事，装完 CubeMX 不等于 Java 就绪。先验证java -version，再双击 CubeMX，能少走一大截弯路。

2.2 CubeMX 下载与安装：官网账号、安装路径和首次启动

CubeMX 从芯片厂商官网的下载页获取，下载页需要登录账号，没有就注册。原文提到如果觉得麻烦可以找网上资源，我的习惯是优先走官网，原因是版本和安装包来源清楚，后面固件库导入出问题时不至于怀疑安装包本身。下载时注意页面中间偏下的 EMBEDDED SOFTWARE 区域，那里放的是各系列 HAL 固件库包，不是 CubeMX 本体；CubeMX 本体在页面靠下的下载入口。两样东西别混在一起下。

安装路径我一般选一个不带空格、不带中文的目录，比如C:\Tools\STM32CubeMX。不是玄学，是后面生成工程、导入 zip 包、Keil5 编译时，路径里带空格容易在脚本和命令行环节出问题。安装完成后首次启动会提示固件库路径，这个路径也建议固定，不要每次换目录。CubeMX 的固件库默认仓库位置可以在Help -> Updater Settings里看，记住它，后面from local导入 zip 包时知道文件最终落在哪。

# 安装目录和固件库仓库目录的常见检查方式 # 确认 CubeMX 安装路径没有空格和中文 echo %PATH% # 如果自定义了固件库仓库，进入该目录看是否有 STM32Cube_FW_F4 类似文件夹 dir C:\Users\你的用户名\STM32Cube\Repository

上面两条不是必须执行，只是我装完后的确认动作。echo %PATH%看环境变量里有没有异常路径；dir看固件库仓库是否已经建立。仓库目录一开始可能是空的，导入固件包后才会出现对应系列文件夹。路径里出现中文用户名不一定会立刻出问题，但一旦 Keil5 编译报路径错误，先把工程挪到纯英文路径下验证，是最快的排除法。

2.3 Keil5 与器件支持包：别等编译报错才补

Keil5 装好后，常见做法是顺手把 STM32F4 系列的器件支持包装上。原文没有展开这一步，但只装 Keil5 本体，打开工程时可能识别不到具体器件，或者编译时缺启动文件。Keil5 里通过 Pack Installer 安装对应系列支持包，装完在器件列表里能选到 STM32F427。这个步骤不需要和 CubeMX 同时做，但建议在生成工程前完成，避免工程生成后打不开。

Keil5 的安装路径同样建议纯英文。有人把工程放在桌面，桌面路径里带中文用户名，编译时由于中间文件路径过长或者编码问题报错，最后误判成代码问题。我的做法是固定一个工作目录，比如D:\work\c620_demo，CubeMX 生成工程、Keil5 打开工程、后续加 BSP 文件都在这个目录下完成。这样出问题时只看一个路径，不用满盘找工程。

注意：Keil5 的器件支持包和 CubeMX 的 HAL 固件包不是同一个东西。前者让 IDE 认识芯片，后者提供外设驱动源码，两个都得有。

3. 固件库导入与工程生成：从 zip 包到 Keil5 工程目录

固件库这一步是整套环境里最容易“看起来装了、实际没装”的环节。原文给的操作路径很清楚：下载好固件库 zip 包，打开 CubeMX，依次点Help -> Install New Libraries -> From Local，选择 zip 包打开。安装成功后，左侧对应器件系列固件库版本号的 checkbox 会变成绿色。注意原文的提醒：必须装 pack，不能只安装 CubeMX，因为各系列 pack 里才有该系列的外设驱动代码，否则无法生成初始化代码。这个 checkbox 不绿，后面生成工程一定缺驱动。

3.1 固件包导入：选 zip 包，不要先解压再指目录

我见过有人把固件库 zip 解压后，在From Local里选解压出来的文件夹，结果 CubeMX 不认。这个入口要的是原始 zip 包，直接选 zip，让 CubeMX 自己解包到仓库目录。导入时如果网络安装慢，可以用 local 方式；如果 local 也失败，先确认 zip 包完整，没有被浏览器改过后缀，也没有在下载过程中中断。

# 导入后检查固件库仓库的常见目录结构 # 这里只看目录名，不要求版本号一致 dir C:\Users\你的用户名\STM32Cube\Repository # 预期能看到类似 STM32Cube_FW_F4_Vx.x.x 的文件夹

这段检查的作用是确认 zip 包确实被 CubeMX 解到了仓库里。STM32Cube_FW_F4_Vx.x.x里的Vx.x.x是版本号，不同时间下载的包版本可能不同，不用强求一致。关键是左侧固件库列表里 F4 系列那一行的 checkbox 变绿。变绿代表 CubeMX 能索引到该系列的外设驱动，生成工程时才会把 HAL 驱动带进去。如果导入后没变绿，先重启 CubeMX；还不行就删掉仓库里半截目录重新导入，别在工程生成阶段反复试。

提示：只装 CubeMX 不装固件包，新建工程时也能走到生成那一步，但生成出来的工程会缺外设驱动。后面 Keil5 编译报一堆头文件找不到，根因就在这一步。

3.2 新建工程：选 STM32F427、开 FreeRTOS、配 CAN 和 TIM5 PWM

新建工程时选对器件是第一步。主控 MCU 是 STM32F427，选错系列后面固件包、启动文件、外设寄存器都对不上。时钟配置按主控板实际晶振和需要的系统频率来，原文没有给具体时钟树参数，我不在这里编具体数值；原则是先把时钟源和调试接口配通，再开外设。调试接口建议保留，不然后面下载一次锁一次很麻烦。FreeRTOS 要勾选，原文说明勾选后 CubeMX 生成的工程已经移植好 FreeRTOS，控制代码放在freertos.c的StartDefaultTask函数里。

外设侧要开三块：CAN1 用于 CAN 控制模式，TIM5 用于 PWM 信号输出，GPIO 用于按键输入。CAN 模式接的是 CAN1 信号端口，PWM 模式接的是主控板上标注的 PWM 端口 C1、C2、C3 或 C4，原文示例使用 TIM5 作为 PWM 信号端口。具体引脚以主控板引脚示意图为准，原文提到 TIM5 作为 PWM 信号端口时引脚在主控板圈红处，接线时对着图找，不要凭记忆。CAN 波特率、滤波器参数按电调说明书和工程实际配置，原文没有给具体值，我不写死；但生成工程前要把 CAN 接收中断打开，否则后面读不到电机转速。

# 生成工程后的目录结构大致检查 cd D:\work\c620_demo dir # 预期能看到 Core、Drivers、Middlewares、MDK-ARM 等目录

这个目录结构不是让你手工创建，而是生成后用来确认 CubeMX 有没有把 HAL 驱动、FreeRTOS、CMSIS 内核层和 Keil5 工程文件带出来。Core下放用户代码和freertos.c，Drivers下是 HAL 和 CMSIS，Middlewares下是 FreeRTOS，MDK-ARM是 Keil5 工程入口。如果Drivers里空得离谱，或者MDK-ARM没生成，多半是固件包没装好或者生成时 Toolchain 没选 MDK-ARM。

3.3 生成 Keil5 工程：Toolchain 选 MDK-ARM，代码分组按 BSP 加

生成工程时 Toolchain 选 MDK-ARM，也就是 Keil5 能打开的工程格式。生成后先别急着加自己的代码，先打开工程编译一次空工程，确认工具链、器件支持包、启动文件都正常。这一步很多人跳过，后面加完 BSP 和 PID 再编译，报错分不清是环境问题还是代码问题。空工程能过，说明 CubeMX、固件包、Keil5 三者已经对齐。

工程里原文已经按功能分组，示例 Demo 添加了一个 BSP 组，用来放用户自己的代码文件。BSP 组里加bsp_can.c/h、pid.c/h等文件。bsp_can主要负责 CAN 滤波器初始化、按格式接收与发送、RX 接收中断；pid包含 PID 参数初始化和计算函数。控制代码放在freertos.c的StartDefaultTask里，通过宏定义CAN_CONTROL和PWM_CONTROL切换控制方式。这个分组方式很实用：HAL 驱动是生成的，BSP 是自己的，PID 是算法层，FreeRTOS 任务只做调度和模式切换，出了问题按层排查。

这张表建议在加代码前对照一遍。BSP 组不是 CubeMX 自动生成的业务分组，需要手动建组、加文件、把 include 路径补进 Keil5。bsp_can.c里用到 HAL CAN 接口，头文件路径要能找得到；pid.c如果只做纯计算，依赖会少一些。加完文件先编译，不要等全部逻辑写完再统一编译，错误堆在一起很难定位。

4. 硬件接线与 BSP 配置：CAN1、TIM5 PWM 和 PID 文件怎么落位

硬件接线是这套 Demo 里最不能“先随便接，不行再换”的部分。原文给了一条硬约束：不允许同时连接 CAN 信号线和 PWM 信号线，否则会导致电调控制失常。我一般会在桌上先把两种模式的线分开摆，CAN 模式只拿 2-Pin CAN 信号线，PWM 模式只拿 3-Pin PWM 信号线，避免手上抓着两根线顺手都插上去。C620 电调的三相输出线（3 色）和 7-Pin 数据线（黑色）先连接 M3508 电机，这一步两种模式都一样。

4.1 接线先定模式：CAN1 与 TIM5 PWM 只能二选一

CAN 控制方式的连接是：CAN 信号线（2-Pin）分别连接电调和主控开发板的 CAN1 信号端口，C620 电调的 PWM 信号端口不接。PWM 控制方式的连接是：PWM 信号线（3-Pin）分别连接电调和主控开发板，接主控板上标注的 PWM 端口 C1、C2、C3 或 C4，C620 电调的 CAN 信号端口不接。电源线（黑色）接主控开发板的 24V 电源端口。仔细检查接线后，再为主控板供 24V。

这张表建议接线时放在手边。CAN 和 PWM 是二选一，不是“都接上更稳”。同时接的后果原文写得很直接：电调控制失常。表现可能是电机不转、乱转、按键无响应，甚至电调进入保护。遇到这种情况先断电，把另一根信号线拔掉，再按当前模式检查，不要带电插拔信号线。

注意：供电建议用动力电池。原文特别提醒，如果使用电源箱，可能因电机反电动势过高，造成主控开发板中做电源保护的二极管被击穿。这个坑不是配置能救的，属于电源侧硬损伤。

4.2 BSP 分组：bsp_can.c/h 和 pid.c/h 怎么放、怎么加进 Keil5

BSP 组是用户代码的落脚点。我的习惯是在工程根目录下建BSP文件夹，把bsp_can.c/h、pid.c/h放进去，然后在 Keil5 里新建同名 Group，把.c文件加进去，再把BSP路径加到 Include Paths。这样 CubeMX 重新生成代码时，BSP 文件不会被覆盖；HAL 和 FreeRTOS 是生成层，BSP 是用户层，PID 是算法层，层次清楚，后面切 CAN/PWM 只改任务层和宏。

bsp_can.c里主要做三件事：CAN 滤波器初始化、按格式接收与发送、RX 接收中断。CAN 控制模式下，电调对电机是电流闭环控制，所以程序需要从电调获取电机转速，并增加电机转速 PID 调节控制。pid.c里做 PID 参数初始化和计算函数。PWM 控制模式下，电调对电机是转速闭环控制，只需要给定符合标准的 PWM 信号，PWM 脉宽决定电机转速，不需要在程序里再做转速 PID。这个差异决定了两种模式的代码路径不一样，不能只改一个宏却沿用同一套闭环逻辑。

/* bsp_can.c 里的 CAN 滤波器初始化与接收中断骨架，参数按工程实际配置 */ void BSP_CAN_Init(void) { CAN_FilterTypeDef filter = {0}; filter.FilterBank = 0; /* 滤波器组编号，按工程分配 */ filter.FilterMode = CAN_FILTERMODE_IDMASK; filter.FilterScale = CAN_FILTERSCALE_32BIT; filter.FilterIdHigh = 0x0000; /* 按电调说明书填写接收 ID 相关值 */ filter.FilterIdLow = 0x0000; filter.FilterMaskIdHigh = 0x0000; /* 掩码决定哪些位参与匹配 */ filter.FilterMaskIdLow = 0x0000; filter.FilterFIFOAssignment = CAN_RX_FIFO0; filter.FilterActivation = ENABLE; HAL_CAN_ConfigFilter(&hcan1, &filter); HAL_CAN_Start(&hcan1); HAL_CAN_ActivateNotification(&hcan1, CAN_IT_RX_FIFO0_MSG_PENDING); } /* RX 接收中断里读电调回传的转速，具体帧格式按电调说明书解析 */ void HAL_CAN_RxFifo0MsgPendingCallback(CAN_HandleTypeDef *hcan) { CAN_RxHeaderTypeDef rx_header; uint8_t rx_data[8]; if (HAL_CAN_GetRxMessage(hcan, CAN_RX_FIFO0, &rx_header, rx_data) == HAL_OK) { /* 在这里按 ID 和字节序解析电机转速，供 PID 计算使用 */ } }

这段代码是骨架，不是可直接烧录的完整业务。FilterBank、FilterIdHigh/Low、FilterMaskIdHigh/Low必须按 C620 电调说明书和工程实际 ID 配置，原文没有给具体 ID，我不在这里编。FilterMode和FilterScale决定滤波器匹配方式；FilterFIFOAssignment指定接收 FIFO；FilterActivation使能滤波器。中断回调里先取帧头和 8 字节数据，再按协议解析转速。CAN 控制模式下，转速解析不对，PID 输出就会乱，所以先确认接收中断能进、帧能收到，再调 PID 参数。

4.3 StartDefaultTask 里的 10ms 闭环：宏切换和 PID 输出

原文的 CAN 控制流程是：系统初始化、PID 参数初始化、CAN 初始化、速度闭环 PID 计算、10ms 等待，期间按键修改目标速度，PID 计算结果输出到电调，CAN 中断服务程序读取电机转速。PWM 控制则简单得多：给定符合标准的 PWM 脉宽，按键改变转速。代码上我一般把两种模式放在StartDefaultTask里，用#define CAN_CONTROL和#define PWM_CONTROL二选一，不要两个宏同时打开。

/* freertos.c 中的控制模式宏，二选一，不要同时定义 */ #define CAN_CONTROL /* #define PWM_CONTROL */ void StartDefaultTask(void *argument) { /* 系统初始化、PID 参数初始化、CAN 初始化按顺序放这里 */ PID_Init(); BSP_CAN_Init(); for (;;) { if (key_pressed()) { target_speed += 100; /* 按键调速步长按实际手感调整 */ } #ifdef CAN_CONTROL /* CAN 模式：电调做电流闭环，程序侧做转速 PID */ int16_t speed = BSP_CAN_GetSpeed(); int16_t current = PID_Calc(target_speed, speed); BSP_CAN_SendCurrent(current); #elif defined(PWM_CONTROL) /* PWM 模式：电调做转速闭环，程序侧只给标准脉宽 */ BSP_PWM_SetPulse(target_speed); #endif osDelay(10); /* 10ms 周期，原文流程中的等待时间 */ } }

这段代码的重点不是照抄，而是看清两个宏对应的控制责任不同。CAN_CONTROL下，电调对电机是电流闭环，程序要从电调读转速并做转速 PID，PID 输出再发给电调；PWM_CONTROL下，电调自己完成转速闭环，程序只要给符合标准的 PWM 脉宽。osDelay(10)对应原文的 10ms 等待，周期改太小会加重总线负载，改太大调速响应变慢。按键步长100只是示例，实际按电机和负载调，别一上来给满。PID_Init()里要设好比例、积分、微分参数和输出限幅，限幅不设，目标速度和实际转速差一大，输出容易顶到边界。

提示：切宏之前先断电或至少让电机停转，改完宏重新编译下载。只在代码里切宏、硬件线没跟着换，等于 CAN 模式接着 PWM 线，现象就是电调不按预期响应。

5. 避坑排查：电调不转、固件包变灰、CAN 无回传的五个现场

这套环境的坑有一个共同点：表面现象都像代码问题，根因却在安装、接线或宏切换。下面五条是我装这类环境时最常遇到的现场，按“现象 → 原因 → 解决”记，出问题时对照看，比从头翻文档快。

5.1 现象：CubeMX 双击没反应或启动卡住；原因：JRE 没装好或 PATH 冲突；解决：先命令行验证 Java

现象很典型：双击 CubeMX 图标，鼠标转一圈就没动静；或者启动画面卡住，任务管理器里有进程但界面不出来。原因八成是 JRE 没装、装完没进 PATH，或者机器上多个 Java 版本打架。解决顺序是先开命令行执行java -version，报错就装 JRE；能出版本但 CubeMX 还卡，就执行where java看路径，把多余 Java 从 PATH 里挪走，保留一个能用的。装完 JRE 重启命令行和 CubeMX，别在进程管理器里反复结束进程硬开。

5.2 现象：固件库 checkbox 不绿；原因：只装 CubeMX 没装 pack，或 zip 包选错；解决：From Local 选原始 zip

CubeMX 左侧对应系列固件库版本号的 checkbox 不绿，新建工程也能走，但生成出来缺驱动。原因通常是只装了 CubeMX，没有导入对应系列 firmware package；或者导入时选了解压后的文件夹，CubeMX 不认。解决是走Help -> Install New Libraries -> From Local，选原始 zip 包，不要先解压。导入后重启 CubeMX 看 checkbox 是否变绿。还不行就查仓库目录里有没有半截文件夹，删掉重导。原文说得很清楚：必须装 pack，不能只安装 CubeMX。

5.3 现象：Keil5 编译报外设驱动头文件找不到；原因：固件包没装全或工程没重新生成；解决：补 pack 后重新生成工程

编译时一堆stm32f4xx_hal_xxx.h找不到，或者 CAN、TIM 的 HAL 文件缺失。原因不是 Keil5 抽风，而是 CubeMX 生成工程时固件包没索引到，或者外设开了但对应驱动没带出来。解决是先确认固件库 checkbox 绿色，再回 CubeMX 重新生成一次工程，Toolchain 仍然选 MDK-ARM。重新生成后 Keil5 里重新加载工程，必要时 Clean 再 Build。不要手工往Drivers里拷头文件，拷漏一个又得重来。

5.4 现象：电机不转、电调报警或按键无响应；原因：CAN 与 PWM 同时接、线序错、脉宽不标准或电源不对；解决：断电二选一，按模式查线

这个现场最像“程序没跑起来”，实际先查硬件。原因可能是 CAN 信号线和 PWM 信号线同时接了，原文明确不允许；也可能 CAN 线序反了、PWM 脉宽不在标准范围、电源带不动。解决是断电，拔掉当前模式不用的那根信号线，CAN 模式只留 CAN1，PWM 模式只留 C1-C4 其中一路，再查电源是不是动力电池。用电源箱供电导致主控板电源保护二极管被击穿的情况，原文专门提醒过，别用电源箱硬顶。PWM 脉宽用逻辑分析仪或示波器看，比反复改代码快。

5.5 现象：CAN 模式能发不能收，转速读不到；原因：滤波器、波特率、接收中断或 ID 不匹配；解决：先通中断再对协议

CAN 控制模式下电机能动但转速读不到，PID 没有反馈，调速就会发飘。原因常见的是滤波器配置把回传帧滤掉了、波特率与电调不一致、RX 接收中断没使能，或者收发 ID 按错。解决顺序是先确认HAL_CAN_ActivateNotification使能了 RX FIFO0 中断，再在回调里打断点或翻转 GPIO 看有没有进中断；进了中断再核对波特率和 ID。不要一上来调 PID 参数，反馈链路没通，调参数是黑匣子。

注意：排查时每次只改一个变量。先断电改接线，再上电看现象；或者先改宏再编译下载。一次改接线又改代码，最后不知道是哪一步生效。

6. 装完怎么验证：用按键调速和串口日志确认双模式跑通

验证我一般分两步：先验环境，再验控制。环境验证不接电机也能做：Keil5 能编译空工程、能下载、按键能读到变化，说明 CubeMX、固件包、Keil5、下载链路都通了。控制验证再按模式接电调和电机，PWM 模式先给低脉宽看电机是否缓慢转，CAN 模式先看接收中断有没有回传，再开 PID。下面这张表是我上电前会逐项打勾的验证表，失败时直接看“失败先看哪里”。

验证宏有没有切错，我习惯在编译前用一条命令查freertos.c里两个宏的定义状态。不是必须，但比打开文件肉眼找快，尤其是工程放久了忘了上次切到哪个模式。

# 在工程根目录检查控制模式宏，确认 CAN_CONTROL 和 PWM_CONTROL 只开一个 grep -n "define CAN_CONTROL\|define PWM_CONTROL" Core/Src/freertos.c

grep -n会带行号输出匹配行。预期结果是其中一个宏被定义，另一个被注释掉。如果两个都出现且都没注释，说明宏切换漏了，先改再编译。Windows 环境没有 grep 的话，用编辑器全局搜索也一样，目的就是确认“宏二选一”和“接线二选一”对得上。

最后一步是听声音和看响应。PWM 模式给一个较小脉宽，电机应该能缓慢起转，按键加速时转速变化连续，没有突然堵转或电调反复重启。CAN 模式先不接负载，按键给目标速度，观察回传转速是否跟随；跟随太慢先查 10ms 周期和 PID 限幅，跟随抖动先查转速解析和滤波器。验证完一种模式，断电，换线，改宏，再验另一种，不要带电切换。

从那以后我每次上电前都强制走一遍“接线二选一、宏二选一、电源是不是动力电池”这三项检查，哪怕前一天刚跑通过。这套 C620 电调 Demo 的环境搭建不难，难在依赖层次多、硬件约束硬，按顺序装、按层排查，基本都能跑通。希望帮到你。需要这份 C620 电调 Demo 程序说明的，可以在资源页按文件名取用，里面把 CubeMX 配置、BSP 分组和双模式宏切换放在了一起，照着对一遍比到处翻零散截图省事。

本文还有配套的精品资源，点击获取