imx: RS-485 problems during TX, maybe DMA related

imx: RS-485 problems during TX, maybe DMA related

[Clemens Gruber]

Hi,

I observed odd behavior of the current tty/serial/imx.c driver in RS-485
mode.

RX works fine, but TX does not: When sending data, it arrives multiple
times and with data from previous transmissions at the end, after a
delay.

# My setup

Hardware:
i.MX6Q board with UARTn_RX_DATA, _TX_DATA and _CTS_B connected to a
RS-485 half-duplex transceiver (Exar SP3082E), pins RXD, TXD and DE
respectively. (DE is active-high, _CTS_B is inverted on the board)
I am using an external USB-to-RS-485 converter connected to my PC to
conduct the tests.

Firmware:
I tried both the original ROM SDMA scripts and also the RAM scripts from
Freescale (placed in firmware/imx), but there was no difference, except
for a DMA transaction error message going away (appeared when writing too
much data too fast into a device configured with too low baud rate).
So I switched back to the pure mainline 4.9 kernel with SDMA using the
scripts from ROM.

Software:
Mainline Linux 4.9 with serial_rs485 flags: rs485 (SER_RS485_ENABLED),
-rs485rtsonsend (~SER_RS485_RTS_ON_SEND), rs485rtsaftersend and
rs485rxduringtx. I only enabled rs485rxduringtx, because otherwise it
would not work at all. But I am still unsure why it is needed for
half-duplex RS-485.

# The tests

1) On the board: echo A > /dev/ttymxc4
2) On my PC: A \n A \n appears immediately
             (about 4s delay)
             A \n
             (about 4s delay)
             A \n

Kernel log on the board:
[   29.059983] imx-uart 21f4000.serial: TX: prepare to send 2 bytes by DMA.
[   29.067166] imx-uart 21f4000.serial: we finish the TX DMA.
[   29.073057] imx-uart 21f4000.serial: TX: prepare to send 4094 bytes by DMA.
[   33.359405] imx-uart 21f4000.serial: we finish the TX DMA.
[   33.365173] imx-uart 21f4000.serial: TX: prepare to send 4072 bytes by DMA.
[   37.603551] imx-uart 21f4000.serial: we finish the TX DMA.

3) On the board: echo B > /dev/ttymxc4
4) On my PC: B \n B \n appears immediately
             (about 4s delay)
             A \n B \n
             (about 4s delay)
             A \n B \n
Kernel log:
[   66.000296] imx-uart 21f4000.serial: TX: prepare to send 2 bytes by DMA.
[   66.007110] imx-uart 21f4000.serial: we finish the TX DMA.
[   66.012841] imx-uart 21f4000.serial: TX: prepare to send 4094 bytes by DMA.
[   70.297051] imx-uart 21f4000.serial: we finish the TX DMA.
[   70.302798] imx-uart 21f4000.serial: TX: prepare to send 4072 bytes by DMA.
[   74.539094] imx-uart 21f4000.serial: we finish the TX DMA.

And so on..
( If I continue with a echo C > /dev/ttymxc4, the last characters are
  A \n B \n C )

--

To illustrate the behavior, I recorded the signals on the transceiver
pins with a logic analyzer:
https://pqgruber.com/rs485_results.png
I triggered only on the raising and on the falling edge of DE, so I only
captured the first and the last characters for the first two tests and
not all three events per test.

I also enabled the DMA debug options in the kernel if that is helpful,
here is the full log during the two tests:
https://gist.github.com/clemensg/1ac5ee8a8ea32acc9145c5aa8407aea5

--

Do you have an idea, what's wrong here?

Also: If you are using RS-485 with the imx driver on a recent kernel,
please let me know if it is working for you and if you can reproduce the
behavior.

Thanks,
Clemens

--

PS:

Because I assumed that the error has something to do with DMA, I
commented out the call to imx_uart_dma_init.
Then, transmitting and receiving data over RS-485 works! Verified with
the logic analyzer and the RS-485-to-USB adapter.

