Forum Discussion
Nios-II SOPC UART delivers wrong bytes
We use the UART in our Nios-II design that comes with Quartus 5.0SP1 and Nios-II 5.0
We face the problem that sometimes the Uart reports wrong RX Bytes from correct RX streams. The serial stream starts with a 0x02 byte but the UART delivers a 0x04 byte. Monitoring the serial signal outside the FPGA and inside the FPGA shortly before it enters the UART shows that the stream correctly contains the 0x02. So no electrical problem. a perfect signal. Has somebody a clue how to find the problem for this ? Could it be that the Altera UART has a problem ? The serial stream is 100% perfect no jitter and a 50:50 duty cycle. The UART is set to 115200 8Bit no parity 1 stopbit and the Clock is 48MHz (but will be set to 64MHz in the next step). Our FPGA is a EP1C20. BTW we use EUROS as the real time OS. Regards. Michael Schmitt Baumer Ident GmbH30 Replies
- Altera_Forum
Honored Contributor
We are finding the same or a similar problem. We have 2 devices, we program one to just transmit. Every four seconds we send a blast of data 0-255. If we enable Rx and listen to ourself on that device, we hear all 256 characters nice and clean. We then plug into a second device and enable it to Rx. We loose about one byte in 16. We have tried blocking, non-blocking, read only, read write, disabling the transmitter. We have tried open(), fopen(), we have used getc() and read(), and more.
These have no apparent affect on the input. The scope shows what looks like a clean pattern. Anyone with solutions would be GREATLY appreciated. Regards, Jeff Ballif - Altera_Forum
Honored Contributor
If i understand you right you have the following setup :
I guess you use half duplex like RS485 ? You disable the receiver during transmitting, in order not to receive your own data, and reenable the receiver afterwards again ? We use the RTS signal to control a RS485 driver. Mostly the first received character is wrong. But sometimes a byte in the middle is wrong. A 0x02 is always a 0x04 if we get a wrong data from the UART. What i do not understand from your reply is "if we plug in another device" does this mean you connect another device to your cable ? does this have an effect of the serial datastream ? Here we can plug and unplug the serial datastream is not affected but sometimes the UART delivers wrong data. Note that only the nios Uart delivers wrong data. "real" Uarts like a 16450 or 16550 always receive the correct value if nios delivers the wrong value. A Digital scope (HP54645D) with a snapshot of the receiver in pin of the uart *always* shows the correct value. The same HW setup without the nios sopc uart, but instead used an own core, is able to comunicate up to 16MBit/sec without any change in the HW setup except the FPGA. Regards. Michael Schmitt - Altera_Forum
Honored Contributor
We had the same problem - I tried to use the UART together with DMA . At lower baudrates (up to about 115k2) it worked more or less. But we looked for baudrates up to 2Mbit/s. Finally we wrote our own UART with 512 Byte deep fifos - for rx and tx.
Chris - Altera_Forum
Honored Contributor
Hi,
I met the similar problem when I use the UART in NiosII5.0 + QuartusII 5.0. But I tried an alternative approach via some code programmed by myself to tackle this problem and it seems that it works normal now. The way I program is to capture some fixed digit in my code. But the side effect is evident too,that is the time for processing are prolonged about 1 time. - Altera_Forum
Honored Contributor
Hi,
I met the similar problem when I use the UART in NiosII5.0 + QuartusII 5.0. But I tried an alternative approach via some code programmed by myself to tackle this problem and it seems that it works normal now. The way I program is to capture some fixed digit in my code. But the side effect is evident too,that is the time for processing are prolonged about 1 time. - Altera_Forum
Honored Contributor
Today i "Signaltaped" this problem and indeed the uart delivers wrong data.
Currently i have no clue why as i do not have the source. So the problem is not OS related. The Nios get data on the signal "readdata" if accessed register 0 that are definitly not transmitted. tommorow i will put a self made uart inside my project to nail down thesource ... regards - Altera_Forum
Honored Contributor
>Today i "Signaltaped" this problem and indeed the uart delivers wrong data.
Hi MSchmitt, what the type of download cable you are using? Is that BB-II? I heard that BB-II has a poor performence when it is used for debugging and signaltapping. The cable itself perhaps result in wrong code! So if you wanna make sure that is the problem caused by UART, I think perhaps USB Blaster is a little bit better. Regards, Don - Altera_Forum
Honored Contributor
Good morning,
of course we are using USB Blaster Rev.B I do not think that a "slow" Blaster can be the reason for wrong data being received by the uart. we started the investigation because we noticed wrong data beeing received. To find the source if the OS has a bug or the uart realy delivers wrong data. within signaltap if i trigger on falling edge of chipselect and rising edge of read_n with adress = 0 i get the data the uart transfers to the nios by having a look at readdata. as we see here wrong data the os is not the source. but why does the uart deliver wrong data ? the serial stream is perfect no jitter and 50:50 duty cycle. And without a blaster connected we also have the wrong data. Michael Schmitt - Altera_Forum
Honored Contributor
Unfortunately Altera has close mySupport request without delivering any answer except that they have received my request.
Regards Michael Schmitt - Altera_Forum
Honored Contributor
I have met the same problem of "mysupport" with you...