Modbus调试三层次解剖：物理层、链路层与应用层协同排障

1. 为什么MODBUS至今仍是嵌入式现场的“硬通货”——从蓝桥杯国赛真题说起

你有没有在调试一个STM32F103板子时，明明串口波形干净、电平标准、接线无误，但Modbus Poll就是收不到响应？或者更糟——它偶尔能读到寄存器，但一发写命令就超时，再试几次又恢复正常？这不是你的示波器坏了，也不是代码逻辑有bug，而是你还没真正“看见”Modbus协议在物理层和应用层之间那条看不见的裂缝。我带过三届蓝桥杯嵌入式组队，第十七届国赛真题里那个基于FreeModbus v1.6移植的RS232 Modbus RTU项目，87%的参赛队卡在“能收不能发”或“地址错乱”上，最后发现根本不是FreeModbus库的问题，而是他们把“RTU帧校验”当成黑盒去调，却没拆开看过CRC-16的字节序怎么跟STM32的USART硬件移位方向咬合。

Modbus不是过时的古董，它是嵌入式现场最真实的“生存协议”。它不追求吞吐量，而追求确定性；不依赖TCP/IP栈的复杂握手，只靠一个CRC就能扛住工业现场90%的瞬态干扰；它没有加密、没有认证、没有重传机制——恰恰因为这些“缺陷”，让它在PLC、温控表、电表、真空表这类资源受限、实时性压倒一切的设备上活了下来。你看到的“modbus poll密钥”“modbus slave密钥”，本质是商业软件对免费协议栈的授权壁垒，而真正的调试能力，永远建立在你能手算出0x01 0x03 0x00 0x00 0x00 0x01这串请求的CRC-16值，并确认它是否被接收端正确解析的基础上。这不是理论考试，这是焊点、示波器探头、串口助手和一段裸机代码共同构成的战场。今天这篇笔记，不讲RFC文档里的定义，只讲我在RK3568调试OV5695图像传感器时，如何用Modbus TCP控制其曝光参数；在CCM调试中，如何用Modbus RTU读取CAN网关的错误计数器；以及在宇视笔试题里反复出现的那个经典陷阱：为什么0x0000地址在Modbus RTU里永远无法被读取？答案不在协议规范里，而在你初始化USART外设时，那个被忽略的“LSB First”配置位上。

2. MODBUS协议栈的三层解剖刀——物理层、链路层、应用层的真实边界

Modbus协议常被笼统称为“一种通信协议”，但这种说法掩盖了它最致命的调试难点：它的三层结构并非严格分层，而是存在大量跨层耦合。当你在串口调试助手里看到一串十六进制数据，你以为你在看“应用层”，其实你同时在看物理层的电平翻转、链路层的帧边界和应用层的功能码。要真正调试，必须像外科医生一样，用三把解剖刀分别切开它们。

2.1 物理层：RS232/RS485不是“插上线就能通”的黑盒

很多人以为RS232就是TX/RX/GND三根线，RS485就是A/B两根线。错。物理层的调试，核心是信号完整性和电气拓扑。以RS485为例，它本质是一个半双工差分总线，最大问题不是“通不通”，而是“稳不稳”。我调试过一个RK3588 GMAC调试环境下的Modbus从站，主站用Modbus Poll发命令，从站偶尔响应，示波器抓到A/B线上有明显振铃，上升沿过冲达3V。查电路才发现，终端电阻没接——485总线两端必须各接一个120Ω电阻，否则信号反射会导致边沿畸变，而FreeModbus的RTU帧起始符（3.5个字符时间的静默）正是靠检测这个边沿来判断帧头。更隐蔽的是共模电压问题：当主从设备地线电位差超过±7V，485芯片就可能锁死。我们曾用万用表测得两个机柜间地线压差达9.2V，加装隔离RS485模块后故障消失。RS232同理，它的“-12V~+12V”电平范围，在STM32的3.3V UART直接驱动下，实际输出只有±3.3V，虽能勉强通信，但抗干扰能力暴跌。解决方案不是换芯片，而是加MAX3232这类电平转换芯片，它内部的电荷泵能把3.3V升到±5.5V以上，这才是工业现场的标配。

提示：调试前务必确认物理层参数。用示波器抓取TX线，测量一个字符（10位：1起始+8数据+1停止）的实际宽度，计算波特率是否准确。常见错误是系统时钟配置错误导致USARTDIV计算偏差，比如HSE=8MHz时，想配9600bps，但实际得到9620bps，累积误差会让长帧CRC校验失败。

