UART1 not working

To rule out any hardware issues, put a scope on U9:Pin 3 and check to make sure you are seeing the correct baud rate and voltage levels.

You can verify you have set the device baud rate correctly by writing data out on UART1_TXD and scoping the signal to see if you get 9600 baud.

Jeff

Many thanks for the quick reply Jeff! Below is what I see with the scope on U9:

Pin 1: 3.3V (as expected from SEL_EXP2_UART1)

Pin 2: some signal with max voltage of 0V and min voltage of - 0.9V

Pin 3: the transmitted signal from my device with max voltage 3.3 V.  On it is superimposed the signal from Pin 2 i.e. min voltage on Pin 3 is -0.9V. The baud rate is 9600 baud as is given in the specification of my device.

Pin 4: same as Pin 3.

Pin 5: some signal with max voltage of 0.1V and min voltage -0.3 V

Pin 6: 3.3V ( I see the constant 3.3V signal also on the UART_RX pin of my device)

Pin 7: 3.3V

Pin 8: GND.

When I continuously write to /dev/ttyS1 I see no change on  Pin 7 (U9) and I cannot understand why. Below is the code to open the port:

#include <stdio.h>   /* Standard input/output definitions */
#include <stdlib.h>   /* Standard input/output definitions */
#include <string.h>  /* String function definitions */
#include <unistd.h>  /* UNIX standard function definitions */
#include <fcntl.h>   /* File control definitions */
#include <errno.h>   /* Error number definitions */
#include <termios.h> /* POSIX terminal control definitions */

struct termios options;

    fd = open("/dev/ttyS1", O_RDWR | O_NOCTTY | O_NDELAY);

    if (fd == -1)
    {
        fprintf(stderr, "open_port: Unable to open /dev/ttyS0 - Check the connection ");fflush(stderr);
    }
    else
    {
        fcntl(fd, F_SETFL, 0);
    }

    tcgetattr(fd, &options);          // Get the current options for the port
    cfsetispeed(&options, B9600);         // Set the baud rate for the input to 9600 baud
    cfsetospeed(&options, B9600);        // Set the baud rate for the output to 9600 baud

    options.c_cflag &= ~PARENB;        // No parity check
    options.c_cflag &= ~CSTOPB;        // One stop bit
    options.c_cflag &= ~CSIZE;        // Mask the character size bits
    options.c_cflag |= CS8;            // Select 8 data bits
    options.c_cflag &= ~CRTSCTS;    // Disable Hardware Flow Control


    /* set raw input */
    options.c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP | INLCR | IGNCR | ICRNL | IXON | IXOFF | IXANY);
    options.c_lflag &= ~(ECHO | ECHONL | ECHOE | ICANON | ISIG | IEXTEN);

    options.c_cflag     |= (CLOCAL | CREAD);        // Enable the receiver and set local mode...
    options.c_oflag     &= ~OPOST;
    options.c_cc[VMIN]  = 100;            // Blocking read until 100 chars received
    options.c_cc[VTIME] = 0;                        // Inter-character timer

    tcsetattr(fd, TCSANOW, &options);            // Set the new options for the port...

and to write:

nBytes = write(fd, bufptr, sizeof(bufptr));
if (nBytes != sizeof(bufptr))
{
       fprintf(stdout," write error\n"); fflush(stdout);
}

I appreciate very much your help to this problem!

There seems to be two issues:

1) You should not see anything from pin 2 superimposed onto pin 3 or 4. That is either a probing error or a short on the board. Does it look bad enough that it is possible the DSP is not able to read the data because of this?

2) If you see nothing on pin 7, it is probably because the pinmuxing has not be configured for that pin. Check the SYSCFG registers to verify that pin is set at UART1_TXD.

Jeff

I modified in "/arch/arm/mach-da8xx/board-evm.c" the pin assignments as follows: 

static const short evm_uart1_pins[] = {
  DA8XX_UART1_RXD, DA8XX_UART1_TXD,
  -1
}

static const short evm_mcasp0_pins[] = {
  -1
}

static const short evm_spi1_pins[] = {
  -1
}

 /* Enable UART1 power managment register PWREMU_MGMT (see SPUFM6.pdf pag. 38) */
 davinci_writel( (0x01 | (0x03 << 13)), DA8XX_UART1_BASE + 0x30 ); 

I rebuild the kernel and now I can see the transmitted signals with the scope on U9:Pin7 (and at Rxd of my device). I can also read the data so the superimposing does not seem to be a problem. 

However, the data that I receive is wrong because my device uses a negative voltage level for INACTIVE (MARK) and positive voltage level for ACTIVE (SPACE) while the UART driver on the OMAP-L137 uses a positive voltage level for INACTIVE (MARK) and negative voltage level for ACTIVE (SPACE). Thus, both the START, STOP and data are inverted.

How can I make the protocols match i.e. to make the OMAP-L137 use negative voltage as MARK (1)  and  positive voltage for  SPACE (0) as in the actual RS-232 specification? I guess one solution would be to create a HW interface with 4 inverters to inverted the lines but I would like to have a software solution if possible.