COM2 Problem with OpenBSD4.3 on NET4501

[grice]

OpenBSD 4.3 installed smoothly, but I’ve been wrestling with serial
communication over COM2 for days now.  At the moment I have a simple C program
designed to echo any data sent to the serial port to stdout.  I’ve tested the
program on other OpenBSD 4.3 PCs without issue, but when I move the code to
the Soekris board, I see data being received, but it’s entirely corrupted.  At
this point I have tried sending the data at multiple baud rates, both with and
without CTS/RTS.  The results are always the same.  I receive data as it’s
being sent, but it’s not the data I expect.

The code for the echo program is listed below.  Must CTS/RTS be connected?  I
noticed in another message thread, 19200 is the recommended baud rate for
COM2.  Is this true?  If so, why?  Must I use 19200?  Any other
recommendations?

Strangely enough, I actually always receive data back from the COM2 connection
as well, whether the echo program is running or not.  For example, sending the
character ‘t’, I get back 0x0000.  If I send “test”, I receive
0x000246000000.  Again, this occurs whether or not the program is running
(note that the program doesn’t actually return anything via the serial port at
all).   I suspect this is a configuration issue, but quite honestly I’m a
loss.  Any suggestions would be greatly welcomed.

Have a great weekend - Greg

Echo Program:

#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <termios.h>
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <unistd.h>
       
#define BAUDRATE B9600
#define MODEMDEVICE "/dev/cua01"
#define _POSIX_SOURCE 1 /* POSIX compliant source */ #define FALSE 0 #define
TRUE 1

int main(int argc, char **argv)
{
      unsigned char serialbuf[512];
      int fd, resume;
      struct termios oldtio, newtio;

      int n = 0;

      // Open serial port for communications
      fd = open(MODEMDEVICE, O_RDWR | O_NOCTTY);
      if (fd < 0)
      {
            perror(MODEMDEVICE);
            exit(-1);
      }
      else
      {
            printf("\nSerial Port Initializing...\n\n");
      }
   
      // Save existing port settings
      tcgetattr(fd, &oldtio);    
      bzero(&newtio, sizeof(newtio));
   
      /*
             CRTSCTS : flow control
             CS8     : 8N1
             CLOCAL  : local connection, no modem contol
             CREAD   : enable receiving characters
      */
      newtio.c_cflag = BAUDRATE | CS8 | CLOCAL | CREAD | CRTSCTS;

      newtio.c_iflag = IGNPAR;
      newtio.c_oflag = 0;
      newtio.c_lflag = 0;

      newtio.c_cc[VTIME]    = 0;  
      newtio.c_cc[VMIN]     = 1;    
   
      // Activate settings
      tcflush(fd, TCIFLUSH);
      tcsetattr(fd,TCSANOW,&newtio);
   
      // Begin Receiving serial data communication
      printf("\nReceiving on Serial Port...\n");
      while(1)
      {
            resume = read(fd,serialbuf,512);
            if (resume > 0)
            {  
              printf("Size: %d\n", resume);
              for (n=0; n<resume; n++)
                  printf("%c\n",serialbuf[n]);
            }
           
      }
      tcsetattr(fd, TCSANOW, &oldtio);
      return 0;
}






_______________________________________________
Soekris-tech mailing list
Soekris-tech@...
http://lists.soekris.com/mailman/listinfo/soekris-tech

[Xavier Milliès-Lacroix]

The speed 19200 is only to have a faster communication vs the traditionnal
9600 baud. IMHO.

Xavier.

-----Message d'origine-----
De : soekris-tech-bounces@...
[mailto:soekris-tech-bounces@...] De la part de
grice@...
Envoyé : mercredi 23 juillet 2008 03:05
À : soekris-tech@...
Objet : [Soekris] COM2 Problem with OpenBSD4.3 on NET4501