However, if trying to send large amounts of data in a short time,
sometimes I get an "Unhandled fault: imprecise external abort (0x1406)".
But the back trace is not very helpful and probably not related
(it is different every time), the last time I tried, the PC was at
_raw_spin_unlock_irqrestore, called from hrtimer_start_range_ns.

Re: imx: RS-485 problems during TX, maybe DMA related

[Fabio Estevam]

Hi Clemens,

On Wed, Jan 4, 2017 at 2:00 PM, Clemens Gruber
<clemens.gruber@pqgruber.com> wrote:
> Hi,
>
> I observed odd behavior of the current tty/serial/imx.c driver in RS-485
> mode.
>
> RX works fine, but TX does not: When sending data, it arrives multiple

I am also trying to get rs485 in half-duplex mode to work on mx6dl
with kernel 4.9.

RX also works for me, but TX does not.

On my board it is the MX6QDL_PAD_CSI0_DAT16__UART4_RTS_B pin that
controls the rs485 transceiver flow, but I do not
see RTS to toggle to 1 during transmit. It stays always at 0.

I see you use CTS pin instead, but I thought RTS pin should be used.

On my userspace application I have:

/* enable RS485 mode: */
rs485conf.flags |= SER_RS485_ENABLED;

/* set logical level for RTS pin equal to 1 when sending: */
rs485conf.flags |= SER_RS485_RTS_ON_SEND;

/* set logical level for RTS pin equal to 0 after sending: */
rs485conf.flags &= ~(SER_RS485_RTS_AFTER_SEND);

Any ideas as to how to make RTS go to one so that the data can go
through the rs485 transceiver?

Thanks

Re: imx: RS-485 problems during TX, maybe DMA related

[Clemens Gruber]

Hi Fabio,

On Fri, Jan 06, 2017 at 07:22:32PM -0200, Fabio Estevam wrote:
> Hi Clemens,
> 
> On Wed, Jan 4, 2017 at 2:00 PM, Clemens Gruber
> <clemens.gruber@pqgruber.com> wrote:
> > Hi,
> >
> > I observed odd behavior of the current tty/serial/imx.c driver in RS-485
> > mode.
> >
> > RX works fine, but TX does not: When sending data, it arrives multiple
> 
> I am also trying to get rs485 in half-duplex mode to work on mx6dl
> with kernel 4.9.

I am glad I am not the only one working on this. Maybe we can figure it
out together :)

> 
> RX also works for me, but TX does not.
> 
> On my board it is the MX6QDL_PAD_CSI0_DAT16__UART4_RTS_B pin that
> controls the rs485 transceiver flow, but I do not
> see RTS to toggle to 1 during transmit. It stays always at 0.
> 
> I see you use CTS pin instead, but I thought RTS pin should be used.

I am pretty sure that CTS is the correct signal to control the
transceiver. In the reference manual on page 5231 (section 64.7.1) it
says: "The CTS_B pin can be used to control RS-485 output driver outside
the chip."
Maybe it is only called RTS in struct serial_rs485 because of DTE mode
where RX, TX, RTS and CTS are interchanged? Very confusing.

I am muxing MX6QDL_PAD_CSI0_DAT16__UART4_RTS_B and
MX6QDL_PAD_CSI0_DAT17__UART4_CTS_B because the transceiver-enable signal
is connected to ball L3 (CSI0_DAT17).

But according to the i.MX Pins tool, they can be muxed vice-versa too.
So if you connected the transceiver-enable to ball L4 (CSI0_DAT16), you
could mux MX6QDL_PAD_CSI0_DAT16__UART4_CTS_B and
MX6QDL_PAD_CSI0_DAT17__UART4_RTS_B instead?

As far as I understand, RTS is an input which is not used for RS-485, so
it is a no-connect on our board.

> 
> On my userspace application I have:
> 
> /* enable RS485 mode: */
> rs485conf.flags |= SER_RS485_ENABLED;
> 
> /* set logical level for RTS pin equal to 1 when sending: */
> rs485conf.flags |= SER_RS485_RTS_ON_SEND;
> 
> /* set logical level for RTS pin equal to 0 after sending: */
> rs485conf.flags &= ~(SER_RS485_RTS_AFTER_SEND);

This is similar to my config, however I had to also enable
SER_RS485_RX_DURING_TX, otherwise TX would not work at all.
Also, due to the active-low signal output on UART4_CTS_B, I use
~SER_RS485_RTS_ON_SEND and SER_RS485_RTS_AFTER_SEND.

--

Do you have an idea what could cause this doubling of the transmitted
characters and extra data I described?

Maybe you will see that effect too after you changed the pinmuxing.

At the moment I am trying to understand the interaction between the SDMA
engine and the imx UART driver. But this is the first time I dig into
DMA parts of the kernel and i.MX6/SDMA.. very challenging imho.

What's odd is that in RS-232 mode, everything works fine. This
buffer/DMA? problem only appears in RS-485 mode.

Regards,
Clemens

Re: imx: RS-485 problems during TX, maybe DMA related

[Fabio Estevam]

Hi Clemens,

On Fri, Jan 6, 2017 at 8:50 PM, Clemens Gruber
<clemens.gruber@pqgruber.com> wrote:

> But according to the i.MX Pins tool, they can be muxed vice-versa too.
> So if you connected the transceiver-enable to ball L4 (CSI0_DAT16), you
> could mux MX6QDL_PAD_CSI0_DAT16__UART4_CTS_B and
> MX6QDL_PAD_CSI0_DAT17__UART4_RTS_B instead?

Yes, I have tried like this:

&uart4 {
    pinctrl-names = "default";
    pinctrl-0 = <&pinctrl_uart4>;
    uart-has-rtscts;
    status = "okay";
};

pinctrl_uart4: uart4grp {
fsl,pins = <
    MX6QDL_PAD_CSI0_DAT12__UART4_TX_DATA 0x1b0b1
    MX6QDL_PAD_KEY_ROW0__UART4_RX_DATA 0x1b0b1
   MX6QDL_PAD_CSI0_DAT16__UART4_CTS_B 0x1b0b1
>;
};

In this case the DE pin of the rs485 transceiver is always at 0 then
RX works and TX does not.

Then I tried to use a gpio for controling the rts line:

&uart4 {
    pinctrl-names = "default";
    pinctrl-0 = <&pinctrl_uart4>;
    rts-gpios = <&gpio6 2 GPIO_ACTIVE_HIGH>;
    status = "okay";
};

pinctrl_uart4: uart4grp {
fsl,pins = <
    MX6QDL_PAD_CSI0_DAT12__UART4_TX_DATA 0x1b0b1
    MX6QDL_PAD_KEY_ROW0__UART4_RX_DATA 0x1b0b1
    MX6QDL_PAD_CSI0_DAT16__GPIO6_IO02 0x1b0b1
>;
}

In this case the DE pin of the rs485 transceiver is always at 1, then
TX works and RX does not.

So I was never able to observe the DE pin toggling correctly.

Maybe you could share your userspace application with me offline?

Thanks

Re: imx: RS-485 problems during TX, maybe DMA related

[Clemens Gruber]

Hi Fabio,

On Fri, Jan 06, 2017 at 10:31:16PM -0200, Fabio Estevam wrote:
> Yes, I have tried like this:
> 
> &uart4 {
>     pinctrl-names = "default";
>     pinctrl-0 = <&pinctrl_uart4>;
>     uart-has-rtscts;
>     status = "okay";
> };
> 
> pinctrl_uart4: uart4grp {
> fsl,pins = <
>     MX6QDL_PAD_CSI0_DAT12__UART4_TX_DATA 0x1b0b1
>     MX6QDL_PAD_KEY_ROW0__UART4_RX_DATA 0x1b0b1
>    MX6QDL_PAD_CSI0_DAT16__UART4_CTS_B 0x1b0b1
> >;
> };

