COM port loopback test & settings

[David (PassMark)]

Here is an extract from,
http://www.linux.com/howtos/Serial-H...9.shtml#ss19.3

-=-=-=-=-
To understand the differences between dumb and FIFO (First In, First Out queue discipline) first let's examine what happens when a UART has sent or received a byte. The UART itself can't do anything with the data passing thru it, it just receives and sends it. For the obsolete dumb UARTS, the CPU gets an interrupt from the serial device every time a byte has been sent or received. The CPU then moves the received byte out of the UART's buffer and into memory somewhere, or gives the UART another byte to send. The obsolete 8250 and 16450 UARTs only have a 1 byte buffer. That means, that every time 1 byte is sent or received, the CPU is interrupted. At low transfer rates, this is OK. But, at high transfer rates, the CPU gets so busy dealing with the UART, that is doesn't have time to adequately tend to other tasks. In some cases, the CPU does not get around to servicing the interrupt in time, and the byte is overwritten, because they are coming in so fast. This is called an "overrun" or "overflow".

FIFO UARTs help solve this problem. The 16550A (or 16550) FIFO chip comes with 16 byte FIFO buffers. This means that it can receive up to 14 bytes (or send 16 bytes) before it has to interrupt the CPU. Not only can it wait for more bytes, but the CPU then can transfer all (14 to 16) bytes at a time. This is a significant advantage over the obsolete UARTs, which only had 1 byte buffers. The CPU receives less interrupts, and is free to do other things. Data is rarely lost. Note that the interrupt threshold of FIFO buffers (trigger level) may be set at less than 14. 1, 4 and 8 are other possible choices. As of late 2000 there was no way the Linux user could set these directly (setserial can't do it). While many PC's only have a 16550 with 16-byte buffers, better UARTS have even larger buffers.
-=-=-=-=-

However I would be fairly sure you could make the change by doing small mod and a quick recompile in your Kernel.

------
David

[james_tec]

Hi Ian,

Thanks for the feedback!
I am having a difficulty figuring out the Linux UART FIFO settings as I'm not really familiar with any UNIX-like OS. Can you possibly advice me on how to retrieve these information?
Cheers.

Regards,
James

[Ian (PassMark)]

David_H

1. Random numbers are used. V5.0 of BurnInTest displays samples of the data in level 2 trace files (preferences -> logging), as well as the data in the event of an error. However, I think it is more likely to be an interrupt servicing timing issue (ie. buffer overrun) due to a high setting on the UART FIFO.

2. BurnInTest does use the Windows Serial port drivers via the Windows API. BurnInTest sets the baud rate for its serial port usage to that specified by the user in Preferences -> Serial Ports.

3. BurnInTest V5.0 will provide a better indication of what the problem is, as we display the Error from the Line Status Register of the UART (such as buffer overruns). The typical reason for COM port errors is the use of the UART's FIFO with the Windows settings at higher values. I suspect this is your problem. Please try BurnInTest 5.0 (even just the evaluation version).


James_tec,

Continuing on with this point in regards to your Linux question:
To answer the Linux question properly I need to know the what the Linux UART FIFO settings are. As to why Linux reports differently to Windows for the same hardware, I would have to first suspect that Windows and Linux UART FIFO default settings are different. For example, as I understand it, some older versions of Linux did not allow the use of the UART FIFO in any easy to configure way (but by default simply used a single byte buffer, with an interrupt after each byte). Alternatively, the Linux settings may simply set the Interrupt to occur after the buffer is filled at a different point. For example the Linux test system may have (by default) the UART FIFO interrupt set to occur when the FIFO has 4 bytes, whereas using the slider in Windows you can change this (e.g. between 1 and 16). And if the interrupt is set to occur after 16 bytes and it is a 16 byte FIFO, then if another byte is received before the interrupt is serviced, you will lose the data, ie. a buffer overrun error.


In regards to your question re: Duty Cycle, we do not alter the UART clock signal - only add delay between each cycle. If you increase the duty cycle to 100%, then we insert no delay, and I would expect that you would see more buffer overrun errors when the UART FIFO setting is high.

Best regards,
Ian

[james_tec]

Hi Ian,

Thanks for your prompt response & help on these queries.

Just to further clarify on the test duty cycle in Burnintest, does it relate to the duty cycle of the UART clock signal? I can see that my UART clock signal is having a 50% duty cycle so I'm wondering if the test duty cycle if set to 100% will affect the COM port stability.

Please advice. Thank you.

Regards,
James

[David_H]

I am having a similar issue as reported by james_tec (same configuration for burnintest), so expanding on the questions and answers already provided I have some further inquiries

1. Is there a specific a pattern Burnintest uses for its loop back testing? Is there a way to get this pattern from BurninTest after an error has occurred so we can possibly debug where the error has occurred in the pattern? (Maybe a certain pattern or sequence is continually failing) When the duty cycle is changed does the pattern change? (Or is it just adding delay)

2. I have also played with the Windows Baud rate setting and I am curious as well how this affects Burnintest. Does burnint test override this setting? Does Burnintest use the windows Serial port drivers to operate?


4. I am also interested in this question since I have observed the same behavior. (No failure in Linux, failures only observed in Windows)

Thanks for your support

David

[Ian (PassMark)]

I have prepared an initial response. In summary, I suspect you are getting buffer overrun errors and would use BurnInTest V5.0 to check this:
http://www.passmark.com/download/bit_download.htm

Specific answers are:

1. It adds a delay between each Cycle. The delay is at least:

(100 * test_duration / duty_cycle) - test_duration milliseconds

It does not add delay between each write/ read.

2. We will investigate further tomorrow and respond after this. You might find if you drop the BurnInTest data rate to 9600 the errors will also not appear.

3. These Windows settings determine how often the COM port servicing interrupts occurs. Please see:

http://support.microsoft.com/kb/131016/EN-US/

The lower the number the more frequent the COM port servicing interrupts occur. The larger the number, the less often the COM ports are serviced, hence it is faster, but the more likely that you will receive overrun errors. I would definitely try V5.0 of BurnInTest as I suspect you have a buffer overrun error.

4. We will investigate further tomorrow and respond after this.

5. The main benefit with V5.0 for serial port testing is that it reports more specific COM port errors. BurnInTest V5.0 reports framing errors, buffer overrun errors, input buffer overflow errors, parity errors and Transmit buffer full errors as specific error messages (rather than a broader error description that is reported in V4.0). Some other logging has been slightly improved.

V5.0 also corrects a bug to identify non-existing plugs when the Disable RTS/CTS and DSR/DTR testing has been selected.


Best regards,
Ian (PassMark)

[james_tec]

I am currently having some issues with the loopback testing on 2 COM ports simultaneously using Burn In Test Pro v4.0 on Win XP SP1 & 2 on a few platforms. Most of the results will give me error message of “error while sending data to the COM port(s)”. The testing requirements/configurations in burnintest are:

Duty Cycle 100
RTS/CTS and DSR/DTR testing enabled
Send & receive timeout 3500ms
Port speed 115200Kbits/sec

The default COM port settings in Windows device manager however are as below:
Bits per second: 9600
Data bits:8
Parity:None
Stop bits:1
Flow control: None

In Advanced Settings the Use FIFO buffers(requires 16550 compatible UART) is checked. The Receive Buffer is High(14) & Transmit Buffer is High(16).



My questions:

1. How does the duty cycle(set to 100) affect the COM port transmission?
2. The port speed of the BurnInTest was set to 115200kb/s. The chipset Serial I/O Unit can support up to 115Kbps. However the default COM port settings as can be seen above is 9600bps and the receive and transmit buffers are both set to high. Does the settings in the COM port in any way affecting the loopback test performed? How does it relate to the default settings in the COM port?
3. On the cases that we get an error message, we tried rerun the test by changing the Advanced Settings for COM port Receive Buffer set to Low(1) for both COM ports and no error was found. Can you please explain how the settings of receive & transmit buffer affect the COM data transmission?
4. We also tried the test using the Linux version of BurnInTest and for boards that have critical error on the loopback test before on BurnInTest for Windows, we did not receive such error now when using the Linux version. Does the Linux version in any way different than the Windows version? Does it suggest an OS or driver problem?
5. Specifically for loopback test, what are the improvements on the v5.0 of the Burn InTest Pro compares to v4.0?(bug fixes, etc)

Your clarification on these queries would be much appreciated.

Many thanks.

Regards,
James