OpenBSD 4.3 installed smoothly, but Ive been wrestling with serial
communication over COM2 for days now.  At the moment I have a simple C
program
designed to echo any data sent to the serial port to stdout.  Ive tested
the
program on other OpenBSD 4.3 PCs without issue, but when I move the code to
the Soekris board, I see data being received, but its entirely corrupted.
At
this point I have tried sending the data at multiple baud rates, both with
and
without CTS/RTS.  The results are always the same.  I receive data as its
being sent, but its not the data I expect.

The code for the echo program is listed below.  Must CTS/RTS be connected?
I
noticed in another message thread, 19200 is the recommended baud rate for
COM2.  Is this true?  If so, why?  Must I use 19200?  Any other
recommendations?

Strangely enough, I actually always receive data back from the COM2
connection
as well, whether the echo program is running or not.  For example, sending
the
character t, I get back 0x0000.  If I send test, I receive
0x000246000000.  Again, this occurs whether or not the program is running
(note that the program doesnt actually return anything via the serial port
at
all).   I suspect this is a configuration issue, but quite honestly Im a
loss.  Any suggestions would be greatly welcomed.

Have a great weekend - Greg

Echo Program:

#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <termios.h>
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <unistd.h>
       
#define BAUDRATE B9600
#define MODEMDEVICE "/dev/cua01"
#define _POSIX_SOURCE 1 /* POSIX compliant source */ #define FALSE 0 #define

TRUE 1

int main(int argc, char **argv)
{
      unsigned char serialbuf[512];
      int fd, resume;
      struct termios oldtio, newtio;

      int n = 0;

      // Open serial port for communications
      fd = open(MODEMDEVICE, O_RDWR | O_NOCTTY);
      if (fd < 0)
      {
            perror(MODEMDEVICE);
            exit(-1);
      }
      else
      {
            printf("\nSerial Port Initializing...\n\n");
      }
   
      // Save existing port settings
      tcgetattr(fd, &oldtio);    
      bzero(&newtio, sizeof(newtio));
   
      /*
             CRTSCTS : flow control
             CS8     : 8N1
             CLOCAL  : local connection, no modem contol
             CREAD   : enable receiving characters
      */
      newtio.c_cflag = BAUDRATE | CS8 | CLOCAL | CREAD | CRTSCTS;

      newtio.c_iflag = IGNPAR;
      newtio.c_oflag = 0;
      newtio.c_lflag = 0;

      newtio.c_cc[VTIME]    = 0;  
      newtio.c_cc[VMIN]     = 1;    
   
      // Activate settings
      tcflush(fd, TCIFLUSH);
      tcsetattr(fd,TCSANOW,&newtio);
   
      // Begin Receiving serial data communication
      printf("\nReceiving on Serial Port...\n");
      while(1)
      {
            resume = read(fd,serialbuf,512);
            if (resume > 0)
            {  
              printf("Size: %d\n", resume);
              for (n=0; n<resume; n++)
                  printf("%c\n",serialbuf[n]);
            }
           
      }
      tcsetattr(fd, TCSANOW, &oldtio);
      return 0;
}






_______________________________________________
Soekris-tech mailing list
Soekris-tech@...
http://lists.soekris.com/mailman/listinfo/soekris-tech

[Bill Maas-2]

Hi Grice,

RTS/CTS is enabled by default, at least on a net5501 (I had trouble with
an oddly wired cable a while ago). The problem is that this is not
documented anywhere, except maybe fragmentarily on the Soekris Wiki.

Bill


On Tue, 2008-07-22 at 20:04 -0500, grice@... wrote:

