Much Help needed with 8251 USART Problem.......

[homemadecpu1986]

Hi friends.

I have been trying to debug an 8251 UART for 5 days now. In fact 3 of them and they all error the same way. I got 1 from a different source, and the last 2 from a single source.

The problem is when receiving characters from my PC, into a simple system with a CPU + UART.

Most characters are received correctly, but 1 out of 10 or so chars are junk.

I have set up the USART for asynchronous communications, 8 data bits, 1 stop bit, no parity.

I configure Putty for the exact same setting.

I have even tried to test the USART on a breadboard, and do it manually. I still get the same issue.

I am initializing the USART correctly I think, the mode byte is 0x4D, and command is 0x37. This is exactly for 8 data bits, 1 stop, no parity, etc.


I am out of ideas, and this is driving me nuts. The issue was happening with my first 8251, so after a while I assumed it was damaged. Bought another 2. Same issue.

Same issue whether when USART used with CPU, or breadboard.

The only thing I can think of is that I am initializing it incorrectly, but that would be unlikely. I have tried many many times.


If someone has any ideas please let me know. I am getting desperate now.

Thank you and best wishes

Paul

[ebastler]

Hi Paul,
You have not talked about the hardware side of things at all. Is this a homebrew computer & UART? Could you share the schematic please, especially showing all connections to the 8251?  (And if it is a homemade/hand-wired design, have you checked that you have indeed made all connections? An open handshake input, for example, could mess things up quite a bit.)

[homemadecpu1986]

Hi there. I don't have schematics for the 8251 circuit. Yes it is a homebrew CPU. I can guarantee to you all connections are correct. 100%.

If you look at 8251 datasheet it's all very simple. WR/RD pins. Data bus, chip select and control bit. Nothing major.

But the UART fails even at the breadboard alone....

I have tried debugging this in many many ways. Still the problem persists.

is it likely all 3 UARTS are broken ?

[Fraser]

Where UARTs are concerned always make sure the master clock reference is meeting the required specs for amplitude, frequency and noise content. A marginal clock can cause mayhem in serial communications as the link can fail intermittently without any obvious reason.

Fraser

[ebastler]

is it likely all 3 UARTS are broken ?

You already know the answer to that one, right? Why would they all be broken in the same, subtle way? No, the much more likely reason is that you are not using them quite right.

