RH850F1L CAN速率动态切换：位时序与采样点的配置实战

简介：这是一份面向Renesas RH850/F1L芯片开发者的CAN通信速率切换驱动示例。RH850/F1L是瑞萨汽车级32位MCU，内部集成多路CAN控制器，最多支持6路CAN通道。本例演示同一通道先以1Mbps建立通信，再由软件切换为125kbps继续收发，完整覆盖了CAN位定时配置、速率切换流程以及收发缓冲区的处理思路，既适合嵌入式软件工程师参考，也可作为单片机学习者的进阶练习。资源共18个文件，压缩包仅71KB，以C源码、头文件和汇编文件为主体，另含CubeSuite+工程文件、链接脚本、地址映射文件、MOT烧录文件及Object中间文件，并附有ReadMe说明文档；打开工程后可直接查看初始化、中断处理与收发缓冲实现。已有274人浏览下载，适合需要快速理解RH850/F1L CAN模块初始化、速率动态调整与收发逻辑的开发者。

1. 从压缩包名看RH850F1L的CAN速率切换场景

看到6SD_RH850F1L_CAN(SpeedChange_1M_125k).7z这个文件名，第一反应是：工程代号、主控型号、外设、运行参数全被写进命名里了。RH850F1L 是瑞萨面向车身控制、网关和 BMS 常用的 32 位 MCU，CAN 控制器支持多通道和灵活的位时序配置，而SpeedChange_1M_125k意味着程序要在运行过程中把 CAN 总线从 1Mbps 切到 125kbps，或者反向切回来。这种场景最常见于 Bootloader：低速 125k 做引导和握手，高速 1M 做固件批量升级；也见于产线标定，低速模式下保证长线缆通信可靠，运行阶段切到高速。多数人在这个需求上卡住，不是因为 CAN 驱动不会写，而是位时序参数怎么配、切换瞬间总线上会发生什么、切换后如何确认两边真的在同一条速率上。下面按理论、实现、踩坑、验证的顺序把这条链路完整讲清楚。

2. RH850F1L的CAN位时序：把1M和125k放进同一个采样点

2.1 先分清CAN相关的三个时钟：PCLK、fCAN、TQ

RH850F1L 的 CAN 模块虽然挂在 APB 总线上，但总线上的位时间精度不依赖 CPU 主频，而是由 CAN 协议时钟fCAN决定。fCAN通常由外设时钟 PCLK 经过 CAN 控制器的预分频器产生。很多第一次调 RH850 的人直接拿 80MHz 系统主频去算，结果怎么都对不上，因为 PCLK 往往单独配置，且 CAN 模块内部还有一级分频。

先确认 PCLK 的实际值。在 CS+ 或 EB 的时钟配置界面里看 PCLK 的分配比，然后用下面的公式计算：

fCAN = PCLK / (BPR + 1)

BPR是波特率预分频寄存器的写入值。这一步错了，后面所有采样点都是白算。CAN 协议规定一个位由多个最小时间单元 TQ 组成，RH850 的 CAN 控制器把每一位拆成同步段、传播段、相位缓冲段 1 和相位缓冲段 2。同步段固定消耗 1 个 TQ，寄存器TSEG1的写入值加 1 才是相位段 1 的实际 TQ 数，TSEG2同理。位时间的总 TQ 数由下面的公式决定：

bit_time_tq = 1 + (TSEG1 + 1) + (TSEG2 + 1) 波特率 = fCAN / bit_time_tq 采样点 = (1 + TSEG1 + 1) / bit_time_tq

注意，SJW（同步跳转宽度）不参与位时间长度计算，它只决定硬件在做再同步时最多能调整几个 TQ。采样点的位置完全取决于 TSEG1 和 TSEG2 的配比，这也是本文后面反复强调“采样点统一到 80%”的原因。

2.2 TSEG1/TSEG2/SJW在RH850里到底要写多少

RH850F1L 的 CAN 模块在瑞萨文档里通常被称为 RSCAN。不同子型号对寄存器的命名略有差异，有的手册里写成nCFG1、nCFG2，有的直接叫nSEG1、nSEG2，但字段含义一致。下面以CAN0_BRPR、CAN0_SEG1、CAN0_SEG2、CAN0_SJW为例，换成你工程里实际的寄存器宏即可。

TSEG1 留得长，采样点会后移，能吸收更长的总线传播延迟，但太靠后又会让 TSEG2 没有足够裕量；TSEG2 太短，SJW 就没有空间做再同步。SJW 只在检测到相位误差时才起作用，不影响正常采样点位置。实际配置中，SJW 建议不小于 1，且必须小于等于 TSEG2。经典 CAN 和 CAN FD 的采样点计算公式不同，RH850F1L 在不启用 CAN FD 时按经典 CAN 算，不要拿 CAN FD 帧内速率切换的概念往这里套。

