Nios II uart with alt_irq_register

We probably need a little more information to give a specific answer. For example, are you running with or without uC/OS? What is the state when you tried to print. Is it from a task or is before OSStart()?

My first reaction is that the printf was called from a uC/OS design before tasking and the buffer of tx characters was hit. When that happens the printf pends waiting for the buffer to empty out and the ISR takes over. However, since no task exists it doesn't actually return correctly. I have seen this with my designs. I now only do initialization from a "start" task that then starts the rest of the tasks.

If you are not using uC/OS I am not sure what the problem could be.

Regards,

--- Quote Start ---

originally posted by etienne@May 18 2005, 09:14 AM

when i register my isr with alt_irq_register, it correctly works when an incomming

character is appear in the nios.

when i use functions (as fwrite, fprintf...) to out one or some caracters, the isr

execute itself and execute never return to the main program

--- Quote End ---

According to page 6-7 of the sofware developer's handbook you have to be carful calling ANSI C commands in an ISR. If the device you have the stdout mapped to requires another interrupt your system will become deadlocked. maybe you want to try putting the alt_irq_interruptible() and alt_irq_non_interruptible() calls around the code that needs the interrupt? Just a though.

-Jon

<div class='quotetop'>QUOTE </div>

--- Quote Start ---

I must use the UART in interrrupt mode for Rx functions.

When I register my ISR with alt_irq_register, it correctly works when an incomming

character is appear in the NIOS.

When I use functions (as fwrite, fprintf...) to out one or some caracters, the ISR

execute itself and execute never return to the main program :[/b]

--- Quote End ---

If I had to hazard a guess I would say that your problem is likely to be that you already have a driver in your system talking to the UART and you are subsequently trying to handle the interrupt from the UART. Why not just use the supplied driver?