Bug 207751 - RS485 RTS(TXEN) inactivated too late, resulting in received frame distortion
Summary: RS485 RTS(TXEN) inactivated too late, resulting in received frame distortion
Status: NEW
Alias: None
Product: Drivers
Classification: Unclassified
Component: Serial (show other bugs)
Hardware: All Linux
: P1 high
Assignee: Russell King
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-05-15 09:22 UTC by YuDong Zhang
Modified: 2023-05-23 01:58 UTC (History)
2 users (show)

See Also:
Kernel Version: 5.4.40
Subsystem:
Regression: No
Bisected commit-id:

Attachments
RTS delay oscilloscope (67.63 KB, image/png)
2023-05-04 07:10 UTC, slaveze 		Details
Add an attachment (proposed patch, testcase, etc.)

Description YuDong Zhang 2020-05-15 09:22:55 UTC 
the hardware platform is NXP IMX6UL.
the serial port driver is imx-uart.
serial rs485conf is:
  SER_RS485_RTS_ON_SEND=high
  SER_RS485_RTS_AFTER_SEND=low
  delay_rts_before_send=0
  delay_rts_after_send=0

the oscilloscope shows that after tx completes 2.5ms-5ms, the RTS pin is pulled down, but the opposite end returns data after tx completes 2ms
Comment 1 slaveze 2023-05-04 06:57:05 UTC 
Hi
Comment 2 slaveze 2023-05-04 07:08:37 UTC 
Hi,

I also confirm RTS signal delay when transmitting. (same imx serial IP, on i.MX6ULL)
In rs485, using an external chip (UM3483EESA) it corrupts received frame. (see oscilloscope capture)
This is not consistent and only happens every 10-20 frames in my case.

Thanks,
Sebastien
Comment 3 slaveze 2023-05-04 07:10:05 UTC 
Created attachment 304210 [details]
RTS delay oscilloscope
Comment 4 slaveze 2023-05-04 07:34:17 UTC 
Tested on 6.1.14 and 5.10.162
Comment 5 YuDong Zhang 2023-05-17 08:01:03 UTC 
(In reply to slaveze from comment #4)
> Tested on 6.1.14 and 5.10.162
According to my test, this problem only occurs when power management is turned on.
Comment 6 slaveze 2023-05-17 08:18:35 UTC 
(In reply to YuDong Zhang from comment #5)
> (In reply to slaveze from comment #4)
> > Tested on 6.1.14 and 5.10.162
> According to my test, this problem only occurs when power management is
> turned on.

Tried disabling runtime pm:
$ echo on > /sys/class/tty/ttymxc2/power/control

But the behavior is still the same
Comment 7 YuDong Zhang 2023-05-23 01:55:55 UTC 
(In reply to slaveze from comment #6)
> (In reply to YuDong Zhang from comment #5)
> > (In reply to slaveze from comment #4)
> > > Tested on 6.1.14 and 5.10.162
> > According to my test, this problem only occurs when power management is
> > turned on.
> 
> Tried disabling runtime pm:
> $ echo on > /sys/class/tty/ttymxc2/power/control
> 
> But the behavior is still the same

I recompile the kernel after turning off CONFIG_PM.
Comment 8 YuDong Zhang 2023-05-23 01:58:04 UTC 
(In reply to slaveze from comment #6)
> (In reply to YuDong Zhang from comment #5)
> > (In reply to slaveze from comment #4)
> > > Tested on 6.1.14 and 5.10.162
> > According to my test, this problem only occurs when power management is
> > turned on.
> 
> Tried disabling runtime pm:
> $ echo on > /sys/class/tty/ttymxc2/power/control
> 
> But the behavior is still the same

It may be caused by other reasons, but I didn't investigate deeply.
Note You need to log in before you can comment on or make changes to this bug.