Announcement

**Ian (PassMark)** · Mar-22-2006, 07:03 AM

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)

**David_H** · Mar-22-2006, 06:11 PM

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

**james_tec** · Mar-23-2006, 02:30 AM

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

**Ian (PassMark)** · Mar-23-2006, 05:08 AM

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** · Mar-27-2006, 03:32 AM

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

**David (PassMark)** · Mar-27-2006, 03:52 AM

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** · Mar-27-2006, 07:56 AM

Hi David,

Thanks.
I've read that in the linux website before & I understand that we cannot set the UART FIFO buffer directly but is there any way we can retrieve the buffer default settings on that?
Cheers.

Regards,
James

**David (PassMark)** · Mar-27-2006, 09:20 AM

Unfortunately we don't know the exact answer.

I did some research in the Kernel source code for you. The serial port FIFO size is set to a different value depending on your hardware and it might also be different in different Linux distributions and in different versions of the Kernel. I was looking at the i386 V2.6.11

You could try posting the question in the Linux user forum for your Linux distribution. If you 'purchased' Linux you might be able to go back to the vendor and ask them the question.

This is what I found the Kernel

Code:

static const struct serial8250_config uart_config&#91;&#93; = &#123;
164         &#91;PORT_UNKNOWN&#93; = &#123;
165                 .name           = "unknown",
166                 .fifo_size      = 1,
167                 .tx_loadsz      = 1,
168         &#125;,
169         &#91;PORT_8250&#93; = &#123;
170                 .name           = "8250",
171                 .fifo_size      = 1,
172                 .tx_loadsz      = 1,
173         &#125;,
174         &#91;PORT_16450&#93; = &#123;
175                 .name           = "16450",
176                 .fifo_size      = 1,
177                 .tx_loadsz      = 1,
178         &#125;,
179         &#91;PORT_16550&#93; = &#123;
180                 .name           = "16550",
181                 .fifo_size      = 1,
182                 .tx_loadsz      = 1,
183         &#125;,
184         &#91;PORT_16550A&#93; = &#123;
185                 .name           = "16550A",
186                 .fifo_size      = 16,
187                 .tx_loadsz      = 16,
188                 .fcr            = UART_FCR_ENABLE_FIFO | UART_FCR_R_TRIG_10,
189                 .flags          = UART_CAP_FIFO,
190         &#125;,
191         &#91;PORT_CIRRUS&#93; = &#123;
192                 .name           = "Cirrus",
193                 .fifo_size      = 1,
194                 .tx_loadsz      = 1,
195         &#125;,
196         &#91;PORT_16650&#93; = &#123;
197                 .name           = "ST16650",
198                 .fifo_size      = 1,
199                 .tx_loadsz      = 1,
200                 .flags          = UART_CAP_FIFO | UART_CAP_EFR | UART_CAP_SLEEP,
201         &#125;,
202         &#91;PORT_16650V2&#93; = &#123;
203                 .name           = "ST16650V2",
204                 .fifo_size      = 32,
205                 .tx_loadsz      = 16,
206                 .fcr            = UART_FCR_ENABLE_FIFO | UART_FCR_R_TRIG_01 |
207                                   UART_FCR_T_TRIG_00,
208                 .flags          = UART_CAP_FIFO | UART_CAP_EFR | UART_CAP_SLEEP,
209         &#125;,
210         &#91;PORT_16750&#93; = &#123;
211                 .name           = "TI16750",
212                 .fifo_size      = 64,
213                 .tx_loadsz      = 64,
214                 .fcr            = UART_FCR_ENABLE_FIFO | UART_FCR_R_TRIG_10 |
215                                   UART_FCR7_64BYTE,
216                 .flags          = UART_CAP_FIFO | UART_CAP_SLEEP | UART_CAP_AFE,
217         &#125;,
218         &#91;PORT_STARTECH&#93; = &#123;
219                 .name           = "Startech",
220                 .fifo_size      = 1,
221                 .tx_loadsz      = 1,
222         &#125;,
223         &#91;PORT_16C950&#93; = &#123;
224                 .name           = "16C950/954",
225                 .fifo_size      = 128,
226                 .tx_loadsz      = 128,
227                 .fcr            = UART_FCR_ENABLE_FIFO | UART_FCR_R_TRIG_10,
228                 .flags          = UART_CAP_FIFO,
229         &#125;,
230         &#91;PORT_16654&#93; = &#123;
231                 .name           = "ST16654",
232                 .fifo_size      = 64,
233                 .tx_loadsz      = 32,
234                 .fcr            = UART_FCR_ENABLE_FIFO | UART_FCR_R_TRIG_01 |
235                                   UART_FCR_T_TRIG_10,
236                 .flags          = UART_CAP_FIFO | UART_CAP_EFR | UART_CAP_SLEEP,
237         &#125;,
238         &#91;PORT_16850&#93; = &#123;
239                 .name           = "XR16850",
240                 .fifo_size      = 128,
241                 .tx_loadsz      = 128,
242                 .fcr            = UART_FCR_ENABLE_FIFO | UART_FCR_R_TRIG_10,
243                 .flags          = UART_CAP_FIFO | UART_CAP_EFR | UART_CAP_SLEEP,
244         &#125;,
245         &#91;PORT_RSA&#93; = &#123;
246                 .name           = "RSA",
247                 .fifo_size      = 2048,
248                 .tx_loadsz      = 2048,
249                 .fcr            = UART_FCR_ENABLE_FIFO | UART_FCR_R_TRIG_11,
250                 .flags          = UART_CAP_FIFO,
251         &#125;,
252         &#91;PORT_NS16550A&#93; = &#123;
253                 .name           = "NS16550A",
254                 .fifo_size      = 16,
255                 .tx_loadsz      = 16,
256                 .fcr            = UART_FCR_ENABLE_FIFO | UART_FCR_R_TRIG_10,
257                 .flags          = UART_CAP_FIFO | UART_NATSEMI,
258         &#125;,
259         &#91;PORT_XSCALE&#93; = &#123;
260                 .name           = "XScale",
261                 .fifo_size      = 32,
262                 .tx_loadsz      = 32,
263                 .fcr            = UART_FCR_ENABLE_FIFO | UART_FCR_R_TRIG_10,
264                 .flags          = UART_CAP_FIFO,
265         &#125;,
266 &#125;;

