搜索
bottom↓
回复: 24

遇到奇怪的485通讯问题,请大家来围观

[复制链接]

出5入4汤圆

发表于 2020-7-26 04:03:34 | 显示全部楼层 |阅读模式
最近开发了一个产品A,MCU是GD32F450,正在验证modbusRTU通讯的过程出现一个奇奇怪怪的问题(估计问题出在自己身上)
产品A做modbus主站,使用9600bps 8 N 1,和产品B(其他厂家的设备)通讯,同时在总线挂了一个485转USB做数据监视,产品B回复的报文从监视的角度看是正确的,但是产品A接收缓冲区的数据是错误的,具体表现为:实际回复7字节,但是缓冲区(使用DMA接收)收到6字节,并且前3字节是错的,后三字节是对的。
为什么说奇怪呢?
1、产品A和其他我们能找到的各种设备都通讯过,均正常,产品B和我们能找到的各种主站都试过也都正常,唯独产品A和B通讯有问题(A收B的报文有问题,B收A肯定没有问题,否则就不会回复了)
2、波特率不准? 使用示波器看过,A和B的波特率相差不超过2%,微调过波特率也没有奏效
3、B回复太快导致A来不及收? 不会的,示波器看过,在B回复报文 0.5ms之前已经切换了485收发器的状态,并且配置好了DMA
4、电平不匹配? 用示波器直接看GD的RXD TTL电平,波形和数据都是对的
5、隔壁项目组最近开发了一个产品也是GD32F450做的,试了一下和产品B的modbus功能,也是无法正常通讯

我们做了各种尝试,其中有一个办法可以把接收报文的错误概率降低到30%,但是无法理解:
将UART0所在的总线频率恢复为100M(默认100M,之前为了做到1200bps人为降低为50M了),并且使用8倍过采样(之前使用的是16倍),然后进行波特率配置。

阿莫论坛20周年了!感谢大家的支持与爱护!!

一只鸟敢站在脆弱的枝条上歇脚,它依仗的不是枝条不会断,而是自己有翅膀,会飞。

出0入114汤圆

发表于 2020-7-26 06:00:23 来自手机 | 显示全部楼层
可以买个st的对应的芯片试试看是什么情况,如果st的没问题,那就要在gd的芯片上找原因了

出5入4汤圆

 楼主| 发表于 2020-7-26 06:40:50 来自手机 | 显示全部楼层
是的,准备搞个407试试

出20入12汤圆

发表于 2020-7-26 06:52:45 来自手机 | 显示全部楼层
gd450串口我用过,但接收没使用dma,没发现问题。

出0入8汤圆

发表于 2020-7-26 07:29:17 来自手机 | 显示全部楼层
感觉还是没有及时切换收发

出215入118汤圆

发表于 2020-7-26 08:00:52 | 显示全部楼层
ST的带硬件485收发切换。

出1310入193汤圆

发表于 2020-7-26 08:22:41 | 显示全部楼层
软件已经查不出问题了  那么 换ST的测试一下吧   几分钟事情或许就能见分晓

出10入113汤圆

发表于 2020-7-26 10:43:29 | 显示全部楼层
上下拉电阻是否都有,是否都正确?阻值多少的?是否有多余的120终端电阻?简单办法是都去掉120.

出0入36汤圆

发表于 2020-7-26 13:31:25 来自手机 | 显示全部楼层
破案了么?

出0入0汤圆

发表于 2020-7-26 14:13:31 来自手机 | 显示全部楼层
非常可能是dma的问题

出0入0汤圆

发表于 2020-7-26 14:33:47 | 显示全部楼层
几年前试过一款stc的小单片机,做modbus通信,经常通信不成功,跟踪调试发现crc校验经常缺1,所以最后在stc这边额外加了条,如果crc不通过,加1再测是否通过,没做详细追究问题出在哪了,大概率还是芯片问题

出0入4汤圆

发表于 2020-7-26 14:45:34 | 显示全部楼层
sfes 发表于 2020-7-26 07:29
感觉还是没有及时切换收发

没有及时的切换收发的时候,总线电平会冲突的别的设备也收不到正确数据的。而且楼主已经用示波器验证了TTL这边数据是正确的。大概率的还是DMA操作不当导致的。

出5入4汤圆

 楼主| 发表于 2020-7-27 08:52:19 来自手机 | 显示全部楼层
redworlf007 发表于 2020-7-26 13:31
破案了么?

周天在家带娃了,没继续探索,如果破案第一时间通知你

出5入4汤圆

 楼主| 发表于 2020-7-27 08:55:19 来自手机 | 显示全部楼层
haibaogk 发表于 2020-7-26 14:33
几年前试过一款stc的小单片机,做modbus通信,经常通信不成功,跟踪调试发现crc校验经常缺1,所以最后在stc ...

我这个不是CRC的问题,最后几个字节还是能收到的

出20入62汤圆