> OpenBSD 4.3 installed smoothly, but Ive been wrestling with serial
> communication over COM2 for days now.  At the moment I have a simple C program
> designed to echo any data sent to the serial port to stdout.  Ive tested the
> program on other OpenBSD 4.3 PCs without issue, but when I move the code to
> the Soekris board, I see data being received, but its entirely corrupted.  At
> this point I have tried sending the data at multiple baud rates, both with and
> without CTS/RTS.  The results are always the same.  I receive data as its
> being sent, but its not the data I expect.
>
> The code for the echo program is listed below.  Must CTS/RTS be connected?  I
> noticed in another message thread, 19200 is the recommended baud rate for
> COM2.  Is this true?  If so, why?  Must I use 19200?  Any other
> recommendations?
>
> Strangely enough, I actually always receive data back from the COM2 connection
> as well, whether the echo program is running or not.  For example, sending the
> character t, I get back 0x0000.  If I send test, I receive
> 0x000246000000.  Again, this occurs whether or not the program is running
> (note that the program doesnt actually return anything via the serial port at
> all).   I suspect this is a configuration issue, but quite honestly Im a
> loss.  Any suggestions would be greatly welcomed.
>
> Have a great weekend - Greg
>
> Echo Program:
>
> #include <sys/types.h>
> #include <sys/stat.h>
> #include <fcntl.h>
> #include <termios.h>
> #include <stdio.h>
> #include <string.h>
> #include <stdlib.h>
> #include <unistd.h>
>        
> #define BAUDRATE B9600
> #define MODEMDEVICE "/dev/cua01"
> #define _POSIX_SOURCE 1 /* POSIX compliant source */ #define FALSE 0 #define
> TRUE 1
>
> int main(int argc, char **argv)
> {
>       unsigned char serialbuf[512];
>       int fd, resume;
>       struct termios oldtio, newtio;
>
>       int n = 0;
>
>       // Open serial port for communications
>       fd = open(MODEMDEVICE, O_RDWR | O_NOCTTY);
>       if (fd < 0)
>       {
>             perror(MODEMDEVICE);
>             exit(-1);
>       }
>       else
>       {
>             printf("\nSerial Port Initializing...\n\n");
>       }
>    
>       // Save existing port settings
>       tcgetattr(fd, &oldtio);    
>       bzero(&newtio, sizeof(newtio));
>    
>       /*
>              CRTSCTS : flow control
>              CS8     : 8N1
>              CLOCAL  : local connection, no modem contol
>              CREAD   : enable receiving characters
>       */
>       newtio.c_cflag = BAUDRATE | CS8 | CLOCAL | CREAD | CRTSCTS;
>
>       newtio.c_iflag = IGNPAR;
>       newtio.c_oflag = 0;
>       newtio.c_lflag = 0;
>
>       newtio.c_cc[VTIME]    = 0;  
>       newtio.c_cc[VMIN]     = 1;    
>    
>       // Activate settings
>       tcflush(fd, TCIFLUSH);
>       tcsetattr(fd,TCSANOW,&newtio);
>    
>       // Begin Receiving serial data communication
>       printf("\nReceiving on Serial Port...\n");
>       while(1)
>       {
>             resume = read(fd,serialbuf,512);
>             if (resume > 0)
>             {  
>               printf("Size: %d\n", resume);
>               for (n=0; n<resume; n++)
>                   printf("%c\n",serialbuf[n]);
>             }
>            
>       }
>       tcsetattr(fd, TCSANOW, &oldtio);
>       return 0;
> }
>
>
>
>
>
> _______________________________________________
> Soekris-tech mailing list
> Soekris-tech@...
> http://lists.soekris.com/mailman/listinfo/soekris-tech

--
"There is nothing to worry about" - unknown

_______________________________________________
Soekris-tech mailing list
Soekris-tech@...
http://lists.soekris.com/mailman/listinfo/soekris-tech

[Stuart Henderson]

On 2008-07-23, grice@... <grice@...> wrote:
> OpenBSD 4.3 installed smoothly, but I’ve been wrestling with serial
> communication over COM2 for days now.  At the moment I have a simple C program
> designed to echo any data sent to the serial port to stdout.  I’ve tested the
> program on other OpenBSD 4.3 PCs without issue, but when I move the code to
> the Soekris board, I see data being received, but it’s entirely corrupted.  At
> this point I have tried sending the data at multiple baud rates, both with and
> without CTS/RTS.  The results are always the same.  I receive data as it’s
> being sent, but it’s not the data I expect.

Your program is probably ok, but you could isolate it by using a known-
good program like cu.

# cu -l -s <speed> /dev/cua01

> The code for the echo program is listed below.  Must CTS/RTS be connected?

No, you aren't using modem control lines, so RXD/TXD/GND is enough.

> noticed in another message thread, 19200 is the recommended baud rate for
> COM2.  Is this true?  If so, why?  Must I use 19200?

No, you can use any speed supported by the port.

> Any other recommendations?

Check things are wired correctly. The pinout is given in the board's
manual, http://www.soekris.com/manuals/net4501_manual.pdf, also see
http://wiki.soekris.info/Serial_port. Some PCs use this layout, others
don't. If you use an IDC DE9 connector the ribbon cable should be
crimped on flat, not split and reorganised.


_______________________________________________
Soekris-tech mailing list
Soekris-tech@...
http://lists.soekris.com/mailman/listinfo/soekris-tech

[Stuart Henderson]

On 2008-07-23, Bill Maas <bill@...> wrote:
> RTS/CTS is enabled by default, at least on a net5501 (I had trouble with
> an oddly wired cable a while ago).

afaik, that would only affect the boot loader. for OpenBSD, use
a boot loader dated after 2008/04/20, it was rewritten to access
the hardware directly rather than via BIOS.


_______________________________________________
Soekris-tech mailing list
Soekris-tech@...
http://lists.soekris.com/mailman/listinfo/soekris-tech

Here are a few ideas:

We just went through something very similar, and finally determined that
the cable we were using was incorrect.  There are two different "PC"
standards for IDC10 <-> DB9 out there, and AFAIK there is no way to tell
from the cables we have.

My suggestion is to simply short pins 2-3 on the DB-9 and see if you get
characters echoed.  If you do not, then it is likely your cable is
wrong.  Try shorting TD and RD on the IDC10 header directly on the board
and try the same thing.  If that doesn't work, then it is clearly not
your cable.

Minicom has all sorts of settings for the RS-232 control lines, so you
might want to try that program if the above doesn't give you any joy.

It is also possible that you can a login daemon running on that port --
causes all kinds of strange errors if so.

The manual for the NT 4801 has the pinout for COM2, which AFAIK is the
same for the Net5501.

-bd

On Wed, 2008-07-23 at 10:04 +0000, Stuart Henderson wrote:

> On 2008-07-23, Bill Maas <bill@...> wrote:
> > RTS/CTS is enabled by default, at least on a net5501 (I had trouble with
> > an oddly wired cable a while ago).
>
> afaik, that would only affect the boot loader. for OpenBSD, use
> a boot loader dated after 2008/04/20, it was rewritten to access
> the hardware directly rather than via BIOS.
>
>
> _______________________________________________
> Soekris-tech mailing list
> Soekris-tech@...
> http://lists.soekris.com/mailman/listinfo/soekris-tech

_______________________________________________
Soekris-tech mailing list
Soekris-tech@...
http://lists.soekris.com/mailman/listinfo/soekris-tech

[Bill Maas-2]

On Wed, 2008-07-23 at 10:04 +0000, Stuart Henderson wrote:
> On 2008-07-23, Bill Maas <bill@...> wrote:
> > RTS/CTS is enabled by default, at least on a net5501 (I had trouble with
> > an oddly wired cable a while ago).
>
> afaik, that would only affect the boot loader. for OpenBSD, use
> a boot loader dated after 2008/04/20, it was rewritten to access
> the hardware directly rather than via BIOS.

It would also affect a program that wants to talk with the comBIOS, e.g.
for selecting a boot device with no direct interaction. The issue would
still be with the cable rather than with the software.

