- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Using Nios(3.2), Nios32@30mhz with some user logic modules in the C4. The simplest possible ISR will works a random number of times (< 30) and then stop working. The IRQ signal from the user logic is still low, but the ISR stops getting called just as if the IRQ is being masked in the Nios core. I have stripped down the ISR to just:
int main(void) { .... nr_installuserisr(na_myisr_irq, myISR, 0); count = 0; nr_setirqenable(1); .... } //ISR static int count; void myISR(int context) { printf("count %d\r", ++count); return; } This code should execute indefinitely, yet it locks after a random number of times. I have added sw delays in both the main routine and the ISR, but it does not fix the lockup. Using a push button or a signal generator as an interrupt source, I can see that the rate of interrupts makes no difference either. The non-deterministic nature of the problem suggests timing/floating input type behavior, yet the timing report says all constraints are met by wide margins. Altera support say they have verified the problem, and are are looking into the cause. If this really is a generic Nios problem, I can't be the first person to run into it. Anyone else see this?Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This is because printf uses the timer irq and because your isr never clears it's irq's bit. Every time your irq returns the isr manager is going to service the next irq which is just a big switch statement, so your irq can and will lock up everything else.
If you really don't want to service your irq then you can change the priority of the timer irq and avoid this problem in most cases, but I fully recommend servicing your irqs.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
My example was stripped down to isolate the behavior. My real code does clear the interrupt condition inside the ISR, and it does exhibit the masking behavior whether I use printf or not.
I thought that the system ISRs (spurious, CWP overflow, etc) all used high priority IRQ#s below 16. All my user ISR#s are above these and above the uart IRQ#s, and so should not be blocked. Do you mean that I have to do a nr_setirqenable(1); inside my user ISR to allow even higher priority ISRs? Where do I look to see the IRQ# for this timer? Thanks- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- Quote Start --- originally posted by tns1@Jul 16 2004, 06:11 PM where do i look to see the irq# for this timer? --- Quote End --- It should be in the SOPC builder window as well as the "excalibur.h" or "system.h" file that SOPC Builder generates.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
(Another duplicate. Too bad this forum doesn't have a delete-post option.)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
No timer at all in SOPC 'system contents' or in excalibur.h. If its there, it looks like it is not accessible from the GUI. Are we talking about a baud rate reload timer? I do see that each of my 4 serial ports has an IRQ#. Since these are all of higher priority than the ISR I am testing, changing their priority wouldn't fix anything. On the other hand, if I misunderstood and need to explicitly reenable interrupts inside my ISR for any ISR to work, then that explains why it would lock, it just does not explain why it locks only after a seemingly random# of interations.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I'm also encountering this issue and don't know where to continue. Been working with Nios II economy over the summer to advance my FPGA SoC skills for University, but am stumped by this bug.
The biggest issue is that the system refuses to lock up in debug mode or while connected to console, so I feel like I'm solving this blind.
Around 30s the system seems to lock.
After 30s it will lock instantly if I disconnect the debugger or console.
Is this intentional from Intel?(I don't have a license beyond installing Quartus 18.1 lite and using Nios ii economy)
Being only available while connected to the console is fine for learning.
Any information would help.
***********This is not a graded assignment or for production*************
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Did you ever find the solution to this problem? I have a very similar problem where the irq works fine in console after running as hardware but runs into problems when I stop or if I flash the .elf with the .sof
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I was actually able to solve my problem. I was using the printf() function inside of my code which is controlled by the JTAG connection, so as soon I unplugged the connection my code would break because the STDIO library couldn't be used without JTAG. After changing my code around to just toggle an output pin and scoping it, it never broke even with the interrupts.

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page