[EDIT: In view of oPossum's post below, I guess one could argue that they are indeed all "broken", by design... Or that you not using them quite right, but that the chip designers have made it pretty hard to find out what "right" means...  ]

We don't know you level of experience and don't know what you have built. You firmly believe that you have done it right and might hence be blind to some (obvious or subtle) problem in your setup. So the only way forward is for you to share more information. If you have built this yourself and don't have a schematic, maybe you should draw one -- it helps in double-checking that you did not overlook anything.

Also, looking at the more "analog" aspects of the design: Have you measured your supply voltages, ideally also with an oscilloscope to look for unwanted spikes or glitches? Do you have decoupling capacitors (100 nF, leads as short as possible) across Vcc and GND for every chip? Could you share photos of your board(s) and wiring?

Edit: Yes, and Frazer's point too! Please check the clock quality too. (Where does the clock signal come from?)

Cheers, Jürgen

[oPossum]

I am initializing the USART correctly I think, the mode byte is 0x4D

1X baud rate factor does not work reliably for async mode. 16X or 64X will work.

This is not well documented in the datasheet, but it is 'common knowledge' that a 4X or higher clock is typically needed for reliable async receive.

[ebastler]

1X baud rate factor does not work reliably for async mode. 16X or 64X will work.
This is not well documented in the datasheet, but it is 'common knowledge' that a 4X or higher clock is typically needed for reliable async receive.

Ouch... Great point; that sounds like a very plausible cause indeed. The datasheet for the newer a8251 (https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/ds/ds8251.pdf) mentions this in a very subtle way:

Divide-by-1 mode. Clock and data rates are identical. External logic is responsible for synchronizing the rxd signal to the nrxc signal.

That's a nice way to state "doesn't really work"... 

[homemadecpu1986]

I am initializing the USART correctly I think, the mode byte is 0x4D

1X baud rate factor does not work reliably for async mode. 16X or 64X will work.

This is not well documented in the datasheet, but it is 'common knowledge' that a 4X or higher clock is typically needed for reliable async receive.

This is absolutely mind blowing. I can't believe this !!! I will test it right now!! I really hope this is it. Seems like it !! I will get back here in a few minutes!!!

[oPossum]

Also make sure the CLK is at least 4.5X the TxC/RxC. This is a footnote in the datasheet. It will be unreliable if this ratio is not met or exceeded.

It is possible to run the 8251 well beyond it's specs if you make sure the clock ratios/dividers are correct. I have run it with 12 MHz CLK and 1.5 MHz TxC/RxC for a bit rate of 93,750 bps.

https://www.eevblog.com/forum/microcontrollers/lt30-cent-mcu-with-usb-controllers-capactive-touch-more-wchs-ch55x-series/msg2894590/#msg2894590

[Benta]

Most UART/USARTs sample the incoming bit stream at 16x baud rate and decide on high/low through a "majority decision". 15 high samples is OK for a high, same for an accepted low. I don't know the 8251, but suspect it operates the same way.

[oPossum]

Ouch... Great point; that sounds like a very plausible cause indeed. The datasheet for the newer a8251 (https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/ds/ds8251.pdf) mentions this in a very subtle way:

Divide-by-1 mode. Clock and data rates are identical. External logic is responsible for synchronizing the rxd signal to the nrxc signal.

That's a nice way to state "doesn't really work"... 

The 1985 and 1993 data sheets both say...

In asynchronous mode the baud rate is a fraction of the RxC frequency.

So the info is there, but not as clear as is could be.

The description of reset polarity is quite confusing.

[homemadecpu1986]

I am initializing the USART correctly I think, the mode byte is 0x4D

1X baud rate factor does not work reliably for async mode. 16X or 64X will work.

This is not well documented in the datasheet, but it is 'common knowledge' that a 4X or higher clock is typically needed for reliable async receive.

You are a hero !!!! This was exactly the problem. I tried it now and it works solidly and without any issues. I can't believe this. Really can't. I have been trying to trace this problem down for days now without success. I assumed I was somehow initializing the UART wrong. But I doubled checked and couldn't find anything wrong. Oh boy. I am so happy and relieved now. You lifted a weight from my shoulders. I have made a 16bit cpu/minicomputer from 74HC logic, and I am installing some peripherals to it, one of them is this UART. It would send characters no problem, but when receiving.... it had been a nightmare.

When did you first hear about this? What bad luck on me to use the UART straight at 1x!! I thought about testing at 16x or 64x but somehow didn't. It would still perplex me why it would work at higher x.

I just want to thank you very much for your kind help. You wouldn't believe how happy I am !!

[homemadecpu1986]

That is an interesting fact. Agrees with some of the logic I was trying to use to find this bug. I found it strange that the baud clock would be exactly the same as the baud given the 8251 cannot divide it into smaller chunks by just any divisor. So if it divides say by 16, then it has 16 steps to decide whether it is valid.

That is great information you have given. Thank you for that!

[Ian.M]

The reason for this is inherent in the design of any UART with an external clock.   For asynchronous serial data with normal 'RS232 style' byte framing, the start bit is the same width as the data bits.  The UART can only act on its detection of the start bit at a clock edge, so if the clock frequency is the same as the baud rate, assuming 50% duty cycle clock, there is inevitably half a bit time uncertainty.  The UART needs to sample the data bits in the middle of each bit time, so it should ideally delay 1.5 bit times from the leading edge of the startt bit before sampling D0.  Unfortunately that half bit time uncertainty + propagation delays can push the sampling point into the transition to the next bit.   Therefore you can see that its impossible to design an externally clocked UART using internally synchronous logic that works reliably with less than three active clock edges per bit.   Binary divisors are vastly preferable in logic design and its easier to only sample on a single clock edge, so typically UARTs require a minimum clock of 4x the baud rate, or higher if they oversample each bit.

[homemadecpu1986]

The reason for this is inherent in the design of any UART with an external clock.   For asynchronous serial data with normal 'RS232 style' byte framing, the start bit is the same width as the data bits.  The UART can only act on its detection of the start bit at a clock edge, so if the clock frequency is the same as the baud rate, assuming 50% duty cycle clock, there is inevitably half a bit time uncertainty.  The UART needs to sample the data bits in the middle of each bit time, so it should ideally delay 1.5 bit times from the leading edge of the startt bit before sampling D0.  Unfortunately that half bit time uncertainty + propagation delays can push the sampling point into the transition to the next bit.   Therefore you can see that its impossible to design an externally clocked UART using internally synchronous logic that works reliably with less than three active clock edges per bit.   Binary divisors are vastly preferable in logic design and its easier to only sample on a single clock edge, so typically UARTs require a minimum clock of 4x the baud rate, or higher if they oversample each bit.

That makes a lot of sense indeed. When I started using this UART I had never used one before, and after thinking about the baud rate clock I started to think I was somehow misunderstanding baud because to me it didn't make sense the baud clock should be the same frequency as the data rate clock. So what you are makes complete sense to me and is nice to know. 

Must have caused a lot of headache for many beginners!!

Best wishes