The cable that gave me trouble with the net5501 at boot always worked
with OpenBSD from the boot loader and onwards, even with older OpenBSD
versions. The boot loader and /bsd apparently turned off RTS/CTS. So the
comBIOS ssems to provide adequate support for UART configuration, it is
just not visible to the user, except for the baud rate. In my case a
"ConHandshakeDisable" option would have been useful, it would at least
have lead me immediately to the source of the trouble. Maybe something
for b5501_134.bin?

Bill


>
> _______________________________________________
> Soekris-tech mailing list
> Soekris-tech@...
> http://lists.soekris.com/mailman/listinfo/soekris-tech
>
--
"There is nothing to worry about" - unknown

_______________________________________________
Soekris-tech mailing list
Soekris-tech@...
http://lists.soekris.com/mailman/listinfo/soekris-tech

[grice]

> My suggestion is to simply short pins 2-3 on the DB-9 and see if you get
> characters echoed.  If you do not, then it is likely your cable is
> wrong.  Try shorting TD and RD on the IDC10 header directly on the board
> and try the same thing.  If that doesn't work, then it is clearly not
> your cable.
>

Great suggestions everyone!  We're definitely getting closer.  Indeed I am
certain the wiring is correct; that was one of the first things I checked.  
Instead, this is looking more like an OpenBSD configuration or hardware
issue.  For example, if I jumper TX and RX together on the IDC10 header as
suggested above and run a simple loopback program (listed below), I receive 0
bytes back on the read.

This program displays both 9600 for the old and new rates.

#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <termios.h>
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <errno.h>

#define BAUDRATE B9600
#define MODEMDEVICE "/dev/cua01"
#define _POSIX_SOURCE 1 /* POSIX compliant source */
#define FALSE 0
#define TRUE 1

int main(int argc, char **argv)
{
        unsigned char serialbuf[512];
        int fd, resume;
        struct termios oldtio, newtio;

        int n = 0;
        char m[20]="test\r\n";

        // Open serial port for communications
        fd = open(MODEMDEVICE, O_RDWR | O_NOCTTY | O_NDELAY);
        if (fd < 0)
        {
                perror(MODEMDEVICE);
                exit(-1);
        }
        else
        {
                printf("\nSerial Port Initializing...\n\n");
        }

        // Save existing port settings
        tcgetattr(fd, &oldtio);
        bzero(&newtio, sizeof(newtio));

        /*
         CRTSCTS : flow control
         CS8     : 8N1
         CLOCAL  : local connection, no modem contol
         CREAD   : enable receiving characters
        */
        newtio.c_cflag = BAUDRATE | CS8 | CLOCAL | CREAD | CRTSCTS;
        printf("\nOld Rate = %d\n", cfgetispeed(&oldtio));

        newtio.c_iflag = IGNPAR;
        newtio.c_oflag = 0;
        newtio.c_lflag = 0;

        // Activate settings
        tcflush(fd, TCIFLUSH);
        fcntl(fd, F_SETFL, 0);
        tcsetattr(fd,TCSANOW,&newtio);
        cfsetispeed(&newtio, B9600);
        cfsetospeed(&newtio, B9600);
        printf("New Rate = %d\n", cfgetispeed(&newtio));

        // Begin Receiving serial data communication
        printf("\nReceiving on Serial Port...\n");

        write(fd, m, strlen(m));
        usleep(5000000);
        fcntl(fd, F_SETFL, FNDELAY);
        resume = read(fd,serialbuf,512);
        if (resume >= 0)
        {
           printf("Size: %d\n", resume);
           for (n=0; n<resume; n++)
             printf("%c\n",serialbuf[n]);
        }
        else
        {
           printf("SERIAL read error %d %s\n", errno, strerror(errno));
        }


        tcsetattr(fd, TCSANOW, &oldtio);
        return 0;
}


