Error probability UART RS232

--- Quote Start ---

there is a Pe = 0.001 (1 erronous byte each 1000 bytes).

--- Quote End ---

Where did you get this value? Is it your measurement? If so, for which direction?

The value is extraordinary high and seems to indicate a hardware or software design error.

Hi,

I use the uart provided by altera.

The direction is from my pc sending bytes via serial port to the FPGA.

The error rate is in the received bytes of the FPGA.

Y just count when there is an error in the uart status register:

if (status & (FIFOED_AVALON_UART_STATUS_PE_MSK |

FIFOED_AVALON_UART_STATUS_FE_MSK))

{

errors++;

}

Is that meant to be the probability that a valid async character will treated as an error, or that random noise will be treated as a valid character?

A UART clock is likely to be 4 times the baud, and the middle 2 clocks of each bit time can be compared for equality - giving 10 bit pairs that must match per character.

Except that the both samples of the stop bit must be zero, and the start bit (probably) has to last 3 samples. OTOH if your clock is slow you may not want to wait for all the stop bit (to avoid missing the next start bit).

Or, a different sum. At 115k, a 4x clock is 460k, to guarantee a 1% (or better) clock you'll need to divide down from 50x460k or 23MHz.

You need a 2.5% error on a 4x clock to get one clock out before the end of an async char - so 1% should be plenty! I suspect some standard will quote a closes tolerance though - it all depends on the way the UART logic is defined.

I guess, the frame format is N-8-1, so no parity errors should be detected. It would be interesting however to enable parity and check for real transmission errors.

I don't use Altera SOPC components and am not aware of the UART implementation details like bit sampling method and framing. If the UART is used for other purposes than occasional debugging, I won't accept the error rate.

As dsl suggested, you should calculate the actual baud rate achieved with your SOPC clock frequency. In some cases, the timing error margin can be increased by sending an additional stop bit from the peer.

I am using the uart corresponding http://www.alterawiki.com/wiki/fifoed_avalon_uart

My system clock has a frequency of 144 MHz, enough for sampling the serial line. Also, in my tests, it is achieved the maximum baud:

In the FPGA the elapsed time between receiving the first character until the last is 1250 ms, when I transmit 14400 characters in the computer.

(14400 characters * 10 bits/character) /115200 (bits/sec) = 1250 ms

The error in the status register comes when:

assign rxd_shift_reg = unxshiftxrxd_shift_regxshift_reg_start_bit_nxx6_out;

assign {stop_bit,raw_data_in,unused_start_bit} = rxd_shift_reg;

assign is_break = ~(|rxd_shift_reg);

assign is_framing_error = ~stop_bit && ~is_break;

always @(posedge clk or negedge reset_n)

begin

if (reset_n == 0)

unxshiftxrxd_shift_regxshift_reg_start_bit_nxx6_out <= 0;

else if (clk_en)

unxshiftxrxd_shift_regxshift_reg_start_bit_nxx6_out <= unxshiftxrxd_shift_regxshift_reg_start_bit_nxx6_in;

end

assign unxshiftxrxd_shift_regxshift_reg_start_bit_nxx6_in = (do_start_rx)? {10{1'b1}} :

(sample_enable)? {sync_rxd,

unxshiftxrxd_shift_regxshift_reg_start_bit_nxx6_out[9 : 1]} :

unxshiftxrxd_shift_regxshift_reg_start_bit_nxx6_out;

assign rx_in_process = shift_reg_start_bit_n;

assign sample_enable = baud_clk_en && rx_in_process;

...

I suppose the error comes when a bit is out of sync, probably one of the last bit of the 10 sampled bits.

Ok, so the receive async stream is back-to-back 10bit characters?

ie no extra delays between the stop bit of one character and the start bit of the next?

If so it might be that the UART doesn't allow for a short stop bit - which is needed if the transmitter's clock is running slightly faster than the receiver's.

The baud rate divisor might be being 'rounded to nearest', instead try rounding it down - giving a very slightly fast clock. This should mean that a clock of 'line idle' appears after some stop bits.

Hopefully, when you transmit, the receiving hardware works better!

Ok, I understand , maybe i will test with two stop bits in the tx for making the system more stable.

Many thanks.

Tx with 2 stop bits and rx with one.

Actually I doubt anything checks the number of rx stop bits!

(Unless you've got an ASR33 lurking!)

The error probability is reduced:

In this case I have transmitted 1004409 characters and there are 34 erronous.

Pe = 34 / 1004409 = 0.000038

I've just considered 1bit async (each 'char' is 0x1) using a 4x clock.

A start bit sampled at t(0) might have happened just after t(-1) so the next transition might happen before t(3) or after t(4) - so we must not sample t(4n-1) or t(4n).

t(1) and t(2) are the rest of the start bit - must be zero.

t(5) and t(6) are the data, and must match.

t(9) and t(10) are the stop bit, both must be 1.

t(11) might be the start bit for the next character.

Really shouldn't be that hard!

I've just corrected the async format.

Another uart spec I have uses 8, 16 or 32 times clock checking the middle 3 samples.