I also mux RTS_B even though it is unused, not sure if it this makes a
difference to also add MX6QDL_PAD_CSI0_DAT17_UART4_RTS_B in your case?

It should work like this, I don't think using an extra GPIO is
necessary.

> 
> So I was never able to observe the DE pin toggling correctly.

But did you set SER_RS485_RX_DURING_TX in your flags? This is counter
intuitive, but I observed that it would not work otherwise.

> Maybe you could share your userspace application with me offline?

I am using a patched version of the busybox stty utility, I posted the
patch here, feel free to use it:
https://gist.github.com/clemensg/29bd68b3cfd719bd01002a2acde9662c

I use stty -F /dev/ttymxc4 clocal cread -hupcl -ixon -opost rs485
-rs485rtsonsend rs485rtsaftersend rs485rxduringtx

But for you it is probably rs485rtsonsend and -rs485rtsaftersend?

Regards,
Clemens

Re: imx: RS-485 problems during TX, maybe DMA related

[Fabio Estevam]

Hi Clemens,

On Sat, Jan 7, 2017 at 11:45 AM, Clemens Gruber
<clemens.gruber@pqgruber.com> wrote:

> It should work like this, I don't think using an extra GPIO is
> necessary.

The MX6QDL_PAD_CSI0_DAT16__UART4_CTS_B option is only valid in dte mode.

If I pass 'fsl,dte-mode' then I can see this pin toggling. (rx, tx
would not work as expected).

In the default dce mode I can see UART4_CTS_B pin toggling when I
monitor CSI0_DAT17 pin and configure it as:

MX6QDL_PAD_CSI0_DAT17__UART4_CTS_B

,but unfortunately this pin does not go to the TXEN pin of the RS485
transceiver.

So this means that with the hardware I have access to my only
alternative is to set MX6QDL_PAD_CSI0_DAT16__GPIO6_IO02.

>> So I was never able to observe the DE pin toggling correctly.
>
> But did you set SER_RS485_RX_DURING_TX in your flags? This is counter
> intuitive, but I observed that it would not work otherwise.

Yes, I have also tried when I read your email, but did not help on my case.

Thanks,

Fabio Estevam

Re: imx: RS-485 problems during TX, maybe DMA related

[Clemens Gruber]

Hi Fabio,

On Sat, Jan 07, 2017 at 12:57:10PM -0200, Fabio Estevam wrote:
> The MX6QDL_PAD_CSI0_DAT16__UART4_CTS_B option is only valid in dte mode.

Ah, the input select is limited in that way, I see.

You wrote that you tried rts-gpios.
What about setting cts-gpios to gpio6 2 in the DT?

Or can you remux RX and TX to be switched to work in dte mode?

Regards,
Clemens

Re: imx: RS-485 problems during TX, maybe DMA related

[Fabio Estevam]

On Sat, Jan 7, 2017 at 1:34 PM, Clemens Gruber
<clemens.gruber@pqgruber.com> wrote:
> Hi Fabio,
>
> On Sat, Jan 07, 2017 at 12:57:10PM -0200, Fabio Estevam wrote:
>> The MX6QDL_PAD_CSI0_DAT16__UART4_CTS_B option is only valid in dte mode.
>
> Ah, the input select is limited in that way, I see.
>
> You wrote that you tried rts-gpios.
> What about setting cts-gpios to gpio6 2 in the DT?
>
> Or can you remux RX and TX to be switched to work in dte mode?

I managed to get RS485 in half-duplex working with rts-gios. Will send
a patch shortly.

Thanks

Re: imx: RS-485 problems during TX, maybe DMA related

[Clemens Gruber]