The x's below denotes the two pins jumpered on JP11, where the JP11 label is
directly adjacent to pin 1 on the IDC10.
JP11
+------+
| .  . |
| x  . |
| x  . |
| .  . |
| .  . |
+------+


And just for completion to show that the com ports are believed to be set
correctly...

/etc/boot.conf:
stty com0 9600
set tty com0

I'm not entirely certain of how OpenBSD differentiates the tty and cua devices
so I'll also include /etc/ttys.

/etc/ttys:
# name  getty                           type    status          comments
#
console "/usr/libexec/getty std.9600"   vt220   on  secure
ttyC0   "/usr/libexec/getty std.9600"   vt220   on  secure
ttyC1   "/usr/libexec/getty std.9600"   vt220   on  secure
ttyC2   "/usr/libexec/getty std.9600"   vt220   on  secure
ttyC3   "/usr/libexec/getty std.9600"   vt220   on  secure
ttyC4   "/usr/libexec/getty std.9600"   vt220   off secure
ttyC5   "/usr/libexec/getty std.9600"   vt220   off secure
ttyC6   "/usr/libexec/getty std.9600"   vt220   off secure
ttyC7   "/usr/libexec/getty std.9600"   vt220   off secure
ttyC8   "/usr/libexec/getty std.9600"   vt220   off secure
ttyC9   "/usr/libexec/getty std.9600"   vt220   off secure
ttyCa   "/usr/libexec/getty std.9600"   vt220   off secure
ttyCb   "/usr/libexec/getty std.9600"   vt220   off secure
tty00   "/usr/libexec/getty std.9600"   vt220   on  secure
tty01   "/usr/libexec/getty std.9600"   unknown off
tty02   "/usr/libexec/getty std.9600"   unknown off
tty03   "/usr/libexec/getty std.9600"   unknown off
tty04   "/usr/libexec/getty std.9600"   unknown off
tty05   "/usr/libexec/getty std.9600"   unknown off
tty06   "/usr/libexec/getty std.9600"   unknown off
tty07   "/usr/libexec/getty std.9600"   unknown off
...

Thanks again,

Greg



_______________________________________________
Soekris-tech mailing list
Soekris-tech@...
http://lists.soekris.com/mailman/listinfo/soekris-tech

[Stuart Henderson]

On 2008-07-23, grice@... <grice@...> wrote:
> Great suggestions everyone!  We're definitely getting closer.  Indeed I am
> certain the wiring is correct; that was one of the first things I checked.  
> Instead, this is looking more like an OpenBSD configuration or hardware
> issue.  For example, if I jumper TX and RX together on the IDC10 header as
> suggested above and run a simple loopback program (listed below), I receive 0
> bytes back on the read.

Please try a known working program until you are sure the hardware
is ok. With txd looped to rxd, when you "cu -l /dev/cua01" and type
something, it should be immediately displayed back.

> This program displays both 9600 for the old and new rates.

If I try that here, it leaves the port in a state where if I try and
use cu afterwards, it will receive but not transmit.

> I'm not entirely certain of how OpenBSD differentiates the tty and cua devices

See tty(4) ("man 4 tty").


_______________________________________________
Soekris-tech mailing list
Soekris-tech@...
http://lists.soekris.com/mailman/listinfo/soekris-tech

[grice]

> Please try a known working program until you are sure the hardware
> is ok. With txd looped to rxd, when you "cu -l /dev/cua01" and type
> something, it should be immediately displayed back.

Good point.  I should have mentioned that before as well.  Performing the
above produces similar results as the code.  Regretably, I see nothing
returned on cua01 on a call up despite a successful connection.

I've also tried wiring a full RS232 loopback by jumpering RTS/CTS and
DCD/DSR/DTR as well.  Same result.

Greg


_______________________________________________
Soekris-tech mailing list
Soekris-tech@...
http://lists.soekris.com/mailman/listinfo/soekris-tech