Take the 2-minute tour ×

I have been working on creating a UART on an FPGA. I can successfully transmit and receive single characters typed on PuTTY. However, when I set my FPGA to constantly write a large sequences of "A", sometimes I end up with a sequences of "@" or some other characters until I reset the FPGA a few times.

I believe the UART on the computer looses track of the difference between the start bit and a zero. The delay between the two "A" is ~ 30us (measured with a logic analyzer) and the baud rate is 115200 8N1.

Is there a minimum delay that must be maintained between two consecutive RS232 frames?

share|improve this question
Fairly easy to get out of sync on long data transmissions if using only one stop bit. Gets worse when transmitting binary data that tends to be all zeros at times (or all ones). –  Daniel R Hicks Dec 7 '12 at 1:13
But you say that you have to "reset the FPGA a few times" to clear the error. If the problem was at the receiving end it would only be necessary to pause transmission (between characters) for one character's time to achieve reset. This makes one wonder if your FPGA is somehow getting out of sync internally. –  Daniel R Hicks Dec 7 '12 at 1:22
@sawdust -- The point is that the transition between stop bit and start bit is the only reliable point of reference in the data stream, and the protocol is asynchronous, meaning that you can't rely on the timing of previous bits. A single noise glitch and the protocol's "locked on" to the wrong reference point. –  Daniel R Hicks Dec 7 '12 at 1:28
@DanielRHicks - OK, you're right. I do recall once or twice hot-plugging a serial connection, and the receiver synch'd to the wrong bit of the frame. It would not correct until there was a pause in the transmission. –  sawdust Dec 7 '12 at 3:30
Okay, I had a free running baud rate generator. May be I should try to reset the counter in the generator on detecting a start bit. But this is not my problem - the computer is going out of sync, not the receiving FPGA (not stress tested yet). –  Lord Loh. Dec 7 '12 at 5:56
add comment

3 Answers

up vote 2 down vote accepted

As well as speed and number of data bits, I think the two ends must agree on the number of start bits, stop bits and parity bits.

See Asynchronous Serial Communication

RS232 signal

The above shows how characters are separated but has rather idealised rise and fall times, I believe a scope would show something more like what follows (note inverted mark/space axis compared with prior diagram).

enter image description here

Perhaps you should set the speed lower, maybe your FPGA isn't emitting a well-formed signal at higher speeds.

Also RS232 is async, I believe that means the receiver is expected to synchronise it's timing based on the start and stop bits.

  • A is binary 01000001
  • @ is binary 01000000

The difference is a matter of accurate timing. With inaccurate timing a receiver can count six instead of five whilst the +3...15V is asserted.

See Signal Timing and Signal Characteristics

share|improve this answer
This makes it look easy to get out of sync if I have one start and one stop bit. Practically, my stop bit is a little bit longer as the serializer it loads the next byte in. I used a logic analyzer. I do not have an oscilloscope :-( But the FPGA and the board are designed to operate up to 400 MHz (digilentinc.com/Products/…) –  Lord Loh. Dec 6 '12 at 17:29
I'd try running at 9600 N81. If OK double speed & retry. rinse repeat. You do the byte loading during the "idle" state? At low speeds a cheap and nasty scope may be useful. –  RedGrittyBrick Dec 6 '12 at 17:32
This is my first revision of the UART. I have not yet implemented a FIFO or anything fancy. Just a Serializer and Deserializer. –  Lord Loh. Dec 6 '12 at 17:57
It just occurred to me that I get the same problem whether I use the IO pins to connect to a USB TTL UART module (ebay.com/itm/…) or the onboard USB UART. Can I eliminate signal jitters? –  Lord Loh. Dec 6 '12 at 18:22
Actually, the two ends really only need to agree on data rate and number of data + parity bits. There's only ever one start bit, and modern UARTs should be able to handle one stop bit. More than one stop bit just looks like "dead air" between characters. –  Daniel R Hicks Dec 7 '12 at 1:15
show 6 more comments


No, there is no such requirement (no min and no max) in EIA/RS232C.
The Start bit of the next character can immediately follow the Stop bit of a character.
Note that the line idles at the Marking state, which is the same level as the Stop bit.

It is interesting that you make no mention of the Stop bit in the character frame.


You are using the wrong tool for this task! You should be using a 'scope. You cannot analyse a timing problem by viewing a sampled and sanitized rendition of the analog signal.
The difference between the Start bit and a zero is timing. The character frames are transmitted at an asynchronous rate. But the bits of the frame have to be clocked at the specified clock rate.
For 115200 baud rate, that would be 8.68usec for 1 bit time. For 8 data bits plus a Start bit and a Stop bit, the frame time is 86.8usec.
You question implies that you have not bothered to look at the EIA/RS232C spec for minimum rise/fall times and when the signal is typically sampled. Interesting method for implementing HW.

Perhaps you should also use a frequency counter to measure the baud rate generator at each end. A mismatch of a few percent can usually be tolerated. A mismatch could produce the symptoms you see.
How come framing errors are not reported by the receiver? Instead of just looking at output, maybe you need to review the stats of the serial port, i.e. /proc/tty/driver/...

share|improve this answer
Using an FPGA, I have little control of the raise time or the fall time. Also, I am not attempting to implement the EIA/RS232C specification. What I can reasonably do an an FPGA is a serdes. Example code provided by the vendor works just fine - so I rule out analog trouble. Although example codes do not dump single characters as fast as the hardware possibly could. –  Lord Loh. Dec 7 '12 at 6:02
add comment

I suspect that UARTs are still pretty much similar to the original ones. They used a 16xdata rate clock to "sample" the data, vs the earlier analog scheme that used an oscillator that was edge-triggered. Using the sample approach the UART could fairly accurately position it's sample time in the middle of the pulses, and could even do multiple samples to be a little more noise tolerant.

Your description is unclear in that you talk in a recent comment about "detecting a start bit", but you had implied earlier that you're TRANSMITTING and hence would have nothing to "detect".

share|improve this answer
That is true. I am having trouble with the transmission. But that does not mean my receiver is perfect. I am sure there are problems that I have not detected. I did not know of the 16x receiver clock. I had thought of something similar, but did not implement it as it would take a lot more hardware. I might try 4x. –  Lord Loh. Dec 8 '12 at 8:43
Without the 16x scheme you've got the problem of building a triggerable oscillator that can be triggered by the start bit and then mark out time reasonably accurately. This is an "analog" circuits problem, and, as we all know, analog solutions are much fussier and less precise than digital solutions. –  Daniel R Hicks Dec 9 '12 at 1:37
add comment

Your Answer


