Re: imx: RS-485 problems during TX, maybe DMA related
Hi Clemens, On Tue, Jan 10, 2017 at 10:33 PM, Clemens Gruberwrote: > 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
Re: imx: RS-485 problems during TX, maybe DMA related
Hi Clemens, On Tue, Jan 10, 2017 at 10:33 PM, Clemens Gruber 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
Re: imx: RS-485 problems during TX, maybe DMA related
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
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
On Sun, Jan 8, 2017 at 4:06 PM, Clemens Gruberwrote: > 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
On Sun, Jan 8, 2017 at 4:06 PM, Clemens Gruber 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
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 >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(>port.lock, flags); /* Reset fifo's and state machines */ -- Regards, Clemens
Re: imx: RS-485 problems during TX, maybe DMA related
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 > 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(>port.lock, flags); /* Reset fifo's and state machines */ -- Regards, Clemens
Re: imx: RS-485 problems during TX, maybe DMA related
Hi Clemens, On Sat, Jan 7, 2017 at 9:06 PM, Clemens Gruberwrote: > 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
Hi Clemens, On Sat, Jan 7, 2017 at 9:06 PM, Clemens Gruber 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
Hi Clemens, On Sat, Jan 7, 2017 at 9:06 PM, Clemens Gruberwrote: > 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
Hi Clemens, On Sat, Jan 7, 2017 at 9:06 PM, Clemens Gruber 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
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 >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
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 > 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
Hi Clemens, On Sat, Jan 7, 2017 at 6:59 PM, Clemens Gruberwrote: > 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
Hi Clemens, On Sat, Jan 7, 2017 at 6:59 PM, Clemens Gruber 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
On Sat, Jan 07, 2017 at 02:48:03PM -0200, Fabio Estevam wrote: > On Sat, Jan 7, 2017 at 1:34 PM, Clemens Gruber >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
On Sat, Jan 07, 2017 at 02:48:03PM -0200, Fabio Estevam wrote: > On Sat, Jan 7, 2017 at 1:34 PM, Clemens Gruber > 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
On Sat, Jan 7, 2017 at 1:34 PM, Clemens Gruberwrote: > 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
On Sat, Jan 7, 2017 at 1:34 PM, Clemens Gruber 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
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
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
Hi Clemens, On Sat, Jan 7, 2017 at 11:45 AM, Clemens Gruberwrote: > 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
Hi Clemens, On Sat, Jan 7, 2017 at 11:45 AM, Clemens Gruber 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
Hi Fabio, On Fri, Jan 06, 2017 at 10:31:16PM -0200, Fabio Estevam wrote: > Yes, I have tried like this: > > { > pinctrl-names = "default"; > pinctrl-0 = <_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
Hi Fabio, On Fri, Jan 06, 2017 at 10:31:16PM -0200, Fabio Estevam wrote: > Yes, I have tried like this: > > { > pinctrl-names = "default"; > pinctrl-0 = <_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
Hi Clemens, On Fri, Jan 6, 2017 at 8:50 PM, Clemens Gruberwrote: > 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: { pinctrl-names = "default"; pinctrl-0 = <_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: { pinctrl-names = "default"; pinctrl-0 = <_uart4>; rts-gpios = < 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
Hi Clemens, On Fri, Jan 6, 2017 at 8:50 PM, Clemens Gruber 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: { pinctrl-names = "default"; pinctrl-0 = <_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: { pinctrl-names = "default"; pinctrl-0 = <_uart4>; rts-gpios = < 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
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 >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
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 > 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
Hi Clemens, On Wed, Jan 4, 2017 at 2:00 PM, Clemens Gruberwrote: > 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
Hi Clemens, On Wed, Jan 4, 2017 at 2:00 PM, Clemens Gruber 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
imx: RS-485 problems during TX, maybe DMA related
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.
imx: RS-485 problems during TX, maybe DMA related
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.