i.MX6ULL 中断频繁触发(21f4000.serial)

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

i.MX6ULL 中断频繁触发(21f4000.serial)

323件の閲覧回数
xisuisan222
Contributor I

大家好,系统运行时发现卡顿,通过排查发现有一个中断计数异常,这个外设是rs485。在前一天晚上是3亿多次,

67: 334823120 GPC 30 Level 21f4000.serial

第二天变得更多。

xisuisan222_0-1755174004840.png

我们只有一个进程在使用这个串口收发数据,正常的业务不会这么频繁的发送数据

异常的波形如下

xisuisan222_1-1755174213455.png

正常波形

xisuisan222_2-1755174236393.png

 

当拔掉rs485与外设的通信线后,中断计数增加变为正常,后续重新进行我们设备的业务,中断计数每秒增加几万次。最终是通过重启使用uart的进程恢复的。我们有三台同时运行的设备,只有这一台会这样,并且是突然出现的。正常运行的数据如下图所示

xisuisan222_3-1755174521514.png

我们想知道为什么会出现这种情况,谢谢!

 

ラベル(1)
0 件の賞賛
返信
2 返答(返信)

284件の閲覧回数
JosephAtNXP
NXP TechSupport
NXP TechSupport

Hi @xisuisan222 ,

This isolated behavior seems like a physical issue, the line must have an agent like the cable, the other end, a hardware fault.

Do you see any difference after power cycling all the elements?

Regards

0 件の賞賛
返信

265件の閲覧回数
xisuisan222
Contributor I

Hi @JosephAtNXP ,

Thanks so much for your support on this issue. I wanted to provide an update: the device resumed normal operation simply after we restarted the process that uses UART4. We've been monitoring it since then, and the issue hasn't recurred.

For context, there are two slave devices on this RS485 bus. At the time, we checked the logs from the slave devices but didn't find any obvious anomalies. We had actually adjusted the process's log level to capture the original packets during the abnormal state, but after restarting the UART4 process as part of that process, the issue was resolved, and unfortunately we weren't able to capture the problematic packets.

Regards