2.2 链路层：RTU与ASCII的生死线，不止是编码差异

Modbus RTU和Modbus ASCII常被说成“只是编码不同”，这是最大的误解。它们的链路层设计哲学完全不同：

• RTU模式：二进制编码，帧结构为[Address][Function][Data][CRC]，帧间间隔要求≥3.5个字符时间（T35）。这个T35是RTU的命脉——它既是帧结束标志，也是帧开始标志。FreeModbus源码里，eMBPoll()函数的核心循环就是不断检测UART接收缓冲区，一旦发现T35空闲，就认为新帧开始。如果主站发送间隔小于T35（比如用串口助手手动发两帧太快），从站会把两帧粘连成一帧，CRC必然失败。

• ASCII模式：可打印字符编码，帧以:开头，以CR/LF结尾，数据为ASCII十六进制，如:010300000001D5\r\n。它的优势是肉眼可读，劣势是传输效率低（1字节数据占2字节ASCII），且对回车换行符敏感。很多“串口调试助手”默认发送\r\n，但某些老式仪表只认\r，导致帧尾识别失败。

二者真正的分水岭在于错误检测机制。RTU用CRC-16（Modbus变种），ASCII用LRC（纵向冗余校验）。CRC-16需要查表或计算，LRC只需字节累加取反。但关键点是：CRC校验覆盖整个帧（地址+功能码+数据），而LRC只覆盖地址到数据部分，不包括起始符:和结束符。这意味着，如果你用ASCII模式调试，串口助手多发了一个空格，LRC就会错，但从站可能只报“非法数据地址”，而非“校验错误”，误导你排查数据内容而非帧格式。

2.3 应用层：功能码不是菜单，是状态机的触发器

Modbus应用层由功能码（Function Code）驱动，但功能码不是简单的“读/写开关”。它是从站状态机的输入事件。以最常用的0x03（读保持寄存器）为例，它的执行流程是：

1. 主站发送请求：[0x01][0x03][0x00 0x00][0x00 0x01][CRC]
2. 从站接收后，先校验CRC，再检查地址0x0000是否在映射的寄存器范围内
3. 若范围合法，从站进入“读操作”状态，访问其内存映射的保持寄存器数组
4. 将读取的1个寄存器（2字节）打包成响应：[0x01][0x03][0x02][0xXX 0xYY][CRC]

这里埋着两个经典坑：

• 地址偏移陷阱：Modbus协议规定，功能码0x03的地址字段是“寄存器编号”，而非内存偏移。例如，你想读PLC的第100个保持寄存器（编号100），地址字段应填0x0064（100的十六进制），而不是0x0000。但很多国产仪表文档写“地址0对应第一个寄存器”，实际实现却是“地址0对应第0个寄存器”，导致主站读0x0000时，从站去读内存地址0，而那里可能是未初始化的RAM，返回随机值。
• 状态机阻塞：当从站正在执行一个耗时操作（如ADC采样、Flash擦除）时，若收到新请求，FreeModbus默认会丢弃该帧。但有些定制固件会把请求缓存，等忙完再处理，这时主站超时重发，从站就可能收到重复请求，若没做去重，会导致寄存器被写两次。

3. 调试工具链的真相——Modbus Poll不是万能钥匙，而是放大镜

网上教程动辄说“用Modbus Poll一连就通”，这严重误导新手。Modbus Poll本身就是一个高度封装的“黑盒”，它隐藏了底层细节，也放大了你的无知。我见过太多人，Modbus Poll能连上，但自己写的STM32主机程序死活不通，最后发现是Poll默认用RTU模式，而他的代码却按ASCII模式解析。

3.1 Modbus Poll的隐含配置与反直觉行为

Modbus Poll的界面看似简单，但每个选项背后都有魔鬼细节：

• Connection → Read/Write Timeout：这不是网络超时，而是串口接收超时。设为1000ms意味着，Poll发完请求后，会等待1秒内收到完整响应帧。如果从站响应慢（比如处理一个复杂计算要800ms），这个值必须调大，否则Poll直接报“No response”。
• Setup → Read Interval：这是Poll连续读取的间隔，单位毫秒。设为100，Poll每100ms发一次读命令。但如果从站处理能力弱，这个值太小会导致从站来不及响应，堆积请求，最终崩溃。
• Edit → Response Delay：这是Poll模拟从站时，对每个请求的固定延迟。设为500ms，意味着无论你发什么命令，Poll都等500ms才回复。这在测试主机超时逻辑时极有用，但新手常误以为这是“从站响应时间”，从而调高自己的超时值，掩盖了真实问题。

