Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
12 years ago

FIFOed Avalon Uart reprise

Currently working with Quartus 9.1 and will later move to latest.

Need a Uart with FIFOs and found this:

http://www.alterawiki.com/wiki/fifoed_avalon_uart

Grabbed this from the above link:

Got a basic tx working in no time simply writing the tx reg at offset 1 with test byte 0xA1 as here:

IOWR(FIFOED_AVALON_UART_0_BASE, 1, 0xA1);

Installed a loopback to the receive and then writing same data and looking then for it to

be in the receive buffers. 6 is the offset for "uartrxfifoused" which should be number of chars

in receive FIFO.

read_val = IORD(FIFOED_AVALON_UART_0_BASE, 6);

...however read_val is always 0.

I also looked at the status reg and bit 7 (RRDY=receive character ready) is also always 0.

The status reg is sometimes 0x60 and sometimes 0x40 but bit 7 is always 0.

I saw this particular question in a past post and it never got an answer.

Seems there were quite a few issues folks were having so perhaps this module is not recommended.

From the defaults, in SOPC, I change only the baud to 9600 and include rx and tx buffers both 256 deep.

Thanks, all.

Cos

5 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    12 years ago

    FYI...Update...

    I have tried everything I can think of and will have to abandon this module

    if I cannot find a resolution to this (supposedly) simple issue of receiving data.

    Any and all suggests welcome.

    Thanks,

    Cos
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    12 years ago

    No replies.

    Looks like I am going to have to code up my own - should not take too long.

    It looks like the code was done by a student by some of the earlier posts so I guess I should not

    have spent any time on this.

    Live and learn.

    Cos
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    12 years ago

    Hi

    Ever get the FIFOED UART to work. I am in need of a UART for a NIOS 13.0sp1 design. It seems that the Avalon UART in Qsys can be hooked to DMA and this will allow for streaming and flow control as well as offload the NIOS processor. I am just getting started after looking at the FIFOED UART and not being about to port the IP to Qsys.

    Any comments or insight would be appreciated.

    Thanks.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    11 years ago

    I am experiencing the same problems (zero in rx fifo) I think I have found an error in one of the pm files named: "em_fifoed_uart_qsys.pm", I think this typing error is causing receive fifos to be disabled even if you enable them...

    ...# 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.

    Thanks for any help...
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    10 years ago

    Hi,

    I know, it's probably to late to answer this question, but maybe somebody else who is working with this UART will face the same problem.

    I myself try to work with this UART for two days now and had the same problem that the initial poster is mentioning. No RX data in the RX FIFO.

    However, I figured out, that after exactly 64 rx words, I suddenly get some data. I tried to hunt the cause down with signal tap and found out, that there were read accesses to the rx fifo immediately after a byte has been received. Before that, there were staus reads.

    Now, since I did not do these reads in my user code, I suspected the IRQ routine of the driver to be the root cause for this.

    Indeed, after I disabled the IRQ for the component (by switching to small drivers in the BSP editor), I was able to receive all data in polling mode which is exactly what I need anyway.

    Hope this peace of information helps somebody (and hopefully, somebody will be able to help me on my upcoming post regarding this component :cool:)

    Regards,

    Maik