Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Altera_Forum
Honored Contributor I
1,068 Views

Error probability UART RS232

Hello everyone, 

 

Is there any way to reduce the error probability in a serial transmission using the UART provided by Altera? For a baudrate of 115200 bps there is a Pe = 0.001 (1 erronous byte each 1000 bytes). Maybe, to fix the error, the rate of the system clk must be different? 

 

Many thanks
0 Kudos
13 Replies
Altera_Forum
Honored Contributor I
59 Views

 

--- 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.
Altera_Forum
Honored Contributor I
59 Views

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++; 

}
Altera_Forum
Honored Contributor I
59 Views

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.
Altera_Forum
Honored Contributor I
59 Views

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.
Altera_Forum
Honored Contributor I
59 Views

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.
Altera_Forum
Honored Contributor I
59 Views

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!
Altera_Forum
Honored Contributor I
59 Views

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

Many thanks.
Altera_Forum
Honored Contributor I
59 Views

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!)
Altera_Forum
Honored Contributor I
59 Views

The error probability is reduced: 

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

 

Pe = 34 / 1004409 = 0.000038
Altera_Forum
Honored Contributor I
59 Views

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.
Altera_Forum
Honored Contributor I
59 Views

Time to write your own uart :-)

Altera_Forum
Honored Contributor I
59 Views

Thanks. I'll consider it :)  

I 'll comment any progress!
Altera_Forum
Honored Contributor I
59 Views

Hmmm.... The standard Altera UART seems to only have a 1x clock input. Even if it uses both edges that isn't enough to (easily) decode async. 

The fifo uart only seems to have pre-defined baud/divisors, so it is difficult to verify from the docs. 

If the data isn't oversampled then it will go wrong.