Nios-II SOPC UART delivers wrong bytes

--- Quote Start ---

originally posted by mschmitt+aug 30 2005, 01:42 am--><div class='quotetop'>quote (mschmitt @ aug 30 2005, 01:42 am)</div>

--- quote start ---

mike you mean that the electrical layer is not the source of the problem ? it must be inside the fpga ? if so .. yes i agree with you.[/b]

--- quote end ---

in the fpga firmware is my guess.

<!--quotebegin-mschmitt@Aug 30 2005, 01:42 AM

the first thing i will look after inside the uart core is, if the rxd signal is filtered. i would expect that the rxd signal is piped into a shift register where a 3 out of 4 detection triggers a srff. 3 one&#39;s will set and 3 zero&#39;s will clear this filtered rxd. if there is no filtering any glitch could trigger.

--- Quote End ---

I doubt that the Altera UART was designed to be bullet-proof at all. It looks like it&#39;s about as simple a UART implementation as possible. Simple edge checking for the start bit and one sample per data/parity/stop bit. This is more than enough for debug port and low-speed console applications. I think that Altera expected customers who needed more features to either buy a MegaCore (16450 or equivalent) or write their own.

there is timing problem.

with UART baudrate = 115200bps and System Clock 48Mhz

SOPC calculate baud error.

that is almost 0.04%(maybe 1byte data loss per 20byte stream)

but. Set system clock to 50Mhz

that is <0.01%

so, I have set system clock to 50Mhz, and test some long UART datastream. (50Kbyte)

that looks perfect.(single thread test)

now I have two problems.

one is how to check datastream end.(for now using timeout method)

the other is testing in multi thread environment.

did you try 50 Mhz as clock ?

I use Quartus 5.0 Nios 5.0, no OS

clock 50Mhz and uart baudrate 115200

I changed circular buffersize in avalon_uart.h (from 64 to 2048 bytes)

We use Hyperterminal and ymodem file download to nios with

no retransmits (uart works ok).

I had tow pitfalls with RS485 (older projects) I can remember,

1. use 1k pullup,pulldown (BIAS resistors) to VCC and GND to get a defined

level if no device is active on the bus.

2. to switch of the rs485 tranceiver it is sometimes dangerous to use

a "transmit register empty" interrupt, (perhaps data is still present

in the transmit shift out register, tx still running)

Have you checked the UART status register to see if there was some sort of receive error such as receive overflow or parity bit error...

Also you should check out the FIFOed UART in the projects section. I was having similar problems and found it was due to the processor not serviceing the UART fast enough. At low speeds a 16 byte fifo will solve your problem I think. You might try a deeper one though especially since you are running an OS.

Have you tried giving the UART IRQ top priority?

I wrote my own FIFO UART to allow higher interrupt latency (and this was only at 38k Baud)

Oh ... an old posting from my side ...

we use a multitasking OS that does fast enough switching if an interrupt occurs. even a couple of avalonmasters with 1-2MB/sec and INTs every <50uSec is no problem.

So the software is fast enough. The fact is that we read bytes from the uart that where never transmitted. no errorbit set. we have monitored that with signaltap.

the normal uart is not used any more. there were some other postings here reporting similar problems. we have use a self written uart to get rid of these problems. but even that was only a temp. solution.

Having a short look at the uart source showed us that we do not see any kind of filtering to get rid of spikes .....

Michael

I have seen the same problem too at high bitrates with continuous dataflow on the port.

My guess is that the Altera UART "waits" for the complete stopbit before it start syncing on the startbit of the next character. This is a problem if the two bitrates are not 100% identical.

I replaced the Altera Uart with one from Digital Core Design and there was no problem.

Jan Ulvesten

SICOM

Just some words here again what problem we had when we used this uart.

The uart was idle then a couple of bytes arrived.

the bytes at the beginning were wrong.

mostly the first byte

this means the last stopbit was ages old ....

funny thing here .. after the first bytes the rest was okay.

Michael

hello michael,

what kind of termination do you use for rs485 ?

do you bias the bus with resistors, like it is shown in

the following document in figure 7 (multidrop/fail-safe termination) ?

http://www.maxim-ic.com/appnotes.cfm/appnote_number/723 (http://www.maxim-ic.com/appnotes.cfm/appnote_number/723)

http://pdfserv.maxim-ic.com/en/an/an723.pdf (http://pdfserv.maxim-ic.com/en/an/an723.pdf)

Hi Fischer,

the transceiver is a true fail safe type MAX3078xxx with hardware autotermination.

The design is a multi master, self arbitrating, 16MBit/sec Bus with priority of different Masters and datatelegramms running as a avalon master.

Bevor this design was finished we used the sopc uart as a transport module so the software group could start implementing der code. our nios was running at 64MHz und the uart was not able to run faster than 38400 without delivering wrong bytes at the beginning. Again a long "idle" meaning a "1" on the line and then a data telegram travels along tha bus leading to wrong bytes.

the hardware now runs at 16MBit/sec without any modification. If the termination is on we haven&#39;t any wrong bit or corrupted telegramm. The "gap" between two transmitting masters is less than 2uSec. taking into account the roundtriptime along a 100m cable of about 60% of c and the delay the tranceivers introduce.

The bus hardware is not the source of the problem. It is qualified and testet and signed "bullet proof" for industrial application and the emc disturbances that could happen. All parts like tranceivers, cable, connectors, layout, .... are very well engineered for transmission of up to 16MBit/sec.

The signal that comes into the fpga is perfect. External measurements using LeCroy scopes and SignalTap showed a absolut stable signal. we could "see" the correct bit pattern and see what the uart delivers to nios via avalon. The data entering the sopc uart was a perfect and correct serial bitstream, but the parallel data stream was wrong. again .... the start of the data was mostly wrong and it has happend that the data somewhere in the middle was wrong. So if the uart is idle and has nothing to do, the first startbit enteres the uart followed by the 8 databits and a stopbit why does the uart deliver a wrong databyte ?

The uart is not used anymore for this bus and replaced by the finished sopc module i have written. it is only used for a terminal interface the softwaregroup wants during debugging.

but we will use a uart if a customer wants a good old serial interface as a host connection and then we will deceide what uart will be used.

I do not think that the sopc uart will be used as it is currently not reliable.

Michael Schmitt