2.3 20TQ方案：两档速率共用同一组段参数

以fCAN = 20MHz为例，1Mbps 下每位正好 20 个 TQ。如果直接把 20MHz 拿去做 125kbps，位时间会变成 160TQ，虽然也能工作，但采样点的调整步长变得很粗，且切换时 TSEG1/TSEG2/SJW 全都要跟着换。更合理的做法是：125k 时把预分频改成 8，fCAN降到 2.5MHz，位时间又回到 20TQ。

这个方案的收益很大：两个速率的位时间都是 20TQ，段参数完全一致，采样点完全相同，切换时只需要改 BPR 一个值。1M 和 125k 的 TQ 宽度不同，但每一位的相位组成比例一样，对端节点只要同样使用 80% 采样点，两边在任意一档速率下都能对齐。

用一段 Python 快速验证参数：

def bit_timing(bpr, tseg1, tseg2, pclk=20_000_000): fcan = pclk // (bpr + 1) tq_total = 1 + (tseg1 + 1) + (tseg2 + 1) baud = fcan // tq_total sample_point = (1 + tseg1 + 1) / tq_total return baud, sample_point # 1Mbps: 预分频1, TSEG1写14, TSEG2写3 print(bit_timing(0, 14, 3)) # (1000000, 0.8) # 125kbps: 预分频8, TSEG1写14, TSEG2写3 print(bit_timing(7, 14, 3)) # (125000, 0.8)

输出显示两档速率下采样点都是 0.8。如果 PCLK 不是 20MHz，比如 40MHz，把 BPR 改成 1 得到fCAN = 20MHz，结论不变。核心思想是：先把 PCLK 分频到合适的 CAN 协议时钟，再让两个目标速率的位时间都落在整数个 TQ 上，段参数只在初始化时写一次。

3. CAN波特率切换的最小实现：换BPR而不是换段参数

3.1 先定义波特率配置表

在实际工程里，我习惯把位时序参数做成结构体表，而不是散落在切换函数里的魔法数字。新增一档速率只需要往表里加一行，逻辑分支也被统一成查表。

typedef struct { uint32_t baud; /* 目标波特率，单位 bps */ uint8_t bpr; /* 预分频写值，实际分频 = BPR + 1 */ uint8_t sjw; /* 同步跳转宽度，实际 TQ = SJW + 1 */ uint8_t tseg1; /* 相位段1，实际 TQ = TSEG1 + 1 */ uint8_t tseg2; /* 相位段2，实际 TQ = TSEG2 + 1 */ } can_timing_t; /* 基于 fCAN = 20MHz，位时间 20TQ，采样点 80% */ static const can_timing_t can_timing_table[] = { { 1000000u, 0u, 1u, 14u, 3u }, /* 1Mbps */ { 125000u, 7u, 1u, 14u, 3u }, /* 125kbps */ };

1M 档的分频系数为 1，TQ 宽度 50ns；125k 档分频系数为 8，TQ 宽度 400ns。两者位时间都是 20TQ，采样点都是 80%。注意表中的sjw写入 1，实际是 2 个 TQ。1M 下 2 个 TQ 只有 100ns，配合 20ppm 晶振和 5m 以内的短总线足够；125k 下 2 个 TQ 等于 800ns，容错很充裕。

3.2 核心切换函数：先进初始化模式再改分频

CAN 控制器的位时序寄存器不允许在通信过程中直接改。常见做法是先请求进入初始化模式，停止当前帧的收发，确认硬件完成状态切换后再改写寄存器，最后退出初始化模式。

static uint8_t CAN_SetBitTiming(const can_timing_t *tbl) { /* 请求进入初始化模式：停止收发，释放总线 */ CAN0_CTR.INIT = 1u; /* 等待控制器确认进入初始化，避免总线上有错误帧时卡死 */ uint32_t timeout = 10000u; while (timeout-- > 0u) { if (CAN0_STR.INIT == 1u) break; } if (CAN0_STR.INIT == 0u) { return 1u; /* 进入初始化超时 */ } /* 初始化模式下改写位时序参数 */ CAN0_BRPR = tbl->bpr; CAN0_SEG1 = tbl->tseg1; CAN0_SEG2 = tbl->tseg2; CAN0_SJW = tbl->sjw; /* 退出初始化模式 */ CAN0_CTR.INIT = 0u; while (CAN0_STR.INIT != 0u) { /* 等待硬件重新进入正常模式 */ } return 0u; }