发表于 2020-7-27 09:11:57 | 显示全部楼层
有没有这种可能:
1、你用了串口的空闲中断+dma方式接收的。
2、B设备发送的7个字节中,某两个字节之间的时间间隔略长,引发了空闲中断。

出0入16汤圆

发表于 2020-7-27 09:32:32 | 显示全部楼层
最简单的办法 用监听一下A接收的TTL电平就知道了。

出0入8汤圆

发表于 2020-7-27 09:42:06 | 显示全部楼层
还等什么, 直接买个逻辑分析仪啊,
思路1, 是不是总线负载能力不够, 上下拉电阻多少
思路2, 是不是外接了USB-485后出问题? 之前是否正常通讯?
思路3, 485波形和TTL波形是否一致?
思路4, 两边断开单独和USB485通讯, 看是否有问题? 如果有问题, 是否有可能增加了什么打印功能到串口导致收发冲突了



出0入0汤圆

发表于 2020-7-27 09:45:38 | 显示全部楼层
我遇到过类似的问题,但是具体现象和你这个不一样。
1.使用STM32做Modbus主站,和其他设备通讯正常,和客户某一台设备B通讯异常,接收全是乱码,但是外部监视,逻辑分析仪看数据和方向切换一切正常。
2.后面找了很久,STM32在发送的时候为了避免RS485芯片上的RX引脚信号抖动导致进入接收中断,因此发送的时候关闭了UART的接收功能。
3.STM32发送完成中断后切换方向,同时开启UART接收,经过详细对比错误数据的位和正常数据的位,发现STM32串口前面有几个bit的数据没有收到。
4.后面专门测试发现UART开启接收后串口并不能马上接收数据,导致前面有几个Bit会收不到,导致bit错位。这个感觉是串口的硬件BUG,后面程序改成发送的时候不关闭串口接收,只关闭接收中断使能。
5.后面又分析为什么其他设备正常,就B设备不正常,发现B设备收完后立马就回数据了,基本上没有等到帧间隙3.5T的时间。也就是说从站设备回数据太快,UART的接收BUG导致前面几个位丢失。

出0入36汤圆

发表于 2020-7-27 21:15:24 | 显示全部楼层
tim4146 发表于 2020-7-27 08:52
周天在家带娃了,没继续探索,如果破案第一时间通知你

看好你哦,福尔摩斯。

出0入0汤圆

发表于 2020-7-27 21:36:09 | 显示全部楼层
前面字节不对 后面字节对。  试试人为延迟回复如何?  试试正常回复前加几个FF之类无效字符如何?试试示波器捕捉UART错误中断如何    怀疑还是收发切换,或者接收器有什么特殊地方。

出0入0汤圆

发表于 2020-7-27 21:39:05 | 显示全部楼层
我遇到过,双向485与单向485不兼容,找谁说理去

出16170入6148汤圆

发表于 2020-8-1 11:57:21 来自手机 | 显示全部楼层
打赏!

庆祝论坛“打赏”功能实施, 现在开始发技术主题,可以获得打赏
https://www.amobbs.com/thread-5735948-1-1.html

出0入4汤圆

发表于 2020-8-6 14:31:34 | 显示全部楼层
RX脚是否配置上拉输入?

出0入0汤圆

发表于 2020-8-9 17:09:31 | 显示全部楼层
可以将A和B更改为偶校验试试,如果没有问题,说明硬件没有问题。那就可能是无校验方式时,A接收或B发送对停止位处理不严格导致,如果有逻辑分析仪很好判断。

出5入4汤圆

 楼主| 发表于 2020-8-13 21:31:25 来自手机 | 显示全部楼层
今天找了同事帮忙处理,后来找到了原因。对方这个设备在发送第一个字节的前面几个位的时候波特率偏差达到20%,导致接收的mcu出现异常。不过同样是485主站,我用k60就没问题,用电脑做主站也没问题,难道是gd32容错率做得比较差?
回帖提示: 反政府言论将被立即封锁ID 在按“提交”前,请自问一下:我这样表达会给举报吗,会给自己惹麻烦吗? 另外:尽量不要使用Mark、顶等没有意义的回复。不得大量使用大字体和彩色字。【本论坛不允许直接上传手机拍摄图片,浪费大家下载带宽和论坛服务器空间,请压缩后(图片小于1兆)才上传。压缩方法可以在微信里面发给自己(不要勾选“原图),然后下载,就能得到压缩后的图片】。另外,手机版只能上传图片,要上传附件需要切换到电脑版(不需要使用电脑,手机上切换到电脑版就行,页面底部)。
您需要登录后才可以回帖 登录 | 注册

本版积分规则

手机版|Archiver|amobbs.com 阿莫电子技术论坛 ( 粤ICP备2022115958号, 版权所有:东莞阿莫电子贸易商行 创办于2004年 (公安交互式论坛备案:44190002001997 ) )

GMT+8, 2024-3-29 03:09

© Since 2004 www.amobbs.com, 原www.ourdev.cn, 原www.ouravr.com

快速回复 返回顶部 返回列表