Nios® V/II Embedded Design Suite (EDS)
Support for Embedded Development Tools, Processors (SoCs and Nios® V/II processor), Embedded Development Suites (EDSs), Boot and Configuration, Operating Systems, C and C++
12608 Discussions

Code to determine interrupt context?

Altera_Forum
Honored Contributor II
1,104 Views

Is it possible for a re-entrant C function to determine in which interrupt context it is running on a NIOSII processor? i.e. if it can be called from both the idle loop and an interrupt handler, can the code distinguish these cases?

0 Kudos
7 Replies
Altera_Forum
Honored Contributor II
364 Views

Check stack pointer.

0 Kudos
Altera_Forum
Honored Contributor II
364 Views

Only in an operating-system specific manner.

0 Kudos
Altera_Forum
Honored Contributor II
364 Views

So the NIOSII processor doesn't have the equivalent of an "interrupt level" register that it uses to decide whether to accept higher priority interrupts, in the way that many lower end processors have?

0 Kudos
Altera_Forum
Honored Contributor II
364 Views

 

--- Quote Start ---  

So the NIOSII processor doesn't have the equivalent of an "interrupt level" register that it uses to decide whether to accept higher priority interrupts, in the way that many lower end processors have? 

--- Quote End ---  

 

Usually, int is working with interrupt disable. And idle task is working with interrupt enable. But checking stack pointer will be much better solution.
0 Kudos
Altera_Forum
Honored Contributor II
364 Views

Any "interrupt level" register only shows which interrupts are enabled/masked, this will change if software disables interrupts (splfoo(), splx()). However, since writing to the mask register is expensive (it may take 500ns on a 3Ghz x86 cpu!) the OS may not actually mask the interupt, but allow it to happen and then disable it in the interrupt entry code if one actually happens (calling the ISR later when it is unmasked). 

 

The cpu will globally disable interrupts on interrupt entry. but it is quite common for the OS to re-enable them while the ISR runs. The cpu state then doesn't directly contain any information about whether the code is an ISR. 

 

This means you need to use something that the OS does during ISR entry. If the cpu is switched to an interrupt stack, then the range of the stack pointer can be used. If an alternate register set is used, then it may be possible to detect that.
0 Kudos
Altera_Forum
Honored Contributor II
364 Views

Is this what you want to do? 

 

http://www.alteraforum.com/forum/showthread.php?t=21705 

 

Or is it that you want the routine to limit itself when it's in an interrupt context?  

 

You could modify alt_irq_handler.c to set a global to indicate the current context.  

 

Also, ISRs provide the interrupt ID, which tells you what its priority level is.  

 

So you could pass an extra parameter to your routine since, if it's running under an IRQ context, it will have been called from an ISR. 

 

If you're using your own peripherals, another possibility is to modify the logic so that you have a "write a register to generate an IRQ". I did this with my Serial-Tx logic, so that "get next character to transmit from the buffer" would only be called from the ISR.
0 Kudos
Altera_Forum
Honored Contributor II
364 Views

Thanks for all replies. It has pointed me in the right direction.

0 Kudos
Reply