INIT = 1之后，控制器会等当前帧结束或总线空闲才真正进入初始化，所以必须轮询CAN0_STR.INIT而不是直接睡固定时间。如果总线上存在持续错误帧，INIT 请求可能一直得不到确认，超时判断在这里是必需的。退出初始化模式时，硬件会重新锁存 BRPR、SEG1、SEG2、SJW 的值，并且错误计数器会被复位。写入时先写 BPR 再写段参数，或反过来都行，因为初始化模式下控制器不采样总线，新配置不会生效，直到 INIT 被清 0。

3.3 通知帧加延时：让对端和你同时换挡

动态切换波特率在单节点自测时看不出问题，一旦上了真实总线，收发双方必须同步换挡。我的做法是先用旧波特率发一个 DLC=0 的通知帧，对端收到后进入等待状态，双方延时 10ms，再同时切换。

void CAN_SpeedChange(uint32_t new_baud) { /* 查表得到目标速率的位时序配置 */ for (uint32_t i = 0u; i < sizeof(can_timing_table) / sizeof(can_timing_t); i++) { if (can_timing_table[i].baud == new_baud) { /* 1. 按当前波特率发送通知帧，ID 不被业务帧占用 */ CAN_TxFrame(0x555u, (const uint8_t*)0, 0u); /* 2. 给对端留出进入初始化模式的时间 */ DelayMs(10u); /* 3. 切换本端位时序 */ CAN_SetBitTiming(&can_timing_table[i]); /* 4. 按新波特率发同步帧，让对端做硬同步 */ CAN_TxFrame(0x556u, (const uint8_t*)0, 0u); break; } } }

这里的 10ms 不是为了对齐两个控制器的时钟。CAN 协议本身有硬同步机制，任何显性跳变沿都能让接收方重新对齐位时序，只要两边波特率一致，就不存在累积漂移问题。10ms 的真正作用是给对端的协议栈留出处理时间，让对端完成进入初始化、改写寄存器、退出初始化这一整套动作，并且保证总线上没有正在传输的帧。如果对端调度任务的抖动大，这个延时需要按最坏情况放大到 20ms 或 50ms。

通知帧的 ID 要避开业务报文段，DLC=0 是为了把总线占用压缩到最小。同步帧则承担握手职责，对端收到后，说明新波特率已经能正常完成 ACK 握手。

3.4 切换失败时的现场特征

如果对端没有成功切换，新速率下的第一帧就会出问题。对端仍按 125k 采样 1M 的位流，会把 SOF 后的第一个位即判断为位错误，随后发出积极错误帧。本端的错误计数器每次加 8，连续几帧后进入 error passive，最终可能 bus off。出现这种情况时，排查顺序是：先看本端退出 INIT 后是否回到正常模式，再看对端错误计数是否累加，最后回到通知帧本身，确认它确实被总线上的所有节点都收到了。

4. 动态切换的踩坑清单：错误帧、Bus-Off与采样点不匹配

4.1 切换瞬间的错误帧从哪里来

很多人误以为错误帧是因为“波特率改错了”，实际上切换瞬间总线上几乎没有正常帧在跑，错误帧主要来自两端位序时的不一致。一端已经切到 1M，另一端还在 125k，高速端发出的每一位在低速端看来都落在采样点之外，低速端立刻回一个显性错误帧。这个错误帧反过来又破坏了高速端的正常接收，双方互相叠加错误计数，一两轮下来就有人进 bus off。

这种故障的波形特征很典型：切换之后的第一帧数据还没到 DATA 段，总线上就出现连续 6 个显性位组成的错误帧。如果你用示波器在 CAN_H/CAN_L 上看到这个形状，不用怀疑，先查对端节点是否真的完成了切换。

4.2 Bus-Off恢复策略：让控制器自动恢复还是手动复位

RH850 的 RSCAN 模块在进入 Bus-Off 后，按 CAN 规范需要等待 128 次 11 位隐性位序列才能恢复。硬件默认会自动执行恢复流程，但自动恢复的时间取决于总线负载和错误帧频率。如果总线被某个节点持续干扰，自动恢复可能反复失败，这时候就需要软件介入。

if (CAN0_STR.BOFF != 0u) { /* 总线关闭，TEC 已经达到 255 */ CAN0_CTR.INIT = 1u; /* 等待进入初始化模式，清掉错误计数 */ uint32_t timeout = 10000u; while (timeout-- > 0u) { if (CAN0_STR.INIT == 1u) break; } CAN0_CTR.INIT = 0u; while (CAN0_STR.INIT != 0u) { /* 等待恢复 */ } }