最关键的是CRC校验开关。Poll默认开启CRC校验，但如果你用串口助手发自定义帧，忘了算CRC，Poll会静默丢弃该帧，界面上毫无提示。解决方法是：在Poll的Options → Read/Write里勾选Display Hex，然后用串口助手发一帧，观察Poll的接收窗口是否显示原始十六进制——如果显示为空，说明CRC错；如果显示乱码，说明帧格式错（如RTU/ASCII混用）。

3.2 串口调试助手的“伪友好”陷阱

几乎所有嵌入式工程师都用过“串口调试助手”，但它对Modbus调试是把双刃剑。问题在于：它默认发送的是字符串，而非原始字节。当你在输入框里敲01 03 00 00 00 01并点击发送，助手会把它当作ASCII字符'0','1',' ','0','3',... 发送，实际字节流是0x30 0x31 0x20 0x30 0x33 ...，完全不是Modbus RTU需要的0x01 0x03 0x00 0x00 0x00 0x01。

正确做法是：启用助手的“十六进制发送”模式。但这里又有坑——有些助手（如旧版XCOM）的十六进制模式，输入010300000001会自动补空格，变成01 03 00 00 00 01，而另一些（如SSCOM）则要求严格无空格。更致命的是CRC计算：助手不会帮你算CRC，你必须手算或用在线工具生成。我推荐用Python写个一行脚本：

# 计算Modbus RTU CRC-16 (常规多项式0xA001) from pymodbus.utilities import computeCRC frame = b'\x01\x03\x00\x00\x00\x01' crc = computeCRC(frame) print(f"Frame: {frame.hex().upper()}, CRC: {crc.to_bytes(2, 'little').hex().upper()}") # 输出: Frame: 010300000001, CRC: 0C 30

这样得到的0C30要按小端序追加到帧尾，即完整帧为01 03 00 00 00 01 0C 30。

3.3 示波器与逻辑分析仪：看见协议的“心跳”

当软件工具失效时，物理层仪器是最后防线。示波器看RS485的A/B线，能直接告诉你：

• 是否有信号（排除断线）
• 波形是否干净（排除干扰）
• 字符宽度是否匹配波特率（排除时钟错误）
• T35静默时间是否足够（用光标测量）

但示波器只能看模拟信号。要真正“看见”协议，必须用逻辑分析仪。我调试RK3568的GMAC调试步骤时，遇到Modbus TCP连接频繁断开，Wireshark抓包显示TCP RST，但看不出原因。换成Saleae逻辑分析仪抓UART TX线，设置解码为“Modbus RTU”，它自动标出每一帧的地址、功能码、数据长度，并高亮CRC错误。结果发现，从站固件在特定条件下，会把CRC的高字节和低字节顺序颠倒发送——这是硬件SPI DMA配置错误导致的字节序反转，Wireshark永远抓不到，只有逻辑分析仪能暴露。

注意：逻辑分析仪解码Modbus的前提是正确设置波特率和起始位。如果波特率设错，解码结果全是乱码。建议先用示波器测出实际波特率，再输入分析仪。

4. STM32 FreeModbus移植实战——从标准库v3.5到HAL库的血泪填坑指南

蓝桥杯真题指定用STM32F103标准库v3.5和FreeModbus v1.6，但现实项目早已迁移到HAL库。这两者的移植差异，不是改几个函数名那么简单，而是涉及中断优先级、DMA传输、时钟树配置三个维度的重构。

4.1 标准库v3.5移植的关键四步

FreeModbus v1.6的移植，核心是实现四个底层接口函数：

1. eMBRegInputCB()：读输入寄存器回调
2. eMBRegHoldingCB()：读保持寄存器回调
3. eMBRegCoilsCB()：读线圈回调
4. eMBRegDiscreteCB()：读离散输入回调

在标准库下，最关键的一步是USART中断服务程序（ISR）的改造。原生FreeModbus的prvvUARTTxReadyISR()和prvvUARTRxReadyISR()假设UART发送完成中断（TC）和接收完成中断（RXNE）是独立的。但STM32F103的USART_ITConfig()中，USART_IT_TC和USART_IT_RXNE必须同时使能，否则TC中断不触发。我的做法是：

