Question

I’m trying to set up a serial communication between the RPI and an FPGA. However, there is an issue when using the standard C library open() to init the serial interface: I’m using a scope to monitor what is sent and received via the RX and TX lines. A call to open causes the TX line of the RPI to go low for the length of one bit. I do not see this behavior with other computers/linux PCs. The point is, the FPGA assumes a valid transmission, since he thinks it’s a start bit, but it’s not.

I checked with minicom installed on the RPI. Same thing. Starting minicom causes the TX line sending one bit. Once minicom has started, the communication runs as expected and all bytes have the correct frame size. Is there any way to suppress the TX line going low upon the open call to init the serial communication? Is this an expected behavior?

Answer 1

This is a super far-fetched hunch, but this code seems a bit suspicious, from the pl011_startup() function in the PL011 serial port driver:

/*
 * Provoke TX FIFO interrupt into asserting.
 */

It seems as if it’s twiddling the TX line when starting up the port, which would explain the pulse you’re seeing. More investigation would surely be needed before concluding this is what happens, of course.

So, I guess my “answer” boils down to: that sounds weird, perhaps it’s something with the driver?

Of course, one way of working around this is to apply some care in the FPGA end, assuming you have more control over it. “Proper” framing would take care of this, and make it clear that the spurious send can be discarded.

UPDATE: I meant that if “proper” messages were to be always framed by some sequence of bytes, the FPGA might be able to discard invalid (“unframed”) data anyway, and thus become immune to the random pulse. For instance, messages could be defined to always start with SOH (start of header) or SOT (start of text) symbols (bytes with the values 0x01 and 0x02, respectively).