Repeat After Me

I came across a really obscure UART failure mechanism. I'm not going to call it a bug, but it frequently causes problems. And while everyone else may know about it, I sure was unaware of it.

The basic UART architecture works well, and allows for mismatches in the baud rate of up to about 5%. But there is a case where it doesn't work.

Consider a slave system that receives, and then re-transmits the same data as a confirmation that the data is correct. Also consider the case where the master is running an incrementally faster baud rate than the receiver. After all, this is a Universal Asynchronous Receiver Transmitter. Because data is coming in faster than it is going out, eventually the transmit buffer will overflow, and a character will be lost. Downloading a 512 byte program requires that the external transmitter be within 0.2% of the slave receiver, or data will be lost.

Statistically, half of the external systems will be running slightly faster than the slave system, and so this happens frequently. We have researched this condition, and found that the problem is frequently mentioned, but the real cause is just as frequently misunderstood.

One common solution is to buffer the transmitter. Think 16550. This does not fix the problem, but may delay it from happening until the packet is over.

Another solution from the slave side is to shave time off of the transmit stop bit. This can work, but may cause other system communication problems.

The only correct solution is on the master side. There, additional stop bits (1.5 or 2) can be used to effectively slow the source data rate to slightly below the slave transmit rate. Alternately, the master can pause every N bytes. Or, the master can deliberately choose a transmit baud rate that is known to be slower than the slave system. Any of these solutions will allow for the continuous transmission and reception of data.

I have known about the ability to insert extra stop bits, but I never knew why someone would do it. Now I finally know why.

--------

We found this case while working on a reported bug on one of our new 68HC11 microprocessors. The initial report is that our chip failed to download a program while the original Freescale part worked. We were able to easily duplicate the problem, and from there were able to trace it down to the transmit buffer overflow condition.

What we didn't understand was why we had a problem and the original Freescale part didn't. We went to the bench, determined to discover whether Freescale was shaving stop bits. We discovered that they weren't. We also discovered that the Freescale part failed just like our part did.

So why the report that the Freescale part worked? We don't know. I suspect that their oscillator may be running a bit faster than ours, and thereby reducing the probability of failure. Since Freescale fails just like we do, this isn't really a bug, and so there is nothing to be fixed. But it sure was an education for me. And I thought I understood UARTs.

Date

2011-11-27