UART frame error

[niv]

Anyone know the philosophy behind frame error on uarts?

I've designed a uart which works fine, but to fully test it, the test bench
sends a frame with a wrong stop bit (i.e. set to 0, to force a frame error).

when this happens the uart receiver gets a bit screwed up at the moment.
This is because after the middle of the stop bit detection (be it good or
bad) the rx starts looking for a new start bit.
Since a bad stop was sent, this is seen straightaway as the new start bit,
so everything gets out of step.

What is the correct methodology for dealing with incorrect stop bit(s)?

One option is to abort reception until a '1' is detected on the line, and
then start again searching for start bit.

Anyone got any good ideas or point me at the relevant web page.

TIA Niv.

[Ray Andraka]

You usually sample at some multiple of the bit clock. From the start bit
detection, you wait a half of a bit time then sample at 1 bit intervals. After
you sample the stop bit (at the center of the bit) you should wait a half bit
time before enabling the start bit detect again. That said, even then you may
get a false start due to unknown timing relationship between your local timing
and the sender.

niv wrote:

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email r...@andraka.com
http://www.andraka.com

"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759

[niv]

I know all about the 16x clock etc., the problem is that you MUST start to
look for a new start bit after the middle of the last stop bit to ensure the
+ or - 4% tolerance on the baud rate.

(I believe this comes from 16x 12 bits [strt,8data,parity 2 stop;as worst
case], which is 192 clk cycles, so half bit period or 8 clks in 192 gives
4%)

Niv.

Ray Andraka <r...@andraka.com> wrote in message
news:3C505FB5...@andraka.com...

[Allan Herriman]

On Thu, 24 Jan 2002 20:30:16 -0000, "niv" <n...@ntlworld.com> wrote:

>I know all about the 16x clock etc., the problem is that you MUST start to
>look for a new start bit after the middle of the last stop bit to ensure the
>+ or - 4% tolerance on the baud rate.
>
>(I believe this comes from 16x 12 bits [strt,8data,parity 2 stop;as worst
>case], which is 192 clk cycles, so half bit period or 8 clks in 192 gives
>4%)

Yeah, some of the early 8051 variants had this bug. They would wait
until the end of the stop bit before looking for a start bit.
If the tx device had a clock that was a few ppm faster than the rx
clock, it would evenually cause errors if the tx was sending
characters continuously.

(The fix for that particular product was to get the tx to send two
stop bits.)

Philips eventually fixed the uart, and it now starts looking for a
start bit from the middle of the stop bit.

Regards,
Allan.

[Eric Smith]

"niv" <n...@ntlworld.com> writes:
> I know all about the 16x clock etc., the problem is that you MUST start to
> look for a new start bit after the middle of the last stop bit to ensure the
> + or - 4% tolerance on the baud rate.

It's not just for baud rate tolerance. A modem that is receiving a signal
that is slightly overspeed will shave a fraction off the stop bit to allow
it to keep up, if you are using a synchronous modulation (basically anything
from 1200 bps up) and you are not using error control (MNP or V.42). This
was specified in some CCITT (now ITU-T) standard, but I don't recall which
one.

This caused problems with the NEC 7210 SCC, which was found in the
AT&T 7300 and 3B1 "UnixPC" computers. It required one full stop bit, and
would fail if it got the occasional 15/16 stop bit.

[Allan Herriman]

On 24 Jan 2002 20:53:47 -0800, Eric Smith
<eric-no-s...@brouhaha.com> wrote:

Sounds like ITU-T V.14. There's also one in V.22 (as part of a modem
standard) IIRC.

ITU-T also have asynchronous to synchronous mappings in V.110 and
V.120 (as part of ISDN), but they work a bit differently.

Regards,
Allan.

[Niv]

I think I've found what a uart should do (hopefully).

If a stop error occurs on the first stop bit, flag this as a frame error.
An error on second stop bit (only) is not catered for. (I assume it is seen
as a start bit, so following byte will be in error).

If stop error on first, and possibly only, stop bit, and all data bits are
also '0', then assume a line break, and stay here until a '1' is detected on
the line again.

If anyone knows differently, please speak now; I'm about to recode my custom
uart RX.

Niv.

[Allan Herriman]

What you have described sounds like standard UART operation.

I assume that when you say:

>An error on second stop bit (only) is not catered for.

you mean that you don't check the second stop bit.
Most UARTs (well, all UARTs that I've used) only ever check one stop
bit on receive. The "two stop bit" setting only affects the
transmitter.

I think some break detectors require multiple characters to have all
zero data bits and framing errors to detect break. I'm not sure what
the ideal number is though. (A single character sounds like it would
be too sensitive to noise.)

Regards,
Allan.