Nios-II SOPC UART delivers wrong bytes

[Altera_Forum]

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 GmbH

[Altera_Forum]

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]

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]

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]

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]

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]

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]

>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]

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]

Unfortunately Altera has close mySupport request without delivering any answer except that they have received my request. 

 Regards  Michael Schmitt

[Altera_Forum]

I have met the same problem of "mysupport" with you...

[Altera_Forum]

There's no buffering of the data being sent or received in the UART, so if you can't keep up, it will drop data... Could this possibly be what you're seeing? 

 Cheers,  - slacker

[Altera_Forum]

Hi slacker, 

 the uart delivers data that is definitly not part of the serial data stream.   We have monitored the data that is transmitted from the uart to the nios with the signal tap by watching the readata and trigger set to chipselect with the adr equal to the databyte. Well as we do not have the source of this uart i agree that it could be that we see data that is beeing corrupted. we have no idea how we could see what is realy detected when the uart generates the receive interrupt. readdata is only valid during chipselect. and it could be that the time between generating the interrupt and accessing the data is too long but :  we have a half dulpex transmission.  the serial data stream is "idle" for a while, meaning continous 1 like stop bit the serial data stream starts with a 0x02 followed by some other data mostly the first data byte is received as 0x04 instead of 0x02 but the following bytes are mostly correct.  so as 0x04 (the wrong data) is the first data being received and further data is correctly received by the same interrupt routine i don't think that the time between int generation and databyte access is the source.  but maby somebody from altera can tell me what register inside the uart instead of readdata i should monitor with signaltap ...  Regards  Michael Schmitt  BTW i have tried to re-open the mysupport request ...

[Altera_Forum]

I&#39;m not sure what you mean by "don&#39;t have the source". It&#39;s in plain text and all there for you to view, in Verilog or VHDL. It&#39;s also the Europa (Perl-based Verilog/VHDL generation) example component (see <nios2_install_dir>/components/altera_avalon_uart/em_uart.pl).....also in plain text. 

 I haven&#39;t looked at the UART or used it very much, so I can&#39;t comment on what registers to view. I would definitely recommend re-opening the service request on MySupport, since the response you received was not satisfactory.  Best Regards,  - slacker

[Altera_Forum]

It certainly sounds like a hw problem, but to prove that it is not SW/timing related, you should use the simplest possible single-threaded test code. Just take the hello_world example and modify it to echo back everything it receives. Open the uart twice, once for read and once for write. Use a Y cable so a PC (not a scope) can be used to independantly monitor what is really going into the uart. For multi-tasking apps in particular, you should increase the default 64 char buffer size in altera_avalon_uart.h

[Altera_Forum]

Also try out Bray terminal (I&#39;m guessing you are using hyperterminal). I have heard of issues with uart buffer flushing on the PC side as well. When you say that you read 2 instead of 4 are you sure you are triggered properly? (i.e. sampling before the shift operations are complete). This could be any number of problems so until you get more help from us we need some more information (how you set up the uart, flow control?, baud rate, what you have on the host side, etc....). Also so that we are on the same page here, which direction are you referring to in your posts? (sometimes it sounds like tx and other times it rx)

[Altera_Forum]

Thanks for all your replies and i will try to answer the open questions this morning. 

 we aware of the hyperterminal problem and we use terraterm if we monitor serial data.  Just to make some things clear ....  We have the JTAG Uart implemented as well to have the panic-output console available that euros (the OS) offers. via JTAG we do a printf with the content we have received via the avalon uart we have the problem with. so if we see a string on our pc monitor, it is the "dump" via the jtag uart with the content the nios has received. as this is pure ascii and no interpretation we assume that there is no problem with the pc or the software running on that computer.  we have one nios-fpga that acts as a master, sending data via the avalon uart that is converted to a differential signal and carried along the cable. several other nios-fpga are connected to that half duplex RS485 line. Each one of them also has the avalon uart listening. And there are some boards connected that have for example a i386EX CPU with build in Uarts. We have the equipment to monitor the serial line (also eye-pattern) like digital scopes (HP54645D, LeCroy, ...) and of course the experience to do that :-)  Imagine the serial bus is idle for a wihle. now the master boards sends out a 0x02 followed by a couple of other bytes. The boards with i386EX always receive the 0x02 and all other bytes with no problems. The boards with the Nios Uart sometimes receive a 0x04 and then all other bytes. The digital scopes always show the correct 0x02 as the first byte on the seria line. we see the startbit followed by 0x02 and the stopbit. no jitter and a perfect 50:50 duty cycle. So the electrical transmision was perfect. no error here.  So we droped signaltap into out design to monitor what data is transfered from the uart to the nios via avalon. we monitored readdata, chipselect, adress, read, write, ....  we triggered on chipselect, read, and adress equal to the data register of that uart. and indeed the uart transmits a 0x04 on readdata.  so the nios correctly reports a 0x04. but there has never been a startbit + 0x04 + stopbit on that line. remember that the serial line was idle and the first byte sent was 0x02 but nios gets a 0x04. no idea how the uart creates this.  we have no flow control. every data that is available will be received and then transmitted to the nios. yes we have half duplex. yes the rts is used to switch the rs485 chip between receive and transmit. yes nios does the switching between receive and transmit by software. but again the digital scopes directly connected on the rxd, txd and rts signals outside the fpga show a perfect transmission and a correctly set rts signal. so the rxd signal that enters the fpga is as perfect as expected. assuming here that every uart we have used bevore would correctly interprete that serial stream as 0x02. but the nios uarts delivers a 0x04.  if it is not clear by now the whole data transmission is between fpga&#39;s that contains the nios uart. the data that leaves one fpga is correct. the data that enters the other fpga is correct as well.  each fpga has a jtag and a normal debug uart. so we see what each fpga has received. as mostly the first byte is wrong, our quick work around is to replace a first 0x04 by a 0x02 and then check the whole stream (crc) and mostly everything is fine. but this consumes time what we don&#39;t have.  The buffer mentioned is not the problem. The buffer can&#39;t be large enough to correct a wrong data. the uart definitly delivers a 0x04 via avalon to the nios cpu. so the buffer, how large it would ever be, will contain a wrong data. signaltap showed us the whole byte stream the uart delivers to the nios cpu. so we see in signaltap the same wrong data in the same order as the nios cpu reports by jtag uart (printf) or the debug uart (the same avalon uart).  Now i hope that i had made it clear that the data that enters the fpga is the correct stream. no jitter and a perfect duty cycle. we see the startbit the 0x02 data and the stopbit. it looks like  1111....1111100100000010xxxxxxxx10xxxxxxxx10xxxxxxxx10xxxxxxxx11111111111  s--0x02--s so this transmission is perfectly received. but again no 0x04 on that stream. The serial stream is 115200 bit / sec with a 48MHz clock. 48MHz is not a perfect clock but the error is less than 0,07%.  For us it seems to be clear that the problem is located inside the fpga.   I startet a new myservice request with a note to the first service request. but no response other that it has been received yet.  Again. thanks for all comments here, any help is welcome.  Reagards.  Michael Schmitt