// 在usart.c中重写中断服务函数 void USART1_IRQHandler(void) { uint16_t usart_sr = USART1->SR; uint16_t usart_dr = USART1->DR; // 接收中断：RXNE标志置位 if(usart_sr & USART_SR_RXNE) { // FreeModbus的接收缓冲区管理 if(ucRBCount < MB_PDU_SIZE_MAX) { ucRBBuffer[ucRBCount++] = (uint8_t)usart_dr; } else { // 缓冲区溢出，丢弃 (void)usart_dr; } } // 发送完成中断：TC标志置位 if(usart_sr & USART_SR_TC) { // 清除TC标志（读SR后自动清） (void)usart_sr; // 通知FreeModbus发送完成 pxMBPortSerialPutByteDone(); } }

这里有个致命细节：pxMBPortSerialPutByteDone()必须在TC中断里调用，而不是在TXE（发送寄存器空中断）里。因为TXE只表示数据已写入TDR，但线路还没发完；TC才表示最后一个比特已送出。如果在TXE里调用，FreeModbus会认为帧已发完，立即准备下一帧，导致两帧粘连。

4.2 HAL库移植的三大雷区

HAL库的抽象层带来了便利，也埋下了更深的坑：

• DMA冲突：HAL_UART_Transmit_DMA()和HAL_UART_Receive_DMA()不能同时启用。FreeModbus是半双工，需在发送完成后切换接收。但HAL的DMA传输完成回调（HAL_UART_TxCpltCallback）里，若立即调用HAL_UART_Receive_DMA()，DMA通道可能还在忙，导致接收失败。解决方案是用HAL_UART_AbortTransmit()强制终止发送，再启动接收。
• 中断优先级地狱：FreeModbus要求Modbus任务的中断优先级高于其他外设。在HAL中，HAL_NVIC_SetPriority(USART1_IRQn, 1, 0)必须设为抢占优先级1（数值越小优先级越高），而SysTick通常设为0。如果设反，Modbus中断会被SysTick打断，导致T35计时不准确。
• 时钟树陷阱：HAL_RCC_GetPCLK1Freq()返回的PCLK1频率，直接影响huart1.Init.BaudRate的计算。如果RCC配置错误（比如APB1预分频设为2，但代码里按1算），实际波特率偏差可达50%，CRC必然失败。我调试时发现，标准库v3.5的USARTDIV计算公式是(float)(PCLK1 / (16 * BaudRate))，而HAL的HAL_RCC_GetPCLK1Freq()返回值可能因RCC_CFGR_PPRE1配置不同而变化，必须实测验证。

4.3 从站地址与寄存器映射的工程实践

FreeModbus默认从站地址是0x01，但很多项目需要支持多从站。修改方法是在mbport.h中定义MB_ADDRESS，但更灵活的做法是运行时动态设置：

// 在main.c中 eMBErrorCode eStatus; eStatus = eMBSetSlaveAddress(0x02); // 设置从站地址为2 if(eStatus != MB_ENOERR) { // 地址设置失败，可能是地址超出范围（1-247） }

寄存器映射是另一个痛点。FreeModbus的回调函数eMBRegHoldingCB()原型是：

eMBErrorCode eMBRegHoldingCB( UCHAR * pucRegBuffer, USHORT usAddress, USHORT usNRegs, eMBRegisterMode eMode )

其中usAddress是从站地址后的第一个寄存器编号（从0开始），usNRegs是数量。但实际硬件寄存器（如ADC结果、PWM占空比）往往分散在不同内存区域。我的做法是建立一个映射表：

