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

[Altera_Forum]

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.

[Altera_Forum]

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]

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]

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]

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.