[Altera_Forum]

If you&#39;re getting an 0x04 when you expect an 0x02, that sounds like a timing problem, like the UART is picking the wrong spot to sample the bit (or maybe there&#39;s a slow edge rate on the driver/receiver?), or is set to a close but incorrect rate (SOPC builder clock rate not the same as the real system&#39;s?). 

 I don&#39;t see much choice for you aside from looking at the receive signal at or near the FPGA pin, and if that looks perfect, start probing some signals inside the UART with SignalTap.

[Altera_Forum]

Mike, i endeed too had the idea that there is a problem with the timing. so i connected one of my debug output pins directly to the rxd input pin of the uart to see what enters the uart but again a perfect signal. 

 we have checked the settings of the uart to see if the OS does the right stuff.  The nios uart now gets remove in this application by an ip core developt here that is capable to handle multi master, self arbitrationing, ... and runs at 16MBit on the same targets as the uart.   But we have some equipment left that needs this uart. This morning i had found the sources of the uart, but currently no time to setup signal tap to dig into this uart. so no idea if there is a signal filtering on that rxd line and how the startbit detection works and when the uart samples.  I want that uart working to have in my mind that i can use it in the future again. so i will investigate as soon as i find some time for this. currently the solution with the uart is useless for an industrial enviroment. but in the current app the uart was temporarily until our ip was available.  Michael Schmitt

[Altera_Forum]

--- Quote Start ---  originally posted by mschmitt+aug 29 2005, 10:42 am--><div class='quotetop'>quote (mschmitt @ aug 29 2005, 10:42 am)</div>  --- quote start ---  i connected one of my debug output pins directly to the rxd input pin of the uart to see what enters the uart but again a perfect signal.[/b]  --- quote end ---   so it&#39;s not the comms hardware.    --- quote start ---  originally posted by mschmitt@aug 29 2005, 10:42 am we have checked the settings of the uart to see if the os does the right stuff.  --- quote end ---   you can also try hardwiring the uart speed.    --- quote start ---  originally posted by mschmitt@aug 29 2005, 10:42 am the nios uart now gets remove in this application by an ip core developt here that is capable to handle multi master, self arbitrationing, ... and runs at 16mbit on the same targets as the uart.  --- quote end ---   sounds like the best plan. just out of curiosity, how fast was this uart supposed to run?  <!--quotebegin-mschmitt@Aug 29 2005, 10:42 AM i want that uart working to have in my mind that i can use it in the future again. so i will investigate as soon as i find some time for this. currently the solution with the uart is useless for an industrial enviroment. but in the current app the uart was temporarily until our ip was available.  --- Quote End ---   The Nios UART never came across to me as being very robust; it&#39;s not like the 6811&#39;s UART with its majority-sampling and noise flags. I&#39;m not sure it was intended to work in an industrial environment as much as be a debug console port.

[Altera_Forum]

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. 

 well currently i am not shure if the software engineers have tried the fpga version with locked baudrate. sorry i cannot tell you what happens if the uart is locked by sopc to run at 115200 8N1 :-( but to be shure i need this information.  Our new IP is much more than just a uart. it carries the signal with 16MBit/sec with a clock speed of 64MHz. what means that this uart could transfer 1,6MByte/sec minus the protocol. This IP core can work with duty cycles of 60:40 to 40:60, jitter on the signal. it always resync&#39;s inside the stream. the rxd is filtered so spikes and glitches won&#39;t disturb. This has been designed with our full custom asic tools on our SUN over worst case situations and successfully implemented on our target. so each device is a master and the ip core handles arbitration with a guranteered maximum bus cycle time. so no software overhead.   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.  In some of our ip cores we go a bit further and check if the first half of the startbit is zero with each clock cycle. This is needed if the signal comes from a rf-transmission where every little "fly" can disturb and modify the signal.  Yes for industrial inviroment we need a uart that is some kind of "bullet proof".  And the fact that other uarts (not the sopc uart) detects the transmitted 0x02 and only the sopc uart delivers wrong data ......... (i will not comment this any further)