Nios® V/II Embedded Design Suite (EDS)
Support for Embedded Development Tools, Processors (SoCs and Nios® V/II processor), Embedded Development Suites (EDSs), Boot and Configuration, Operating Systems, C and C++
The Intel sign-in experience has changed to support enhanced security controls. If you sign in, click here for more information.
12517 Discussions

Weird problem with Fifoed-UART

Honored Contributor II

I am experiencing problems with Fifoed-Uart, first I have tried the latest version (v13.1) and I have seen that it is not generating RX-FIFOs (I inspected the verilog files, TX-FIFOs are there, but RX-FIFOs are missing), I think it is caused by a typing error in pm file named: "" 



#enw for fifoed uart 

$use_tx_fifo = $Options->{use_tx_fifo}; 

$use_rx_fifo = $use_rx_fifo; 

$hw_cts = $Options->{hw_cts}; 

$trans_pin = $Options->{trans_pin}; 

$fifo_size_tx = $Options->{fifo_size_tx}; 

$fifo_size_rx = $Options->{fifo_size_rx}; 



I think the line "$use_rx_fifo = $use_rx_fifo;" has a typing error, but when I changed it as "$use_rx_fifo = $Options->{use_rx_fifo};", I cannot make qsys generate the files. It freezes while creating the files. 


After that I managed to use an earlier version (v9.3.1), everything seems fine with this one but I cannot receive first 63 chars somehow after starting up. 64th char and the following chars are OK. The first 63 chars disappear and 64th char is received like it is the first char received. But the system is all OK after that if you don't mind about this lost data. 


My project is designed for communicating with MODBUS/RTU nodes (RS-485) and I am using Quartus II 64bit v13.1. So it is not possible to waste these 63 chars received in the start-up since it includes data related with a request. 


My question is: Is it possible to modify some code to make fifoed-UART think that it has received 63 chars or something like that ? 


Extra Info: My fifos are 256 Words (with memory elements) for both Tx and Rx, using 4 char periods Rx Timeout, fixed baudrate 9600, using the pin transmitting with MAX485.
0 Kudos
3 Replies
Honored Contributor II

You have tried the latest version of what? Quartus? The latest version is 14.0. And as far as I know, you can modify the code, why not?

Honored Contributor II

I have tried the latest version of fifoed-uart(v13.1) ( and after the problem I experienced about Rx-FIFOs, I installed an earlier version of fifoed-uart (v9.3.1), but still having problems with missing 63 received chars after start-up. I know it is possible to modify the code, I am looking for people that have experienced same problem and may be they have a solution for that. And there seems to be a problem with fifoed-uart under the latest version of Quartus (

Honored Contributor II

I think I have found a solution for my problem, the problem is caused by circular buffers assigned with the following line in the header file fifoed_avalon_uart.h 




* ALT_AVALON_UART_BUF_LEN is the length of the circular buffers used to hold 

* pending transmit and receive data. This value must be a power of two. 






when I changed this value with 2 or 1 I was still missing one char (better than missing 63 chars)... 


since I am not using interrupt functions (instead I am looking to RRDY bit periodically), I have made the following change to the file "fifoed_avalon_uart.c" (I don't have any idea about side effects of this change over uart rcv interrupt !) 



void fifoed_avalon_uart_init (fifoed_avalon_uart_state* sp,alt_u32 irq_controller_id, 

alt_u32 irq) 

void* base = sp->base; 

int error; 



* Initialise the read and write flags and the semaphores used to  

* protect access to the circular buffers when running in a multi-threaded 

* environment. 



error = ALT_FLAG_CREATE (&sp->events, 0) || 

ALT_SEM_CREATE (&sp->read_lock, 1) || 

ALT_SEM_CREATE (&sp->write_lock, 1); 


if (!error) 

/* enable interrupts at the device */ 








/* register the interrupt handler */ 



Now everything is OK with my project, I have no missing received data, but I don't know if the uart interrupt services are still OK...