Yes I probed the pad directly (rather than the connector) and I’ve even tried two different Beagleboards, with the same result. Note that when I say UART1 I really mean the UART corresponding to /dev/ttyO1. The BB documentation talks about /dev/ttyO1 as being UART2. I know I have the right UART because the TXD RXD and CTS pins are all working; I’m only having trouble with the RTS pin.
Here’s the code I added to mux the UART1 pins, found in arch/arm/omap2-mach/board-omap3beagle.c:
static struct omap_board_mux board_mux[] __initdata = {
/* configure the DM3730 processor pads for /dev/ttyO1. /
OMAP3_MUX(MCBSP3_FSX,OMAP_MUX_MODE1 | OMAP_PIN_INPUT), / uart_rx /
OMAP3_MUX(UART2_TX,OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT), / uart_tx /
OMAP3_MUX(UART2_CTS,OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP), / uart_cts /
OMAP3_MUX(UART2_RTS,OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT), / uart_rts */
{ .reg_offset = OMAP_MUX_TERMINATOR },
};
Here’s a snippet of my Linux application code to set the RTS line from user space:
fd = open("/dev/ttyO1",O_RDWR);
int ioctl_arg;
int status = ioctl(fd,TIOCMGET,&ioctl_arg);
if (enable_RTS) {
ioctl_arg |= TIOCM_RTS;
} else {
ioctl_arg &= ~(int)TIOCM_RTS;
}
status = ioctl(fd,TIOCMSET,&ioctl_arg);
/* now probe the RTS pin, before closing the port */
I know the above code normally works because we do this all the time in Linux with standard PC computers running Linux.
But when I probe connector P9 pin 10 (the RTS signal), it is always grounded at 0VDC. In fact, I even tried putting an external pullup resistor (10k ohm) to 1.8VDC, thinking that maybe the RTS output pin from the DM3730 is some kind of an open-collector/open-drain output. But even with the pullup resistor, the signal at P9 pin 10 is always grounded at 0VDC (regardless of whether RTS is asserted or deasserted in software). So the RTS pin (P9 pin 10) is somehow electrically connected to ground internally by the DM3730, regardless of the RTS software setting in the Linux kernel.
I double checked everything a hundred times at this point, and it all points to a bug somewhere, either in hardware, the kernel driver, or the documentation.
Where in the kernel source tree is the RTS handling for the OMAP3 processor serial ports handled? I looked around the kernel tree but it is quite a maze and hard to actually find the logic that is setting the OMAP3 registers to set/clear RTS. If I can find this code, I can add some kernel debug so I can see if the code is even being reached, and if so, what is it doing to the OMAP3 registers. I can then compare what it’s doing with what the DM3730 TRM says it should be doing.
Again, any help is greatly appreciated. We have an order for 200 of these units, but we must have this UART working, and it must support RTS/CTS flow control.
-Eric
