Honored Contributor
Honored ContributorThanks 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'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't have. The buffer mentioned is not the problem. The buffer can'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