On Sat, Jan 07, 2017 at 02:48:03PM -0200, Fabio Estevam wrote:
> On Sat, Jan 7, 2017 at 1:34 PM, Clemens Gruber
> <clemens.gruber@pqgruber.com> wrote:
> > Hi Fabio,
> >
> > On Sat, Jan 07, 2017 at 12:57:10PM -0200, Fabio Estevam wrote:
> >> The MX6QDL_PAD_CSI0_DAT16__UART4_CTS_B option is only valid in dte mode.
> >
> > Ah, the input select is limited in that way, I see.
> >
> > You wrote that you tried rts-gpios.
> > What about setting cts-gpios to gpio6 2 in the DT?
> >
> > Or can you remux RX and TX to be switched to work in dte mode?
> 
> I managed to get RS485 in half-duplex working with rts-gios. Will send
> a patch shortly.

Great!

Did you observe the same effect I described, with the doubling of
characters in the front and the leftovers from previous transmissions at
the end?

Thanks,
Clemens

Re: imx: RS-485 problems during TX, maybe DMA related

[Fabio Estevam]

Hi Clemens,

On Sat, Jan 7, 2017 at 6:59 PM, Clemens Gruber
<clemens.gruber@pqgruber.com> wrote:

> Great!
>
> Did you observe the same effect I described, with the doubling of
> characters in the front and the leftovers from previous transmissions at
> the end?

No, I don't observe these errors when I use 'rts-gpios' in the device tree.

Maybe you could try to use 'rts-gpios' for a quick test by applying
the patches I have just sent.

If you run this test, please remove 'uart-has-rtscts' from your dts.
According to Documentation/devicetree/bindings/serial/serial.txt they
are mutually-exclusive.

Regards,

Fabio Estevam

Re: imx: RS-485 problems during TX, maybe DMA related

[Clemens Gruber]

Hi Fabio,

On Sat, Jan 07, 2017 at 07:43:48PM -0200, Fabio Estevam wrote:
> Hi Clemens,
> 
> On Sat, Jan 7, 2017 at 6:59 PM, Clemens Gruber
> <clemens.gruber@pqgruber.com> wrote:
> 
> > Great!
> >
> > Did you observe the same effect I described, with the doubling of
> > characters in the front and the leftovers from previous transmissions at
> > the end?
> 
> No, I don't observe these errors when I use 'rts-gpios' in the device tree.
> 
> Maybe you could try to use 'rts-gpios' for a quick test by applying
> the patches I have just sent.
> 
> If you run this test, please remove 'uart-has-rtscts' from your dts.
> According to Documentation/devicetree/bindings/serial/serial.txt they
> are mutually-exclusive.

Just remuxed GPIO signals to these pads, applied your two patches and
used rts-gpios in the DT but I still see the same problem :/

