OMAP-L138 UART2 Flow Control Issues

Hello

I'm trying to setup UART2 for 115200 8n1 configuration and hardware flow control on an OMAP-L138 processor. The purpose of this configuration to communicate with a TI GPS/Bluetooth chip. This is not an EVM board, but our own custom board. I have read through a few posts already on the e2e forums, and found this one which is close, but doesn't have a good solution.

I am running linux v3.3 on the OMAP and trying to use the serial port as a tty device (/dev/ttyS1).

I have verified the following information:

  * Pinmuxing the CTS/RTS registers, following code in da850.c:

	+ MUX_CFG(DA850, NUART2_CTS,	0,	28,	15,	4,	false)
	+ MUX_CFG(DA850, NUART2_RTS,	0,	24,	15,	4,	false)


* Enabling UART2 with the davinci_serial_init function and setting bit 2 in the config struct

* Current register dump right before transmit:

UART8250: fed0d000 = reg_0 = 0x00000000
UART8250: fed0d004 = reg_1 = 0x00000007
UART8250: fed0d008 = reg_2 = 0x000000c1
UART8250: fed0d00c = reg_3 = 0x00000013
UART8250: fed0d010 = reg_4 = 0x00000023
UART8250: fed0d014 = reg_5 = 0x00000000
UART8250: fed0d018 = reg_6 = 0x00000000
UART8250: fed0d01c = reg_7 = 0x00000000
UART8250: fed0d020 = reg_8 = 0x000000b6
UART8250: fed0d024 = reg_9 = 0x00000001
UART8250: fed0d028 = reg_10 = 0x44141102
UART8250: fed0d02c = reg_11 = 0x00000000
UART8250: fed0d030 = reg_12 = 0x00006003
UART8250: fed0d034 = reg_13 = 0x00000000

  * In my debugging I have made a few "hacks" to 8250.c (marked with "//todo ajr") and have attached the modified file

  * * These hacks allowed me to bypass tty->hw_stopped checks and print various information

  * * Additionally I modified the code set the RTS bit in the MCR when setting cflag CRTSCTS

The current behavior that I see when trying to write a small buffer to /dev/ttyS1 is that only the first byte is written out, but nothing else. Using print statements (in 8250.c and serial_core.c), I have verified that these values are being written to the THR, but not all are being written out. I am using an oscilloscope on the tx line to verify that data is being written out. However, I never see the CTS line go low, so that may be an additional issue (with the NL5500L chip). I have followed all startup procedure for the 5500 chip, including supplying stable clocks, power, and deasserting the shutdown line.

Here is the test application I am running to write to the tty device:

#include <stdio.h>
#include <unistd.h>
#include <stdint.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <sys/ioctl.h>
#include <termios.h>

#define RX_SZ   11
#define MSG_SZ  6
static const uint8_t msg[MSG_SZ] = {0x09, 0x02, 0x02, 0x00, 0x00, 0x00};

int main(void)
{
        int i, j;
        uint8_t rx[RX_SZ];
        struct termios sp_options;
        int serial_port = open("/dev/ttyS1", O_RDWR | O_NOCTTY);
        speed_t speed = 115200;

        if (serial_port < 0)
        {
                printf("error opening serial port\n");
                return -1;
        }
        else
        {
                printf("setting sp options\n");
                tcgetattr(serial_port, &sp_options);
                cfmakeraw(&sp_options);
                cfsetispeed(&sp_options, speed);
                cfsetospeed(&sp_options, speed);
                sp_options.c_cflag |= CRTSCTS;
                tcsetattr(serial_port, TCSANOW, &sp_options);
        }

        i = write(serial_port, msg, MSG_SZ);
        if (i < 0) {
                printf("error writing to serial port, %d\n", i);
                return -1;
        } else {
                j = tcdrain(serial_port);
                printf("tcdrain = %d, wrote %d bytes\n", j, i);
        }

        i = read(serial_port, rx, RX_SZ);
        if (i < 0) {
                printf("error reading serail port, %d\n", i);
                return -1;
        }

        for (i=0; i<RX_SZ; i++)
        {
                printf("%02x : ", rx[i]);
        }

        return 0;
}

I have been stuck on this simple issues for a few days now am starting to get frustrated and run out of ideas on what could be going wrong. Please let me know if further information is needed.

Austin

(Please visit the site to view this file)

(Please visit the site to view this file)