Hello, I'm trying to use UART6 (/dev/ttymxc5) from the A9. I added the following lines to imx6sx-udoo-neo.dtsi, recompiled the .dtbs and replaced the old ones : Code: pinctrl_uart6_1: uart6grp-1 { fsl,pins = < MX6SX_PAD_CSI_DATA04__UART6_RX 0x1b0b1 // GPIO_18 MX6SX_PAD_CSI_DATA05__UART6_TX 0x1b0b1 // GPIO_19 >; }; &uart6 { pinctrl-names = "default"; pinctrl-0 = <&pinctrl_uart6_1>; status = "okay"; }; However, when I try to use /dev/ttymxc5 from the A9 I can send but not receive messages. I tried the same approach for the device tree setup and UART5 with its GPIOs 179 and 178. For UART5 RX/TX worked without any problems. Has anybody else tried to use UART6 on the A9 and Udoobuntu?
Everything seems fine. Can you try to check if the pin RX is declared in the device tree in another way? Otherwise, you could try to declare them as GPIOs and see if they work.
The RX pin CSI_DATA04 isn't used in the device tree except when configured for UART6 (checked with grep -nrwo "\w*CSI_DATA04\w*") The GPIO works using as output on both, the M4 and the A9. I also noticed that if I continuously send data (holding a key pressed on sender side) I receive "imx-uart 22a0000.serial: Rx FIFO overrun" on UART1. However, minicom/screen doesn't show that any data was received.
I also tried using UART6 with the M4, which works fine. Code snippet from MQX init_gpio.c: Code: case 6: /* Enable pin mux */ if (flags & IO_PERIPHERAL_PIN_MUX_ENABLE){ IOMUXC_SW_MUX_CTL_PAD_CSI_DATA04 = IOMUXC_SW_MUX_CTL_PAD_CSI_DATA04_MUX_MODE(4); IOMUXC_SW_MUX_CTL_PAD_CSI_DATA05 = IOMUXC_SW_MUX_CTL_PAD_CSI_DATA05_MUX_MODE(4); IOMUXC_SW_PAD_CTL_PAD_CSI_DATA04 = IOMUXC_SW_PAD_CTL_PAD_CSI_DATA04_PKE_MASK | \ IOMUXC_SW_PAD_CTL_PAD_CSI_DATA04_PUE_MASK | \ IOMUXC_SW_PAD_CTL_PAD_CSI_DATA04_PUS(2) | \ IOMUXC_SW_PAD_CTL_PAD_CSI_DATA04_SPEED(2) | \ IOMUXC_SW_PAD_CTL_PAD_CSI_DATA04_DSE(6) | \ IOMUXC_SW_PAD_CTL_PAD_CSI_DATA04_SRE_MASK | \ IOMUXC_SW_PAD_CTL_PAD_CSI_DATA04_HYS_MASK; IOMUXC_SW_PAD_CTL_PAD_CSI_DATA05 = IOMUXC_SW_PAD_CTL_PAD_CSI_DATA05_PKE_MASK | \ IOMUXC_SW_PAD_CTL_PAD_CSI_DATA05_PUE_MASK | \ IOMUXC_SW_PAD_CTL_PAD_CSI_DATA05_PUS(2) | \ IOMUXC_SW_PAD_CTL_PAD_CSI_DATA05_SPEED(2) | \ IOMUXC_SW_PAD_CTL_PAD_CSI_DATA05_DSE(6) | \ IOMUXC_SW_PAD_CTL_PAD_CSI_DATA05_SRE_MASK | \ IOMUXC_SW_PAD_CTL_PAD_CSI_DATA05_HYS_MASK; IOMUXC_UART6_IPP_UART_RXD_MUX_SELECT_INPUT = 0; } /* Disable pin mux to the default gpio */ if (flags & IO_PERIPHERAL_PIN_MUX_DISABLE){ IOMUXC_SW_MUX_CTL_PAD_CSI_DATA04 = IOMUXC_SW_MUX_CTL_PAD_CSI_DATA04_MUX_MODE(5); IOMUXC_SW_MUX_CTL_PAD_CSI_DATA05 = IOMUXC_SW_MUX_CTL_PAD_CSI_DATA05_MUX_MODE(5); } status = MQX_OK; break; and code from init structure: Code: const IMX_UART_INIT_STRUCT _bsp_sci2_init = { /* queue size */ 64, /* Channel */ 6, /* Clock Speed */ BSP_PLL3_UART_CLOCK, /* Baud rate */ 115200, /* RX/TX Int vect */ INT_UART6, /* ERR Int vect */ 0, /* RX/TX priority */ 3, /* ERR priority */ 4, };
I see the same overrun error when trying to using UART6. Interestingly enough, I first ran into it the same day that 1chi did. But I was able to take a different path in order to make progress on that day's project. Now I've spent a few hours revisiting the issue, and I still see the overrun issue. I've checked the lines with an oscilloscope: the tx bytes come out of the A9, and the rx bytes in response are transmitted at the correct baud, but it overruns the A9 every time. Even small messages cause the issue, corresponding to 1chi's comment about pressing the Enter key to reproduce the issue. It's nothing obvious in the dts file. Enabling any of the other CSI_DATA04/CSI_DATA05 features like PWM caused a mux error at boot time, so I don't believe that any other instances that are 'disabled' are interfering. I'll try to spend more time with it when I can, because I really don't want to add a USB-to-serial adapter (power consumption and larger enclosure) when there's a UART that should be usable. Here is the DTS change that I made on the latest UDOO Neo kernel code. Code: index 6225aa7..c410d0a 100644 --- a/arch/arm/boot/dts/imx6sx-udoo-neo-externalpins.dtsi +++ b/arch/arm/boot/dts/imx6sx-udoo-neo-externalpins.dtsi @@ -28,10 +28,10 @@ MX6SX_PAD_CSI_DATA01__GPIO1_IO_15 MX6SX_PAD_CSI_DATA02__GPIO1_IO_16 MX6SX_PAD_CSI_DATA03__GPIO1_IO_17 - MX6SX_PAD_CSI_DATA04__GPIO1_IO_18 - MX6SX_PAD_CSI_DATA05__GPIO1_IO_19 - MX6SX_PAD_CSI_DATA06__GPIO1_IO_20 - MX6SX_PAD_CSI_DATA07__GPIO1_IO_21 +// MX6SX_PAD_CSI_DATA04__GPIO1_IO_18 +// MX6SX_PAD_CSI_DATA05__GPIO1_IO_19 +// MX6SX_PAD_CSI_DATA06__GPIO1_IO_20 +// MX6SX_PAD_CSI_DATA07__GPIO1_IO_21 //MX6SX_PAD_USB_H_STROBE__GPIO7_IO_11 0x800000 //MX6SX_PAD_USB_H_DATA__GPIO7_IO_10 @@ -185,7 +185,7 @@ pinctrl-names = "default"; pinctrl-0 = <&pinctrl_uart6>; fsl,uart-has-rtscts; - status = "disabled"; + status = "okay"; }; &i2c2 {
Hi bander, I'm sorry I don't have a solution yet either and currently not the time to look into it. I'm pretty sure that the problem is not related to the device tree configuration. As you said, an invalid pin configuration should produce a mux error at boot time. There is also nothing wrong with the board since the UART is working from the M4. However, looking at Figure 65-5 in the i.MX6SX reference manual, an overrun exception occurs only if a valid character was received. IMO, this leaves two options where things can go wrong: For some reason the Linux driver does not handle an RX interrupt on UART6 unlikely since there is one common ISR for RX, TX and errors (e.g. overrun). If the interrupt vectors are setup wrong then transmitting should not be possible either... Something goes wrong when writing to the RX_FIFO in the last step of Figure 65-5 I think this is where things go wrong. It could be related to the DMA setup in this step. Unfortunately, I didn't have the time to go through the driver code yet
This is in RC1 drop? Is there any way to get the new dtweb functionality without doing a from scratch SD card flash? I have the latest kernel, just not the latest applications. Is dtweb a package I can get through apt-get?
Yes, you can install (or update) dtweb from apt-get avoiding a full SD card flash. Just run Code: sudo apt-get update sudo apt-get install dtweb
I couldn't get UART6 working, even after reflashing to a fresh RC1. After a friend pointed me to this post in another forum, http://forum.embeddedarm.com/showthread.php?1170-UART-Rx-Fifo-Overrun-Error I was able to get it working with the following patch to the kernel (and enabling it in dtweb, nothing else): Code: diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c index b27d3fe..d89c825 100644 --- a/drivers/tty/serial/imx.c +++ b/drivers/tty/serial/imx.c @@ -1221,7 +1221,8 @@ static int imx_startup(struct uart_port *port) /* Can we enable the DMA support? */ if (is_imx6q_uart(sport) && !uart_console(port) - && !sport->dma_is_inited) + && !sport->dma_is_inited + && !sport->port.flags == UPF_LOW_LATENCY) imx_uart_dma_init(sport); if (sport->dma_is_inited) {
Same for me. I tried both, with and without hardware flow control, but the problem remains the same... RX on UDOO NEO does not work, I still get the buffer overrun, etc. @Francesco Did you get UART6 working without any other steps? So something is wrong with the DMA settings...
@Francesco , @Andrea Rovai Just a up to inform you that you didn't add the correction to udoobuntu2 , already need to recompile the kernel to have rx ok on uart6 (A9 side).
Dear @modjo, Francesco, who's developing at the moment and can't answer, told me it works on his side, so please, would you mind explaining exactly what doesn't work?
No problem i understand ... i have the same problem like describe here : imx-uart 22a0000.serial: Rx FIFO overrun need to use bander patch to correct this error ...
Guys, this patch of yours meant for the UDOO QUAD would NEVER work on UDOO NEO, I can't understand why you say it works. The patch is for UDOO QUAD. Ok, I haven't tried it, but seems quite impossible.
Hi, I needed to use UART6 in udoo neo running UDOObuntu_neo_v2.0rc1, and I can tell you that this patch also work in udoo neo, as modjo posted.