When transmit something, I get doubled characters, then zeros and at the
end garbled data of previous transmissions, same as described in my
first post (Logic analyzer: https://pqgruber.com/rs485_results.png)
The data is always 4096 bytes long, this explains why the echo command
is blocking for about 4 seconds (<- 4096 bytes at a baudrate of 9600).
The TE line is also high until all 4096 bytes are sent.

I think this comes from the UART_XMIT_SIZE which is defined to the page
size.
Maybe there is something wrong in imx_transmit_buffer and leads to the
whole circular buffer being sent out all the time, not stopping..

Do these debug logs tell you anything?
https://gist.github.com/clemensg/1ac5ee8a8ea32acc9145c5aa8407aea5

I am analyzing the signals coming directly from the i.MX6Q, so this must
be a software problem, but I don't understand why it works for you, if
we use the same software.

Do you use any other patches on top of mainline and do you use the SDMA
scripts from the ROM?

Thanks,
Clemens

Re: imx: RS-485 problems during TX, maybe DMA related

[Fabio Estevam]

Hi Clemens,

On Sat, Jan 7, 2017 at 9:06 PM, Clemens Gruber
<clemens.gruber@pqgruber.com> wrote:

> Just remuxed GPIO signals to these pads, applied your two patches and
> used rts-gpios in the DT but I still see the same problem :/
>
> When transmit something, I get doubled characters, then zeros and at the
> end garbled data of previous transmissions, same as described in my
> first post (Logic analyzer: https://pqgruber.com/rs485_results.png)
> The data is always 4096 bytes long, this explains why the echo command
> is blocking for about 4 seconds (<- 4096 bytes at a baudrate of 9600).
> The TE line is also high until all 4096 bytes are sent.
>
> I think this comes from the UART_XMIT_SIZE which is defined to the page
> size.
> Maybe there is something wrong in imx_transmit_buffer and leads to the
> whole circular buffer being sent out all the time, not stopping..
>
> Do these debug logs tell you anything?
> https://gist.github.com/clemensg/1ac5ee8a8ea32acc9145c5aa8407aea5
>
> I am analyzing the signals coming directly from the i.MX6Q, so this must
> be a software problem, but I don't understand why it works for you, if
> we use the same software.
>
> Do you use any other patches on top of mainline and do you use the SDMA
> scripts from the ROM?

No, I use the original 4.9 + the two patches I sent. Yes, I do use the
SDMA scripts from ROM.

Here is the procedure I did to try to reproduce the issue you reported:

(The rs485conf is available at:
https://github.com/mniestroj/rs485conf/blob/master/main.c )

First of all I enable rs485 for ttymxc3 using the rs485conf application:

root@imx6qsabresd:/home# ./rs485conf  /dev/ttymxc3 -e 1
[   27.106517] random: crng init done
= Current configuration:
RS485 enabled:                false
RTS on send:                  high
RTS after send:               low
RTS delay before send:        0
RTS delay after send:         0
Receive during sending data:  true

= New configuration:
RS485 enabled:                true
RTS on send:                  high
RTS after send:               low
RTS delay before send:        0
RTS delay after send:         0
Receive during sending data:  true

= Saved configuration:
RS485 enabled:                true
RTS on send:                  high
RTS after send:               low
RTS delay before send:        0
RTS delay after send:         0
Receive during sending data:  true
root@imx6qsabresd:/ho

Then

root@imx6qsabresd:/home# echo A > /dev/ttymxc3

(wait 10 seconds)

root@imx6qsabresd:/home# echo B > /dev/ttymxc3

(wait 10 seconds)

root@imx6qsabresd:/home# echo C > /dev/ttymxc3

On the serial console at 9600bps only the:
A
B
C

are seen, so not duplicated characters, nor noise is seen on the console.

Regards,

Fabio Estevam

Re: imx: RS-485 problems during TX, maybe DMA related

[Fabio Estevam]

Hi Clemens,

On Sat, Jan 7, 2017 at 9:06 PM, Clemens Gruber
<clemens.gruber@pqgruber.com> wrote:

> Just remuxed GPIO signals to these pads, applied your two patches and
> used rts-gpios in the DT but I still see the same problem :/

As you have tested my 'rts-gpios' patches, would it be possible to
reply with your Tested-by tag?

Thanks

Re: imx: RS-485 problems during TX, maybe DMA related

[Clemens Gruber]

Hi Fabio,

On Sun, Jan 08, 2017 at 12:30:24AM -0200, Fabio Estevam wrote:
> Hi Clemens,
> 
> On Sat, Jan 7, 2017 at 9:06 PM, Clemens Gruber
> <clemens.gruber@pqgruber.com> wrote:
> 
> > Just remuxed GPIO signals to these pads, applied your two patches and
> > used rts-gpios in the DT but I still see the same problem :/
> >
> > When transmit something, I get doubled characters, then zeros and at the
> > end garbled data of previous transmissions, same as described in my
> > first post (Logic analyzer: https://pqgruber.com/rs485_results.png)
> > The data is always 4096 bytes long, this explains why the echo command
> > is blocking for about 4 seconds (<- 4096 bytes at a baudrate of 9600).
> > The TE line is also high until all 4096 bytes are sent.
> >
> > I think this comes from the UART_XMIT_SIZE which is defined to the page
> > size.
> > Maybe there is something wrong in imx_transmit_buffer and leads to the
> > whole circular buffer being sent out all the time, not stopping..
> >
> > Do these debug logs tell you anything?
> > https://gist.github.com/clemensg/1ac5ee8a8ea32acc9145c5aa8407aea5
> >
> > I am analyzing the signals coming directly from the i.MX6Q, so this must
> > be a software problem, but I don't understand why it works for you, if
> > we use the same software.
> >
> > Do you use any other patches on top of mainline and do you use the SDMA
> > scripts from the ROM?
> 
> No, I use the original 4.9 + the two patches I sent. Yes, I do use the
> SDMA scripts from ROM.
> 
> Here is the procedure I did to try to reproduce the issue you reported:
> 
> (The rs485conf is available at:
> https://github.com/mniestroj/rs485conf/blob/master/main.c )
> 
> First of all I enable rs485 for ttymxc3 using the rs485conf application:
> 
> root@imx6qsabresd:/home# ./rs485conf  /dev/ttymxc3 -e 1
> [   27.106517] random: crng init done
> = Current configuration:
> RS485 enabled:                false
> RTS on send:                  high
> RTS after send:               low
> RTS delay before send:        0
> RTS delay after send:         0
> Receive during sending data:  true
> 
> = New configuration:
> RS485 enabled:                true
> RTS on send:                  high
> RTS after send:               low
> RTS delay before send:        0
> RTS delay after send:         0
> Receive during sending data:  true
> 
> = Saved configuration:
> RS485 enabled:                true
> RTS on send:                  high
> RTS after send:               low
> RTS delay before send:        0
> RTS delay after send:         0
> Receive during sending data:  true
> root@imx6qsabresd:/ho
> 
> Then
> 
> root@imx6qsabresd:/home# echo A > /dev/ttymxc3
> 
> (wait 10 seconds)
> 
> root@imx6qsabresd:/home# echo B > /dev/ttymxc3
> 
> (wait 10 seconds)
> 
> root@imx6qsabresd:/home# echo C > /dev/ttymxc3
> 
> On the serial console at 9600bps only the:
> A
> B
> C
> 
> are seen, so not duplicated characters, nor noise is seen on the console.

I just did the experiment with your configuration and the rs485conf tool
you mentioned.
But still, no luck :(

What's the revision of the i.MX6Q on your board? Mine is 1.5 (TO 1.3)

Another example: If I run the following on the board..

while true; do
  echo ABCDEFGHIJKLM > /dev/ttymxc4
  sleep 0.5
  echo abc > /dev/ttymxc4 > /dev/ttymxc4
  sleep 0.5
done

Many transmits contain garbled (doubled and sometimes also extended to
a length of 4096 bytes, containing zeros) data.
I can see a few transmissions that are sent correctly, though.

Interesting side note: With the following patch, the problems disappear:

diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index 451e50f6d77a..eb9f0ce6c34a 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -1270,8 +1270,10 @@ static int imx_startup(struct uart_port *port)
 	writel(temp & ~UCR4_DREN, sport->port.membase + UCR4);
 
 	/* Can we enable the DMA support? */
+#if 0
 	if (!uart_console(port) && !sport->dma_is_inited)
 		imx_uart_dma_init(sport);
+#endif
 
 	spin_lock_irqsave(&sport->port.lock, flags);
 	/* Reset fifo's and state machines */
--

Regards,
Clemens

Re: imx: RS-485 problems during TX, maybe DMA related

[Fabio Estevam]

On Sun, Jan 8, 2017 at 4:06 PM, Clemens Gruber
<clemens.gruber@pqgruber.com> wrote:

> I just did the experiment with your configuration and the rs485conf tool
> you mentioned.
> But still, no luck :(
>
> What's the revision of the i.MX6Q on your board? Mine is 1.5 (TO 1.3)

Mine is a mx6solo rev1.1.

> Another example: If I run the following on the board..
>
> while true; do
>   echo ABCDEFGHIJKLM > /dev/ttymxc4
>   sleep 0.5
>   echo abc > /dev/ttymxc4 > /dev/ttymxc4

There is a typo here, this should be:
echo abc > /dev/ttymxc4

Fixed it locally.

>   sleep 0.5
> done
>
> Many transmits contain garbled (doubled and sometimes also extended to
> a length of 4096 bytes, containing zeros) data.
> I can see a few transmissions that are sent correctly, though.

This script runs correctly here and no issue is seen on the console.

Not sure why you get TXEN high for so long in your case.

> Interesting side note: With the following patch, the problems disappear:
>
> diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
> index 451e50f6d77a..eb9f0ce6c34a 100644
> --- a/drivers/tty/serial/imx.c
> +++ b/drivers/tty/serial/imx.c
> @@ -1270,8 +1270,10 @@ static int imx_startup(struct uart_port *port)
>         writel(temp & ~UCR4_DREN, sport->port.membase + UCR4);
>
>         /* Can we enable the DMA support? */
> +#if 0
>         if (!uart_console(port) && !sport->dma_is_inited)
>                 imx_uart_dma_init(sport);
> +#endif

Looks like you disabled DMA.

Regards,

Fabio Estevam

Re: imx: RS-485 problems during TX, maybe DMA related

[Clemens Gruber]

Hi Fabio,

On Sun, Jan 08, 2017 at 07:46:29PM -0200, Fabio Estevam wrote:
> > What's the revision of the i.MX6Q on your board? Mine is 1.5 (TO 1.3)
> 
> Mine is a mx6solo rev1.1.

Could it be dependent upon SMP? Do you have an i.MX6Q board around to
try?

--

I made a few interesting discoveries in the meantime:

1) If I do not enable UCR4_TCEN, the data on TXD is fine. Of course the
TE pin does not toggle in that case, but it shows that the problem has
something to do with the actions taking place after the transmit
complete interrupt and not with the hardware or DMA internals.

2) I added a few custom printks when doing echo A > /dev/ttymxc4 in
RS-485 mode:

imx_start_tx
imx_dma_tx: tx_bytes=2, xmit->tail=0, xmit->head=2
imx_dma_tx: dma_tx_nents=1
imx-uart 21f4000.serial: TX: prepare to send 2 bytes by DMA
imx_transmit_buffer: xmit->tail set to 1, xmit->head=2
imx_transmit_buffer: xmit->tail set to 2, xmit->head=2
imx_stop_tx (returns immediately because dma_is_txing)
^ repeats multiple times
imx_stop_tx (goes through)
dma_tx_callback: xmit->tail=2 tx_bytes=2
dma_tx_callback: xmit->tail set to 4
imx-uart 21f4000.serial: we finish the TX DMA.
dma_tx_callback: xmit->tail=4 icount.tx=4
imx_dma_tx: tx_bytes=4094, xmit->tail=4, xmit->head=2		(!!)
imx_dma_tx: dma_tx_nents=2
..

That's why the data is garbled in that way: It wraps around the circular
buffer. xmit->tail jumps over xmit->head, which explains why I first see
the correct characters, then again followed by many zeros and at the end
again the correct characters.

Regards,
Clemens

Re: imx: RS-485 problems during TX, maybe DMA related

[Fabio Estevam]

Hi Clemens,

On Tue, Jan 10, 2017 at 10:33 PM, Clemens Gruber
<clemens.gruber@pqgruber.com> wrote:
> Hi Fabio,
>
> On Sun, Jan 08, 2017 at 07:46:29PM -0200, Fabio Estevam wrote:
>> > What's the revision of the i.MX6Q on your board? Mine is 1.5 (TO 1.3)
>>
>> Mine is a mx6solo rev1.1.
>
> Could it be dependent upon SMP? Do you have an i.MX6Q board around to
> try?

Unfortunately the only hardware I can test RS485 is based on mx6solo.

Adding Tim Harvey, who could probably test RS485 on MX6Q.

Regards,

Fabio Estevam