STM32 RS232串口接收数据帧被拆分问题排查记录

青争.

于 2024-04-15 19:01:18 发布

阅读量2k

点赞数 40

分类专栏： STM32 文章标签： stm32 嵌入式硬件单片机

本文链接：https://blog.csdn.net/weixin_44124535/article/details/137779250

版权

STM32 专栏收录该内容

2 篇文章 0 订阅

订阅专栏

文章目录

@[toc]
STM32 RS232串口接收数据被拆分问题排查记录
1.问题描述
2.背景阐述
2.1开发环境
2.2数据接收

3.问题分析
4.解决方案
5.验证结果

STM32 RS232串口接收数据被拆分问题排查记录

1.问题描述

如图1所示，与上层设备的串口Modbus RTU通讯，存在数据截断接收情况(实际串口请求数据长度是25字节，被拆分为16+9字节)。

图1 Modbus通讯报错

2.背景阐述

2.1开发环境

芯片型号：STM32F767IGT6、SP3232，如图2、图3所示。

图2 主芯片型号

图3 RS232芯片型号

开发环境：STM32CubeMX、STM32CubeIDE，如图4、图5所示。

图4 STM32CubeMX版本信息

图5 STM32CubeIDE版本信息

2.2数据接收

串口通讯主要的难点在于 命令帧之间的区分 和 应答的及时性，具体的数据处理逻辑如 ST32RS485串口DMA发送问题记录及调试解决文章所示，为避免来回地跳转，此处再对相关部分进行阐述。

如图6所示，在文档Modbus_over_serial_line_V1 2.5.1.1节阐述，在MODBUS RTU模式中，消息帧之间的最小间隔时间是3.5字符的时间(具体时间由串口比特率及单个字符包含的位数决定，如比特率为9600bits/s，单个字符包含1个起始位，8个数据位，0个校验位，1个停止位，则最小间隔时间具体值t_3.5=1/9600*(1+8+0+1)*3.5≈3.65ms)。因此数据接收可以使用芯片自带的超时功能实现，如图7所示，除了要使能接收器超时中断外，同时也要使能接收器超时功能，并使能DMA接收的循环模式，即数据接收采用 串口接收器超时中断+DMA接收循环模式 的方式，在串口中断中判断是否是超时中断，若是则获取此次中断录入DMA的新数据长度值，数据长度值的存储采用10级的循环缓冲区实现，并在程序主循环中判断存储数据长度值的缓冲区是否为空，若不为空则根据存储的数据长度值读取DMA接收缓冲区相应的数据量，然后送入Modbus协议解析函数中进行处理。

图6 MODBUS Message RTU Framing

图7 MODBUS通信

3.问题分析

图8 串口通讯参数设置

图9 串口数据线极性定义

命令帧之间的区分是通过芯片自带的超时功能实现的，再根据图8、图9所示，也就是说若一帧数据刚好被拆分成两帧，理论上是因为一帧数据内会有一段空闲高电平的时间≥t_3.5=1/115200*(1+8+0+1)*3.5≈304us。

刚开始是完全不认为一帧数据内会存在如此长时间的空闲状态，便初步怀疑会不会是RS232电平转TTL电平的SP3232芯片转换速率不足，但通过实际查看芯片手册，SP3232芯片是完全能够支持1M比特率的通讯。于是决定先用示波器采集串口线路上的电平状态，看是否存在问题，具体如下所示。

读保持寄存器：串口请求数据为8个字节，实际所用时间≈660us、690us（理论时间8*10/115200*1000*1000≈694us），串口响应数据为47个字节，实际所用时间≈4.07ms、4.06ms（理论时间47*10/115200*1000≈4ms)，底层数据解析处理时间≈1.23ms、850us；

写多个寄存器：串口请求数据为25个字节，实际所用时间≈2.154ms（理论时间25*10/115200*1000≈2.17ms），串口响应数据为8个字节，实际所用时间≈683us（理论时间8*10/115200*1000*1000≈694us），底层数据解析处理时间≈550us。

所以串口线路上的电平变化是符合串口通讯参数设置的，同时虽然底层的串口通讯数据接收是中断方式，但命令解析处理是轮询方式（轮询周期1ms，所以通讯最大响应时间≤1.5ms），因此示波器采集到的数据也是与程序处理逻辑相符的。

图10 读保持寄存器：串口请求数据时间

图11 读保持寄存器：串口请求数据时间01

图12 读保持寄存器：数据解析处理时间

图13 读保持寄存器：数据解析处理时间01

图14 读保持寄存器：通讯交互总时间

图15 读保持寄存器：通讯交互总时间01

图16 写多个寄存器：串口请求数据时间

图17 写多个寄存器：数据解析处理时间

图18 写多个寄存器：通讯交互总时间

但还是不认为一帧数据内会存在如此长时间的空闲状态，甚至开始怀疑芯片自带的接收超时功能是否有问题，于是想确认下通讯发生错误时串口数据线上的实际电平状态，便在程序串口接收超时中断处增加IO口电平的切换逻辑，以便在数据接收有问题时，给示波器提供触发源，以捕捉到错误时串口数据线上的电平状态。最终捕获到信号如图19、20所示（其中通道1接提供触发信号的IO口，通道2接RS232 PC-TXD，通道4接TTL PC-TXD），在一帧数据内可能会有390us左右的空闲高电平，而串口接收器超时判断的时间是3.5个字符(3.5*10/115200*1000*1000≈304us)，导致触发了串口接收超时中断，同时空闲帧和停止位在串口线上均是高电平状态，并且这段空闲电平刚好是两个字符之间，从而一帧数据的内容实际未出现错误，只是被拆分接收了。