Forum Discussion

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

Adding a vectored interrupt controller has caused the UART module to stop responding

First, I have a system that is made up of a Nios II/e CPU, JTAG debugger UART, interval timer (sys_clk_timer) and a separate UART module that is used for RS232 serial communication, ect. The system with these components work, and I have the ability to use the UART and assign a Tx and Rx pin on my DE0-nano development board and send serial data in/out.

Now, in an attempt to create a timed interrupt task, I added a Vectored Interrupt Controller (VIC), switched my Nios II/e to a Nios II/f.

Building the project and running the existing code shows that any Tx and Rx data sent to the UART module has no effect. Note: at this point i have not created a interrupt task so I know for sure that the Tx/Rx from the UART that runs in the background is not being effected by the interrupt task. I have also run this in debug mode and seen that the code is being executed.

The system seems to behave exactly the same as before, only, the data sent to the UART is not working. why?

when I create a 1 second interrupt task, the task is working and UART code is still being executed in the background but has no effect.

4 Replies

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

    I just ran in debug mode and set a breakpoint at a location where i send transmit data, sending the character one at a time by pressing the run button and having it break before sending another character shows that the component is working properly. I think the problem might have something to do with the UART component being connected to the VIC, and the interval timers also being connected to the VIC. I'm guessing the sys_clk_timer period is not correct, can anyone comment on how to determine what to set the sys_clk_timer period to?

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

    after two days of debugging...I have solved the problem by using a function usleep(delay_us_number); before writing to the transmit data register and changing from direct register access in firmware to instead use HAL library functions like IOWR_ALTERA_AVALON_UART_TXDATA(UART_BASE,myChar); etc...

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

    That seems like an avoidance, not a fix.

    If your old code was just writing to the uart tx register/fifo then it probably wasn't using any interrupts at all. It might have just relied on the code being slow enough to never fill the uart fifo (does it even have a fifo?).

    You should check for space in the fifo before writing data bytes.

    I've not looked at how that uart works, but at a guess you need to enable the 'tx space' interrupt when there isn't enough room for the byte being sent and disable it again (in the ISR) when the ISR has emptied the software transmit fifo.

    This does all mean that you might just as well allocate the memory to a hardware fifo instead of a software one - after all the code has to

    allow for any software fifo being full as well, and the code to handle a hardware tx fifo will be simpler.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    12 years ago

    The altera UART component should de-assert the transmit ready signal (7th bit in the status register) if the FIFO is full, but the signal never turns off.

    I originally had it set where I created a pointer to the UART:

    while(!pUART->Status.sBits.trrdy); //wait for transmit ready

    pUART->TxDATA = myChar; //then transmit data

    maybe this is why Altera recommends to use the HAL library functions instead of direct access.