请求 INIT 模式会让控制器彻底停止收发并复位错误计数，这和单纯等硬件自动恢复的区别在于：自动恢复要等 128 个连续的隐性位序列，而手动复位可以在总线上仍然存在高频错误帧时强制打断。

排查切换问题之前，先读一下错误计数寄存器，判断当前总线处于什么状态：

4.3 采样点不匹配的典型症状

采样点差异是低速看不出来、高速必定翻车的一类问题。125k 的位时间是 8us，采样点差 5% 就是 400ns，通常不影响；1M 的位时间是 1us，采样点差 5% 只有 50ns，加上总线电容导致边沿变缓，误码率会显著上升。如果你遇到“125k 一切正常，切到 1M 就开始零星错误帧”，先别怀疑晶振精度，多半是两边采样点差太多。

本方案把两档速率都做成 20TQ、采样点 80%，就是为了规避这个问题。另一个节点如果用默认配置比如 75% 采样点，在 1M 下和本端的采样时刻相差约 50ns，正好落在边沿附近，就会出现偶发 CRC 错误。这种错误不是每帧都出现，但每出现一次都会让错误计数累加，时间长了也会导致节点进入 error passive。

4.4 多节点切换顺序：先就绪，再统一换挡

双机通信时，先发通知帧的一方占主动权。但总线上挂多个节点时，切换顺序就变得关键。如果主机先切，从机还没切，主机发的同步帧必然触发错误帧，反而让主机自己 bus off。更稳妥的顺序是：所有节点先在旧速率下上报“就绪”，主机确认全部就绪后，向所有节点广播切换命令，每个节点收到命令后延时相同时间再切换。

负载率也要按最低速档位预留。同样一组报文，125k 下的总线负载率是 1M 下的 8 倍。如果切换后要长时间保持 125k，报文周期必须重新计算，否则总线一直高负载运行，任何错误帧都可能让处理不过来的一方先掉线。

5. 验证切换正确性：从示波器到连续压测

5.1 用示波器直接量位宽确认当前速率

切换后第一件事不是看代码，而是用示波器确认总线上实际跑的速率。把 CH1 接到 CAN_H，探头地接 CAN_GND，触发方式设为下降沿单次，抓一帧 DLC=0 的报文。从 SOF 下降沿到第一个隐性上升沿的时间，在 1M 下约等于 1us，在 125k 下约等于 8us。

量到的时间误差在 5% 以内就说明位时序生效了。如果量出来是 8us，但代码里明明配的是 1M，优先检查 BRPR 写入值是否被后续代码覆盖。

5.2 用CAN工具连续压测并统计错误帧

CANoe 或 PCAN 这类工具可以设成对应速率监听。测试序列固定为：通知帧、延时、切换、同步帧、1000 帧业务报文、统计错误计数。压测时让这个序列循环 100 次，重点关注三个指标：切换后第一帧是否发送成功、错误计数器是否归零、是否出现过 bus off。

压测过程中如果第一次循环失败而后续成功，大概率是通知帧发送时的总线状态不对；每次都稳定失败，优先查对端节点是否真的在延时结束后切换。不要忽略切换瞬间的 REC 值，REC 不为 0 说明有节点在切换后发过错误帧，即使后续通信看起来正常，也说明同步流程有瑕疵。

5.3 切换完成后的第一个报文：加一条同步帧再进业务

最后一个实用技巧：切换之后不要立刻发业务数据，先发一条 DLC=0 的同步帧，然后读错误计数寄存器。只有 REC 和 TEC 全部为 0，才说明同步帧已经和对端完成 ACK 握手，总线处于健康状态，之后才能放行业务报文。

/* 读取发送和接收错误计数 */ uint32_t ecr = CAN0_ECR; uint8_t rec = (uint8_t)(ecr >> 8); /* 接收错误计数 */ uint8_t tec = (uint8_t)(ecr & 0xFFu); /* 发送错误计数 */ if ((rec == 0u) && (tec == 0u)) { /* 错误计数为0，说明同步帧已经成功完成握手 */ CAN_TxFrame(APP_START_ID, data, len); }

注意 RSCAN 的 ECR 寄存器在不同型号里位域命名可能不同，有的手册里 TEC 在低字节、REC 在高字节，按实际手册调整。同步帧本身不要携带业务数据，它的作用纯粹是验证新波特率下总线能否正常收发。REC 清零后再放行业务数据，整个切换过程才算真正闭环。

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