0
votes

I have a C++ program on a Raspberry Pi Model B that receives data from a remote sensor via an Xbee and then writes a message back via the Xbee. When I connect the Xbee via a Sparkfun XBee Explorer USB, it works perfectly every time. But if I run the exact same code using the RPi serial port, the incoming message is always received, but the output message is written from the serial port to the Xbee a few times after reboot and then never again. I know there's no output from the serial port to the Xbee because I have a logic probe connected to the GND, TXD and RXD pins and I can see the incomming and outgoing packets. Also, the RPi program writes debug messages for incoming and outgoing packets and both happen when they should. I'm connecting just the 3.3V, GND, TXD, and RXD pins on the RPi GPIO to the corresponding Xbee pins. RPi is running the 2013-09-10-wheezy-raspbian release. Baud rate is 38400.

This is the serial port initialization:

fcntl(fd, F_SETFL, 0);      // Clear the file status flags
struct termios options;
tcgetattr(fd, &options);    // Get the current options for the port
options.c_iflag &= ~(IGNBRK | BRKINT | ICRNL | INLCR | PARMRK | INPCK | ISTRIP | IXON);
options.c_oflag &= ~(OCRNL | ONLCR | ONLRET | ONOCR |  OFILL | OLCUC | OPOST);
options.c_lflag &= ~(ECHO | ECHONL | ICANON | IEXTEN | ISIG);
options.c_cflag |= (CLOCAL | CREAD);
options.c_cflag &= ~PARENB;
options.c_cflag &= ~CSTOPB;
options.c_cflag &= ~CSIZE;
options.c_cflag |= CS8;
if (cfsetispeed(&options, B38400) < 0 || cfsetospeed(&options, baudRate) < 0) {
  throw runtime_error("Unable to set baud rate");
}
if (tcsetattr(fd, TCSAFLUSH, &options) < 0) {
  throw runtime_error("Could not set tty options");
}
FD_ZERO(&set);    // clear the set
FD_SET(fd, &set); // add file descriptor to the set
sleep(1);

In looking closely at the logic analyzer, I can see what's happening. The RPi TxD line (GPIO pin 8) suddenly goes low and stays low. Then no further output is possible without a reboot. The RxD line continues to work perfectly. I have two RPis and this happens on both of them, anywhere between a minute and half an hour. Can anybody please give me a clue as to why this might happen and, more importantly, what I can do about it? I'm desperate. This is driving me crazy after way too many days of testing everything I can think of.

1

1 Answers

0
votes

Problem solved! It's not the problem I thought it was, and of course it's my own fault. First off, I was looking in the wrong place. There was nothing wrong with the C++ code. My project is built using Ruby on Rails and I use the Wiring Pi (http://wiringpi.com) GPIO Interface library for the Raspberry Pi to control external relays. When I coded the pins to initially turn off, I accidentally (stupidly) used the header pin I wanted (15) as the Wiring Pi pin number. Wiring Pi pin 15 is actually GPIO pin 8, and GPIO pin 8 is the UART transmit (TxD) pin. So the result was that the Raspberry Pi did exactly what I told it to do: force TxD to LOW. Apparently once you do that, it doesn't matter what you tell the serial driver to do, the pin will stay low.

So many hours of work to find such a dumb mistake. Thanks to all those who took the time to look at my question.