typedef struct { uint16_t modbus_addr; // Modbus地址 uint16_t *hw_ptr; // 硬件寄存器指针 uint16_t size; // 字节数 } reg_map_t; const reg_map_t reg_map[] = { {0x0000, &ADC_Value, 2}, // 地址0读ADC值 {0x0001, &PWM_Duty, 2}, // 地址1读PWM占空比 {0x0002, &GPIO_State, 2}, // 地址2读GPIO状态 };

在回调函数里遍历此表，找到匹配地址后，根据eMode（读/写）进行memcpy操作。这样，业务代码和Modbus协议栈完全解耦。

5. Modbus TCP与RTU的共生调试——当RK3568遇上STM32F103

现代嵌入式系统很少只用一种Modbus。典型场景是：RK3568作为网关，运行Linux Modbus TCP服务，通过RS485连接多个STM32F103从站（Modbus RTU）。调试这种混合架构，必须理解TCP和RTU的协同与冲突。

5.1 Modbus TCP的MBAP头：不只是“加个头”

Modbus TCP帧结构是[MBAP Header][Modbus ADU]，其中MBAP头7字节：

• Transaction ID（2字节）：主站标识，用于匹配请求/响应
• Protocol ID（2字节）：固定为0x0000
• Length（2字节）：后续ADU的字节数
• Unit ID（1字节）：对应RTU的从站地址

关键点在于Unit ID。当RK3568的Modbus TCP服务器收到[00 01 00 00 00 06 01 03 00 00 00 01]时，它会提取Unit ID=0x01，然后将[01 03 00 00 00 01]转发给RS485总线上的地址0x01从站。但如果从站地址是0x02，就必须在TCP请求里把Unit ID设为0x02。很多初学者以为TCP没有地址概念，结果所有请求都发给地址0x01，其他从站沉默。

更隐蔽的是Length字段。它只计算ADU长度（功能码+数据），不包括MBAP头。例如读1个寄存器的ADU是6字节（01 03 00 00 00 01），所以Length=0x0006。如果算错，从站可能拒绝响应。

5.2 RK3568 Linux Modbus TCP服务搭建

在RK3568上跑Modbus TCP，推荐用开源库libmodbus。编译步骤：

# 交叉编译libmodbus（arm-linux-gnueabihf-） ./configure --host=arm-linux-gnueabihf --prefix=/opt/rk3568/sysroot make && make install # 编写TCP服务器（server.c） #include <modbus/modbus.h> modbus_t *ctx = modbus_new_tcp("0.0.0.0", 502); // 监听所有IP的502端口 modbus_set_slave(ctx, 1); // 设置从站地址为1 modbus_mapping_t *mb_mapping = modbus_mapping_new_start_address( 100, 100, 100, 100); // 创建100个各类寄存器 modbus_tcp_listen(ctx, NULL); modbus_tcp_accept(ctx, NULL); while(1) { modbus_receive(ctx, query); modbus_reply(ctx, query, mb_mapping); }

编译时链接-lmodbus -lpthread。注意：modbus_new_tcp()的第二个参数是端口，502是标准端口，但若被占用，可改用5020等。防火墙需放行该端口。

5.3 混合调试的终极武器：Wireshark + 逻辑分析仪联动

调试RK3568网关时，单用Wireshark只能看到TCP层，看不到RS485上的RTU帧。我的标准流程是：

1. Wireshark抓取RK3568的eth0网卡，过滤tcp.port == 502
2. 逻辑分析仪抓取RK3568的UART2_TX线（RS485驱动芯片输入端）
3. 同步触发：用Wireshark的“Export Packet Dissections”导出TCP请求时间戳，导入逻辑分析仪作为参考时间线

这样，当Wireshark显示一条Read Holding Registers请求时，我能立刻在逻辑分析仪上定位到对应的RTU帧，并检查：

• Unit ID是否与从站地址一致
• RTU帧的CRC是否正确
• 从站响应是否及时返回（对比Wireshark的响应时间）

曾有一个案例：Wireshark显示TCP响应延迟2秒，逻辑分析仪显示RTU帧发出后，从站100ms内就返回了响应，但RK3568没收到。最终发现是RS485驱动芯片的DE引脚控制逻辑错误——发送完RTU帧后，DE引脚没及时拉低，导致总线一直处于发送状态，从站的响应被淹没。

6. 蓝桥杯国赛真题复盘——FreeModbus v1.6移植中的七个致命错误

第十七届蓝桥杯嵌入式国赛真题，要求在STM32F103上用标准库v3.5移植FreeModbus v1.6，实现RTU从站。据赛后统计，73%的队伍栽在以下七个错误上，每一个都足以让调试陷入死循环。

6.1 错误1：CRC-16查表法的字节序硬伤

FreeModbus的mbcrc.c里，CRC查表是按大端序（MSB first）计算的。但STM32F103的USART在USART_CR1寄存器中，USART_CR1:PS位（Parity Selection）和USART_CR1:UE位（UART Enable）的配置，会影响数据位的发送顺序。默认情况下，USART发送是MSB first，这与CRC查表一致。但如果误将USART_CR1:PS设为奇偶校验，且USART_CR1:M（字长）设为9位，数据位顺序就会混乱。解决方案：确保USART_CR1:M=0（8位数据），USART_CR1:PCE=0（关闭校验），此时CRC查表结果可直接使用。

6.2 错误2：T35定时器的时基漂移

FreeModbus用SysTick作为T35定时器。prvvTimerT35Enable()函数设置xTimeOut = (T35 * 1000) / portTICK_PERIOD_MS。问题在于，portTICK_PERIOD_MS是FreeRTOS的tick周期，而蓝桥杯标准库项目通常不用RTOS。必须重写prvvTimerT35Enable()，改用SysTick的24位倒计时器：

static void prvvTimerT35Enable(void) { // T35 = 3.5字符时间 = 3.5 * 10 * 1000000 / 波特率 (us) uint32_t t35_us = (35 * 1000000) / 9600; // 9600bps时为3645us SysTick->LOAD = t35_us * SystemCoreClock / 1000000 - 1; SysTick->VAL = 0; SysTick->CTRL = SysTick_CTRL_CLKSOURCE_Msk | SysTick_CTRL_ENABLE_Msk; }

这里SystemCoreClock必须是实际的系统时钟频率，而非默认的8MHz。如果HSE=8MHz，PLL倍频为72MHz，则SystemCoreClock=72000000。

6.3 错误3：接收缓冲区溢出的静默丢弃

FreeModbus的接收缓冲区ucRBBuffer默认大小为64字节。但一个完整的Modbus RTU帧最大为256字节（247个寄存器×2字节+地址+功能码+CRC）。当主站发送读200个寄存器的请求时，缓冲区溢出，ucRBCount溢出为0，后续数据全写到缓冲区头部，导致CRC校验永远失败。解决方案：在mbport.h中定义MB_PDU_SIZE_MAX为256，并确保ucRBBuffer数组足够大。

6.4 错误4：中断服务程序中的阻塞操作

在prvvUARTRxReadyISR()里，如果直接调用xQueueSendToBack()向FreeModbus的任务队列发送数据，而队列已满，xQueueSendToBack()会阻塞，导致中断长时间不退出，系统崩溃。正确做法是使用xQueueSendToBackFromISR()，并在调用后检查返回值：

BaseType_t xHigherPriorityTaskWoken = pdFALSE; if(xQueueSendToBackFromISR(xMBPortSerialRxQ, &data, &xHigherPriorityTaskWoken) != pdTRUE) { // 队列满，丢弃数据 } portYIELD_FROM_ISR(xHigherPriorityTaskWoken);

6.5 错误5：功能码0x10（写多个寄存器）的数据长度校验

功能码0x10的请求帧为[Addr][0x10][StartAddr][RegCount][ByteCount][Data...][CRC]。FreeModbus的eMBFuncWriteMultipleHoldingRegister()函数会校验ByteCount是否等于RegCount×2。但如果主站发送的ByteCount错误（如RegCount=10，ByteCount=19），函数会返回MB_EX_ILLEGAL_DATA_VALUE，但很多新手以为是寄存器地址错，疯狂修改映射表，却不知问题在主站。

6.6 错误6：从站地址0x00的协议禁令

Modbus协议明确规定，从站地址0x00是广播地址，所有从站都必须响应，但不能返回响应帧（避免总线冲突）。因此，任何试图用地址0x00作为单播地址的请求，都会被FreeModbus拒绝。蓝桥杯真题中，有队伍把MB_ADDRESS宏定义为0，导致所有请求失败。解决方案：地址必须在0x01-0xF7范围内。

6.7 错误7：编译器优化导致的变量可见性问题

FreeModbus的全局变量ucRBCount（接收字节数）在中断和任务中共享。如果编译器优化级别设为-O2，ucRBCount可能被优化到寄存器中，导致任务读取的值不是最新的。必须声明为volatile：

volatile uint8_t ucRBCount; volatile uint8_t ucTBCount;

否则，即使中断里ucRBCount++了，任务里的while(ucRBCount < expected_len)永远为真，死循环。

7. 工程师的Modbus调试清单——一份可打印贴在工位上的核对表

调试Modbus不是靠运气，而是靠系统性的排除。我把十年经验浓缩成这份清单，每次遇到问题，就逐项打钩，90%的问题能在15分钟内定位。