Hi, Re this diagram: http://udoo.org/download/files/pinout/Udoo_pinout_diagram.pdf I am trying to communicate with Xbee serial from linux with one of the PINS marked RX/TX 1, 2 3 coresponding to UART 4 and 5 (on gpio's 150-162, 160-161, 158-159), without any success. Though if I am using /dev/ttymxc3 I can see some but the bus hangs in no time. I would like to use /dev/ttymxc1|0. Does anyting has to be enabled in kernel before thes pins can be used as serial. If yes then which would be the devices associated. I see 3 devices /dev/ttymxc0 /dev/ttymxc1 and /dev/ttymxc3 Thank you.
Solved I use UART5 on pins 48 and 49. I changed the Kernel_Unico/arch/arm/mach-mx6/board-mx6qd_seco_UDOO.h pins setup for UART5
Hello, I'm Simone. I have the same problem, I have to comincare an external card on Linux using a serial port. I could not change the kernel, could you please make a step by step guide.
Only two of the five I.MX6 UARTs are really open and usable for general purpose I/O. /dev/ttymxc0 (UART1) is, for all practical purposes inaccessible and wasted on the UDOO board, due to the way its signals are routed. The IMX6 datasheet shows two possible pairs of pins that UART can be assigned to-- SD3_DAT6 / SD3_DAT7 and CSI0_DAT10 / CSI0_DAT11. According to UDOO_REV_D schematics, the first pair is not bonded out at all (you'd have to get under the surface-mount CPU somehow to reach those pins!), and the second, for some strange reason has been connected in parallel with the SAM3X(Arduino) chip's UART1-- search schematic sheet 15 for "USART0_RX" to see what I mean. Not only is this redundant with the UART4 (/dev/ttymxc3) actually used for iMX6<-->SAM3X programming and communication, the UART1-UART1 connection is TX to TX, RX to RX, and so is useless for inter-chip I/O. I guess this might be a design error, perhaps a remnant of an earlier idea for communication between the CPUs, before they decided to use UART4 instead. It could conceivably be used if you're willing to give up the SAM3X's main serial port (setting pins on that side as inputs so they don't conflict, or just holding the entire chip in reset), but then UART4 would still prevent those from being used independently. Finding and removing the the 33-ohm resistors shown in schematics as R1034, R1036, then soldering to their pads could work too, but probably isn't worth the trouble. On the board these are tiny little surface-mount resistors, none of which are labeled, amidst of sea of identical ones. /dev/ttymxc1 (UART2) is the serial boot/debugging console, routable to the same rear-panel USB port that can also be used for Arduino programming. On most other i.MX6 dev boards UART1 fills this role, but for the above reasons that one wasn't available. Unlike UART1, this one can be rerouted to different pins if you're willing to give up and disable the USB-serial console. /dev/ttymxc2 (UART3) is unused and available (after being enabled in kernel config). It can be routed to two different pairs of header pins, as you prefer to minimize conflict with other functions. /dev/ttymxc3 (UART4) is the internal i.MX6--SAM3X(Arduino) bridge link. If you don't need that function, and don't want it tied to the main pins 0/1 Arduino serial, it can be rerouted via kernel pinmuxing to appear instead on the RXD2/TXD2 headers, but will then block use of that second SAM3X port. I wouldn't mess with this one. /dev/ttymxc4 (UART5) is the second and final one that's completely unused and available, and can also route to two possible pin sets. It's been a while, but I believe I had to turn on UART3 and UART5 in board-mx6_seco_UDOO.c, adding imx6q_add_imx_uart(2, NULL); and imx6q_add_imx_uart(4, NULL); to the labeled "UART" section of that file, in addition to making pinmux changes in board-mx6qd_seco_UDOO.h. Newer distributions may not require this-- check whether or not /dev/ttymxc2 and /dev/ttymxc4 already exist.