------
David

**james_tec** · Mar-29-2006, 05:10 AM

Hi David,

Thanks for your help & info.

I have a couple of questions to ask regarding BUrnintest testing itself:

1. Is there any known difference in the way Linux BurnIntest performs the loopback test for COM port compares to Windows Burnintest? (testing pattern, mechanism etc)

2. We are hoping to get the data pattern generated in Burnintest. I understand that random numbers are used. In what order do the numbers here resemble the instance when an error occurs? Just confirming on how to decode the data pattern here to hardware binary(bolded below).

CRITICAL : 2006-03-29 11:28:11, Serial, Error while receiving from the COM port. Check plug is connected.
LOG NOTE: 2006-03-29 11:28:11, Serial, \\.\COM1 Speed: 115200baud BlockSize: 100 BlockNum: 0 Transferred: 0 Handle:00000548 Total: 0, ErrorCode: 0
LOG NOTE: 2006-03-29 11:28:11, Serial, 29 6B D6 EB 2C A9 3 21 BB EF 5F 5F 4C FC 10 EC BE D4 ED 51 6 45 4D 99 25
LOG NOTE: 2006-03-29 11:28:11, Serial, 8E 51 65 53 5 5C 33 EC 3F 54 16 A7 22 CD CC 8F 60 D4 F3 4E 4A 60 3D CB EE
LOG NOTE: 2006-03-29 11:28:11, Serial, 2F 68 16 75 93 6D 35 33 F4 D 4C E6 5 39 21 10 73 11 8B D0 A1 5A 50 63 91
LOG NOTE: 2006-03-29 11:28:11, Serial, 32 D8 F6 A8 E9 F9 80 72 40 8D 6E 79 EC A1 2B 72 36 92 67 B6 76 35 2A EA DD

Really appreciate your support on this.

Thanks,
James

**Ian (PassMark)** · Mar-29-2006, 07:06 AM

James,

Just further to David's post, it would appear that the source code snippet for this version of Linux enables (for example) the 16550A UART FIFO and sets the Receive FIFO to trigger an interrupt when it has (presumably) 10 bytes (UART_FCR_ENABLE_FIFO | UART_FCR_R_TRIG_10). It does not have a specific Transmit FIFO buffer trigger. It would seem like the UART FIFO buffer interrupt triggers may be hardcoded based on the type of UART chip in the PC. From the perspective of receiving Transmit or Receive buffer overrun errors while testing serial ports with BurnInTest, I suspect this is one the main differences between Windows and Linux.

The BurnInTest COM port test mechanism is the same in both the Windows and Linux versions. The mechanism is basically as follows:

while test running
{
Create buffer of 100 bytes long with random data:
Write 100 byte buffer to COM port x (block 0)
Write 100 byte buffer to COM port x (block 1)
Write 100 byte buffer to COM port x (block 2)
Read 100 bytes from COM port x and verify data (block 0)
Read 100 bytes from COM port x and verify data (block 1)
Read 100 bytes buffer from COM port x and verify data (block 2)
}

The error in your post occurs when on reading the first block of data, 0 bytes are returned (when 100 were expected). The bolded text is the 100 byte random data buffer that was sent (and expected to be available to read). This would normally be the case if the Serial loopback plug was not attached to the COM port under test. Please check the serial loopback plug is attached and try another serial loopback plug to at least rule out the plug.

Also, I would turn on Trace 2 logging and re-do the test. You can post the relevant sections from the .trace file here or send the complete .trace files to help [at] passmark [dot] com.

Best regards,
Ian

**Kevin** · Apr-17-2006, 08:42 PM

Serial Port Speeds

Two questions:

1) I have a serial communications device (RS485) that works at 921.6 kbps and that is the speed I need to be able to test it at. The maximum port speed on the software (BurnInTest Pro v5.0 [registered] for win32) is only 256 kbps. Is there any way that I can change the port speed to match my serial device?

2) I also use the regular RS232 comm ports. Typically I will run these ports at 9600bps, 19200bps, and/or 115.2kbps. Is there any way I can test these three speeds specifically without choosing the 'cycle to 115k' option? Or, even if I could test the upper and lower bounds it would be fine as I'd rather not waste test time by testing at speeds that will never be used.

Thank-you
Kevin

**Ian (PassMark)** · Apr-18-2006, 12:03 AM

Kevin,

1) Presently there is no way to achieve this. If you would like this functionality, we would be pleased to provide a quotation to add this functionality.

2) To only test certain COM port speeds you will need to use a BurnInTest script. Lets say you want to test COM1 at 9600 for 1 minute and 19200 for 1 minute, you would create two configuration files. For the first, you would set the port speed to 9600 and save this to a configuration file named something like "COM1_9600.bitcfg" (or .cfg if you are using BurnInTest V4.0). For the second, you would set the port speed to 19200 and save the config file as "COM1_19200.bitcfg". In both configurations you should set logging to accumulate results (at the bottom of the logging preferences window).

You would create a script file using any text editor, with something like the following scripting:

####################
#Test COM1 at 9600 and 19200
####################
LOAD "COM1_9600.bitcfg"
SETDURATION 1
LOG "Running Serial COM1 at 9600 for 1 minute"
RUN SERIAL
LOAD "COM1_19200.bitcfg"
SETDURATION 1
LOG "Running Serial COM1 at 19200 for 1 minute"
RUN SERIAL

This is just an example, and there are a number of different ways to script this type of test.

Best regards,
Ian (Passmark)

**BrooksL** · Feb-16-2008, 12:31 AM

Error while sending data to COM port (serial loopback)

We are having and issue with running the COM port loopback test and periodically getting the "Error while sending data to COM port" message.

Running WinXP SP2, BIT 5.1, Intel Xeon + 6300ESB ICH Southbridge.

The error only seems to occur while testing both COM ports, usually in the beginning, reccuring ~20~40min when run continuously, regardless of baud rate selection.

Tried, changing ports' I/O address, IRQs, and FIFO settings to 1 byte in Device Manager; no effect on error.

Here's the Activity Level 2 .trace excerpt:

LOG NOTE: 2008-02-15 15:49:46, Serial Port 2, Starting test (fixed baud)
LOG NOTE: 2008-02-15 15:49:46, Serial Port 1, Starting test (fixed baud)
LOG NOTE: 2008-02-15 15:49:47, Serial Port 2, Send 3 blocks of 100 random bytes. (Sample 1 of 100)
LOG NOTE: 2008-02-15 15:49:47, Serial Port 1, Send 3 blocks of 100 random bytes. (Sample 1 of 100)
LOG NOTE: 2008-02-15 15:49:51, Serial Port 2, Read and verify 3 blocks of 100 random bytes. (Sample 1 of 100)
LOG NOTE: 2008-02-15 15:49:51, Serial, \\.\COM1 Error detail: 57.0
LOG NOTE: 2008-02-15 15:49:51, Serial, \\.\COM1 Status detail: 0, 0, 0, 0, 0, 0, 0, 0, 0
LOG NOTE: 2008-02-15 15:49:51, Serial, \\.\COM1 Speed: 19200baud BlockSize: 100 Transferred: 0 Handle:00000558 Total: 0, ErrorCode: 0
CRITICAL : 2008-02-15 15:49:51, Serial, Error while sending data to the COM port
LOG NOTE: 2008-02-15 15:49:52, Serial Port 1, Send 3 blocks of 100 random bytes. (Sample 1 of 100)
LOG NOTE: 2008-02-15 15:49:52, Serial Port 1, Read and verify 3 blocks of 100 random bytes. (Sample 1 of 100)
LOG NOTE: 2008-02-15 15:50:20, Serial Port 2, Send 3 blocks of 100 random bytes. (Sample 1 of 100)
LOG NOTE: 2008-02-15 15:50:20, Serial Port 2, Read and verify 3 blocks of 100 random bytes. (Sample 1 of 100)

This error is not isolated to one motherboard, it's happening on all of them. What can you tell me about what causes this error message?

Please advise,
-- BrooksL

**Ian (PassMark)** · Feb-17-2008, 11:52 PM

This error occurs when a write to COM 1 sent less than the expected number of bytes. In this case, on attempting to write 100 bytes to COM port 1, 0 bytes were actually sent. In this case, the detailed error reporting does not really tell you much more than that. The sequence of events seems to indicate that it is the first write the COM port 1 that fails, but after closing and re-opening the COM port the ports seems to work OK.

I am not sure what would cause this specific behavior.
Are you using the built in Microsoft serial port device drivers?
Does the error always at the start of the test?
Does the error always with COM1?
Are you running any other tests at the time, or other software?

Regards,
Ian

Announcement

COM port loopback test & settings

COM port loopback test & settings

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment