# Nested Interrupts, enable state after context switch **URL:** \ **Category:** Kernel\ **Created:** [September 23, 2020, 8:28am UTC](https://forums.freertos.org/t/nested-interrupts-enable-state-after-context-switch/10749 "2020-09-23T08:28:30Z")\ **Posts on this page:** 18\ **Page:** 1
**Author:** ![ripperle](https://avatars.discourse-cdn.com/v4/letter/r/47e85d/32.png) [@ripperle](https://forums.freertos.org/u/ripperle)\ **Post date:** [September 23, 2020, 8:28am UTC](https://forums.freertos.org/t/nested-interrupts-enable-state-after-context-switch/10749/1 "2020-09-23T08:28:30Z")
Hello, i implement a port for the intel (aka altera) nios 2 processor and have a question regarding nested interrupst ( configMAX\_SYSCALL\_INTERRUPT\_PRIORITY): Inside the context switch i have to disable (and re-enable) interrupts below (or even) the configMAX\_SYSCALL\_INTERRUPT\_PRIORITY. Therefore I store the ISR enable state of each interrupt on the stack (form “INT\_ENABLE” register) and disable all ISRs below (or even) configMAX\_SYSCALL\_INTERRUPT\_PRIORITY. When I restore the next context, I read the saved enable state from stack, and write it back to the “INT\_ENABLE” register… This means, that when I enable a interrupt from a task (after the schedular is startet), this interrupt will be disabled, when a context switch occures to another task… Is this the correct behavior (how it should be)?! So if i want an interrupt to be enabled at all time, i have to enable it, before starting the scheduler?! Can somebody help me to understand, what the enable status of each interrupt should be after a context switch?! Regards, Andy ---
**Author:** ![rtel](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/rtel/32/31_2.png) [@rtel](https://forums.freertos.org/u/rtel)\ **Post date:** [September 23, 2020, 2:15pm UTC](https://forums.freertos.org/t/nested-interrupts-enable-state-after-context-switch/10749/2 "2020-09-23T14:15:09Z")
The enable state is part of the task context so should be restored to whatever it was when it was saved. Are you using our official (if rather old) port? Sounds like you are writing your own. ---
**Author:** ![ripperle](https://avatars.discourse-cdn.com/v4/letter/r/47e85d/32.png) [@ripperle](https://forums.freertos.org/u/ripperle)\ **Post date:** [September 24, 2020, 5:48am UTC](https://forums.freertos.org/t/nested-interrupts-enable-state-after-context-switch/10749/3 "2020-09-24T05:48:20Z")
Yes i wrote a port for the NIOS processor with vectored interrupt controller last year ([LINK](https://forums.freertos.org/t/nios-ii-vic-for-interrupts/7743/6))… There were some issues with it, and now i try to fix it… The first thing was the bad nested interrupt implementation 🙄 Now i think it works like expected… The IRQ state will be restored in every task. I think i also fixed the “portDisable” and “portEnable” Interrupts implementiation, by saving the last enable state (for every task) on the stack (while context is swtiched) und write this state to the ISR\_ENABLE register, as soon “portEnable” will be called… Nesting should also work because of the use of the “vTaskEnterCritical” and “vTaskExitCritical” implementation… Thank you for your help! Andy ---
**Author:** ![ripperle](https://avatars.discourse-cdn.com/v4/letter/r/47e85d/32.png) [@ripperle](https://forums.freertos.org/u/ripperle)\ **Post date:** [October 12, 2020, 1:42pm UTC](https://forums.freertos.org/t/nested-interrupts-enable-state-after-context-switch/10749/4 "2020-10-12T13:42:47Z")
Hello, i also implemented the portSET\_INTERRUPT\_MASK\_FROM\_ISR and portCLEAR\_INTERRUPT\_MASK\_FROM\_ISR makros… Can somebody tell me the diffrence to the portDISABLE\_INTERRUPTS and portENABLE\_INTERRUPTS implementation?! Both makros should disable and (re)enable all interrupts below or equal to configMAX\_SYSCALL\_INTERRUPT\_PRIORITY?! Regards, Andy ---
**Author:** ![jefftenney](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/jefftenney/32/1314_2.png) [@jefftenney](https://forums.freertos.org/u/jefftenney)\ **Post date:** [October 12, 2020, 4:13pm UTC](https://forums.freertos.org/t/nested-interrupts-enable-state-after-context-switch/10749/5 "2020-10-12T16:13:57Z")
The `FROM_ISR` versions allow the caller to save/restore the previous interrupt mask. That’s important in an ISR because you don’t want to enable interrupt priorities lower than the ISR you’re currently executing. > [@ripperle](#): > > Both makros should disable and (re)enable all interrupts below or equal to configMAX\_SYSCALL\_INTERRUPT\_PRIORITY?! No, `portCLEAR_INTERRUPT_MASK_FROM_ISR()` doesn’t enable _all_ interrupts below `configMAX_SYSCALL_INTERRUPT_PRIORITY`. It enables only those above the parameter passed to it. As noted above, the purpose of that parameter is to let the caller restore the original interrupt mask level. ---
**Author:** ![ripperle](https://avatars.discourse-cdn.com/v4/letter/r/47e85d/32.png) [@ripperle](https://forums.freertos.org/u/ripperle)\ **Post date:** [October 14, 2020, 4:23am UTC](https://forums.freertos.org/t/nested-interrupts-enable-state-after-context-switch/10749/6 "2020-10-14T04:23:32Z")
Thanks for the quick response! > That’s important in an ISR because you don’t want to enable interrupt priorities lower than the ISR you’re currently executing. Why I dont want to enable interrupts below the current executing? ---
**Author:** ![jefftenney](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/jefftenney/32/1314_2.png) [@jefftenney](https://forums.freertos.org/u/jefftenney)\ **Post date:** [October 14, 2020, 1:40pm UTC](https://forums.freertos.org/t/nested-interrupts-enable-state-after-context-switch/10749/7 "2020-10-14T13:40:08Z")
> [@ripperle](#): > > Why I dont want to enable interrupts below the current executing? There are a few reasons. Consider a task running inside a critical section that masks interrupts up to priority 3. Then consider an interrupt with priority 4 that interrupts the task’s critical section. Let’s say the ISR masks all interrupts for its own critical section. When the ISR’s critical section ends, it should restore the mask to level 4, not all the way down to level 0. If it restores the mask down to 0, it will break the task’s critical section. Another reason is simply priority. The developer decides interrupt priority to make sure a higher priority ISR gets to finish its work before any lower-priority ISR can execute. Another reason is ISR reentrancy. One some architectures, a peripheral can request a new interrupt in the middle of its own ISR. If the ISR has lowered the interrupt mask, you could have an ISR execute reentrantly. Most developers don’t write ISRs to be reentrant. Some architectures (Cortex M for example) actually enforce this principle in hardware. No matter how the software sets the interrupt mask, the hardware simply won’t allow lower priority interrupts than the one currently being serviced. ---
**Author:** ![ripperle](https://avatars.discourse-cdn.com/v4/letter/r/47e85d/32.png) [@ripperle](https://forums.freertos.org/u/ripperle)\ **Post date:** [October 15, 2020, 6:55am UTC](https://forums.freertos.org/t/nested-interrupts-enable-state-after-context-switch/10749/8 "2020-10-15T06:55:43Z")
Thanks again for your explanation! 1.) > [@jefftenney](#): > > Another reason is simply priority. The developer decides interrupt priority to make sure a higher priority ISR gets to finish its work before any lower-priority ISR can execute. > > Another reason is ISR reentrancy. One some architectures, a peripheral can request a new interrupt in the middle of its own ISR. If the ISR has lowered the interrupt mask, you could have an ISR execute reentrantly. Most developers don’t write ISRs to be reentrant. > > Some architectures (Cortex M for example) actually enforce this principle in hardware. No matter how the software sets the interrupt mask, the hardware simply won’t allow lower priority interrupts than the one currently being serviced. These topics are already handle through hardware. I use the NIOS2 processor for Intel (aka Altera) FPGAs with external interrupt controller (EIC) with shadow register sets. So in my configuration, every interrupt has its own unique priority and register set. Higher IRQ will preempt lower IRQ. Reentrance is not allowed inside the same register set, unless you dont explicitly re-enable the RSIE flag (which will be cleared by hardware, when interrupt is taken). ![2020-10-15_08-09-32](https://d2v6vdsk2p900z.cloudfront.net/original/1X/892c465286bf49fb87999fe89db016daaf392c53.png) I dont use non maskable interrupts (RNMI). 2.) > [@jefftenney](#): > > There are a few reasons. Consider a task running inside a critical section that masks interrupts up to priority 3. Then consider an interrupt with priority 4 that interrupts the task’s critical section. Let’s say the ISR masks all interrupts for its own critical section. When the ISR’s critical section ends, it should restore the mask to level 4, not all the way down to level 0. If it restores the mask down to 0, it will break the task’s critical section. Ok i think i missunderstood, how to implement the portDISABLE\_INTERRUPTS and portSET\_INTERRUPT\_MASK\_FROM\_ISR if i want to implement nesting. What i am doing at the moment is: 1.) Context Switch (SysTick, lowest ISR prio): At the beginning i use the CPU IL (interrupt field) to disable all ISRs below or equal configMAX\_SYSCALL\_INTERRUPT\_PRIORITY. Then i set PIE (interrupt enable flag) to allow higher interrupts (above configMAX\_SYSCALL\_INTERRUPT\_PRIORITY) to execute. after contxt switch and restoring registers, i set IL field again to 0 (enable all interrupts). 2.) portDISABLE\_INTERRUPTS(): disables all irqs below or equal configMAX\_SYSCALL\_INTERRUPT\_PRIORITY with IL fiel (set to configMAX\_SYSCALL\_INTERRUPT\_PRIORITY) portENABLE\_INTERRUPTS(): enables all irqs with IL field (set to 0) 3.) portSET\_INTERRUPT\_MASK\_FROM\_ISR(): Store the interrupt enable register (INT\_ENABLE) from the external interrupt controler. Then disable all ISR below or equal configMAX\_SYSCALL\_INTERRUPT\_PRIORITY by clearing the corresponding bits inside INT\_ENABLE register. portCLEAR\_INTERRUPT\_MASK\_FROM\_ISR(): restore the INT\_ENABLE register with “uxSavedInterruptStatus” parameter. I think with this implementation I dont support real nesting (is this correct?!) So if this is true, there are some new question 🙂 1.) I am correct in assuming that it is correct to disable all interrupt below or equal configMAX\_SYSCALL\_INTERRUPT\_PRIORITY for context switching (e.g. SysTick handler or yield) 2.) > [@jefftenney](#): > > …Consider a task running inside a critical section that masks interrupts up to priority 3. Then consider an interrupt with priority 4 that interrupts the task’s critical section… This wouldnt happen in the actual implementation (what is not correct). If the system behaves like you said, then what happens if th ISR with prio 4 calls a FreeRTOS API funktion (like xQueueSendFromISR ) which unblocks the interrupted task with prio 3?! Is it allowed to use a API in higher ISRs which potentially interrupted a critical section of a lower task? Again thank you very much for your support! Regards, Andy ---
**Author:** ![jefftenney](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/jefftenney/32/1314_2.png) [@jefftenney](https://forums.freertos.org/u/jefftenney)\ **Post date:** [October 15, 2020, 4:04pm UTC](https://forums.freertos.org/t/nested-interrupts-enable-state-after-context-switch/10749/9 "2020-10-15T16:04:01Z")
> [@ripperle](#): > > What i am doing at the moment is: This list looks good until #3. Why not use IL? That would be simpler and faster, right? Then `portSET_INTERRUPT_MASK_FROM_ISR()` would set IL to `configMAX_SYSCALL_INTERRUPT_PRIORITY` and return the previous IL value. And `portCLEAR_INTERRUPT_MASK_FROM_ISR(x)` would set IL to `x`. The key difference between `portENABLE_INTERRUPTS()` and `portCLEAR_INTERRUPT_MASK_FROM_ISR(x)` is that the former can simply set IL to zero, but the latter must set IL to `x`. > [@ripperle](#): > > Is it allowed to use a API in higher ISRs which potentially interrupted a critical section of a lower task? No. You are correct. In my example the interrupt at priority 4 is not allowed to call FreeRTOS API functions. So you’re right – that kind of ISR wouldn’t call `portSET_INTERRUPT_MASK_FROM_ISR()` or `portCLEAR_INTERRUPT_MASK_FROM_ISR()` at all. That was bad example. 😉 ---
**Author:** ![richard-damon](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/richard-damon/32/38_2.png) [@richard-damon](https://forums.freertos.org/u/richard-damon)\ **Post date:** [October 16, 2020, 3:45pm UTC](https://forums.freertos.org/t/nested-interrupts-enable-state-after-context-switch/10749/10 "2020-10-16T15:45:47Z")
One other thing to realize is that the architecture in FreeRTOS needs to support all (or at least most) processors. So just because a give processor might not need to save the information, doesn’t mean the API can skip it. There are a few cases where we know that it doesn’t need to be saved, so the kernel code uses things in a slightly ‘non-standard’ way (with documented reasons for doing so), if you know that you never need to return to the previous state, but can always just re-enable all and the hardware will still work right, you could do the same (just be REAL sure you are right or you will get a hard to find problem). ---
**Author:** ![ripperle](https://avatars.discourse-cdn.com/v4/letter/r/47e85d/32.png) [@ripperle](https://forums.freertos.org/u/ripperle)\ **Post date:** [October 19, 2020, 11:16am UTC](https://forums.freertos.org/t/nested-interrupts-enable-state-after-context-switch/10749/11 "2020-10-19T11:16:05Z")
Thanks for answers! Just to make sure i got it right: The goal from both portFunctions (portDISABLE\_INTERRUPTS and portSET\_INTERRUPT\_MASK\_FROM\_ISR) is to disable all IRQs below or equal configMAX\_SYSCALL\_INTERRUPT\_PRIORITY ?! The portFunction portENABLE\_INTERRUPTS should enable ALL IRQs. The portFunction portCLEAR\_INTERRUPT\_MASK\_FROM\_ISR should ONLY enable these IRQs which were enabled, when portSET\_INTERRUPT\_MASK\_FROM\_ISR were called? In which scenario the function portSET\_INTERRUPT\_MASK\_FROM\_ISR find a IRQ state with only some IRQs disabled? I am testing my port at the moment with the demo application tasks and already noticed a problem: In the GenQTest task (prvHighPriorityMutexTask) the firmware hang up at list.c line 150. The command above tells me already this: > /\* \*\*\* NOTE \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\* > If you find your application is crashing here then likely causes are > listed below. In addition see [FreeRTOS - Open Source RTOS Kernel for small embedded systems](https://www.freertos.org/FAQHelp.html) for > more tips, and ensure configASSERT() is defined! > [FreeRTOS - The Free RTOS configuration constants and configuration options - FREE Open Source RTOS for small real time embedded systems](https://www.freertos.org/a00110.html#configASSERT) > > ``` > 1) Stack overflow - > see https://www.freertos.org/Stacks-and-stack-overflow-checking.html > 2) Incorrect interrupt priority assignment, especially on Cortex-M > parts where numerically high priority values denote low actual > interrupt priorities, which can seem counter intuitive. See > https://www.freertos.org/RTOS-Cortex-M3-M4.html and the definition > of configMAX_SYSCALL_INTERRUPT_PRIORITY on > https://www.freertos.org/a00110.html > 3) Calling an API function from within a critical section or when > the scheduler is suspended, or calling an API function that does > not end in "FromISR" from an interrupt. > 4) Using a queue or semaphore before it has been initialised or > before the scheduler has been started (are interrupts firing > before vTaskStartScheduler() has been called?). > ********************************************************************** / > > ``` So stack shouldn’t be the problem, i think the problem belongs to the nesting IRQ implementation… Regards, Andy ---
**Author:** ![jefftenney](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/jefftenney/32/1314_2.png) [@jefftenney](https://forums.freertos.org/u/jefftenney)\ **Post date:** [October 19, 2020, 1:27pm UTC](https://forums.freertos.org/t/nested-interrupts-enable-state-after-context-switch/10749/12 "2020-10-19T13:27:04Z")
> [@ripperle](#): > > Just to make sure i got it right: All of this looks good as long as enabling/disabling interrupts is done only in STATUS.IL. > [@ripperle](#): > > In which scenario the function portSET\_INTERRUPT\_MASK\_FROM\_ISR find a IRQ state with only some IRQs disabled? The most likely scenario is when critical sections nest. For example, an ISR creates a critical section and then calls a function from within that critical section. Then that function creates “another” critical section. ---
**Author:** ![richard-damon](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/richard-damon/32/38_2.png) [@richard-damon](https://forums.freertos.org/u/richard-damon)\ **Post date:** [October 19, 2020, 1:30pm UTC](https://forums.freertos.org/t/nested-interrupts-enable-state-after-context-switch/10749/13 "2020-10-19T13:30:21Z")
For some/many processors that allow nested interrupts, that nesting is controlled by the interrupt mask. When you get a level N interrupt, the system, as part of responding to the interrupt, saves on the stack the current interrupt mask, and the masks off interrupts of level N or lower. Thus inside the ISR, for such a machine, the mask will always have some levels masked. Other processors keep the current level elsewhere, so nesting doesn’t need to affect the mask level. On this sort of processor, it is much less likely to have some levels masked. Since FreeRTOS is designed to work on all sorts of processors, some things that are standardized, the protocols are designed to handle the most general case, thus saving and restoring the mask, even if for a given machine it isn’t needed. ---
**Author:** ![ripperle](https://avatars.discourse-cdn.com/v4/letter/r/47e85d/32.png) [@ripperle](https://forums.freertos.org/u/ripperle)\ **Post date:** [October 20, 2020, 5:57am UTC](https://forums.freertos.org/t/nested-interrupts-enable-state-after-context-switch/10749/14 "2020-10-20T05:57:08Z")
Ok, got it 🤓 Any suggestens for debugging the above descripted Problem? I reduced the demo applications, so only - vStartLEDFlashTasks (flash.c) - vStartQueuePeekTasks (QPeek.c) - vStartGenericQueueTasks (GenQTest.c) - 2 Tasks which writes and checks the registers are running. After a few senconds (or minutes) the Firmware freezes at (example call stack) - list.c (line 151) - task.c (line 3031) - queue.c (line 1741) - qpeek.c (line 172, “prvHighestPriorityPeekTask”) FreeRTOS Kernel V10.2.1 The demo tests dont use IRQs so far, so the problem must be somewhere else 🧐 Regards, Andy ---
**Author:** ![ripperle](https://avatars.discourse-cdn.com/v4/letter/r/47e85d/32.png) [@ripperle](https://forums.freertos.org/u/ripperle)\ **Post date:** [October 23, 2020, 6:38am UTC](https://forums.freertos.org/t/nested-interrupts-enable-state-after-context-switch/10749/15 "2020-10-23T06:38:28Z")
Ok found the error ( it was a typo, i used the define “NIOS2\_STATUS\_IH\_OFST” instead of “NIOS2\_STATUS\_IL\_OFST” 😒 🙄) Now I successfully run these demo apps (including 2 timer interrupts for the IntQueue example): ``` vStartLEDFlashTasks( mainLED_TASK_PRIORITY ); vStartIntegerMathTasks( mainGENERIC_QUEUE_PRIORITY ); vStartGenericQueueTasks( mainGENERIC_QUEUE_PRIORITY ); vStartBlockingQueueTasks( mainQUEUE_BLOCK_PRIORITY ); vStartPolledQueueTasks( mainQUEUE_POLL_PRIORITY ); vStartQueuePeekTasks(); vCreateBlockTimeTasks(); vStartSemaphoreTasks( mainSEMAPHORE_TASK_PRIORITY ); vStartCountingSemaphoreTasks(); vStartRecursiveMutexTasks(); vStartInterruptQueueTasks(); /* prvCheckTask uses sprintf so requires more stack. */ xTaskCreate( prvCheckTask, "Check", configMINIMAL_STACK_SIZE, NULL, mainCHECK_TASK_PRIORITY, NULL ); /* The RegTest tasks as described at the top of this file. */ configASSERT( xTaskCreate( prvFirstRegTestTask, "Rreg1", configMINIMAL_STACK_SIZE, mainREG_TEST_1_PARAMETER, mainREG_TEST_PRIORITY, NULL ) ); configASSERT( xTaskCreate( prvSecondRegTestTask, "Rreg2", configMINIMAL_STACK_SIZE, mainREG_TEST_2_PARAMETER, mainREG_TEST_PRIORITY, NULL ) ); /* This task has to be created last as it keeps account of the number of tasks it expects to see running. */ vCreateSuicidalTasks( mainCREATOR_TASK_PRIORITY ); /* Finally start the scheduler. */ vTaskStartScheduler(); ``` Regards, Andy ---
**Author:** ![jefftenney](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/jefftenney/32/1314_2.png) [@jefftenney](https://forums.freertos.org/u/jefftenney)\ **Post date:** [October 23, 2020, 4:52pm UTC](https://forums.freertos.org/t/nested-interrupts-enable-state-after-context-switch/10749/16 "2020-10-23T16:52:12Z")
Andy, Glad you got it working! Out of curiosity, did you start from the official NIOS 2 port? Or did you write your port from scratch? Either way it could be helpful to other users if you upload your port in this thread. ---
**Author:** ![ripperle](https://avatars.discourse-cdn.com/v4/letter/r/47e85d/32.png) [@ripperle](https://forums.freertos.org/u/ripperle)\ **Post date:** [October 26, 2020, 6:52am UTC](https://forums.freertos.org/t/nested-interrupts-enable-state-after-context-switch/10749/17 "2020-10-26T06:52:22Z")
The “official NIOS 2” only support the internal interrupt controller (only 1 ISR funnel, no nesting, priorisation, no shadow register etc possible) I copied this port to a new folder “NiosII\_EIC” and implemented the necessary changes… I will prepare and upload the files here… Regards Andy ---
**Author:** ![ripperle](https://avatars.discourse-cdn.com/v4/letter/r/47e85d/32.png) [@ripperle](https://forums.freertos.org/u/ripperle)\ **Post date:** [November 6, 2020, 6:15am UTC](https://forums.freertos.org/t/nested-interrupts-enable-state-after-context-switch/10749/18 "2020-11-06T06:15:34Z")
See here… > [@Nios II VIC for interrupts](https://forums.freertos.org/t/nios-ii-vic-for-interrupts/7743): > > [mark1122](https://sourceforge.net/u/mark1122/) wrote on [Wednesday, March 20, 2019](https://sourceforge.net/p/freertos/discussion/382005/thread/d58424cad9/#2419): Hi, the current freeRTOS only supports IIC for NiosII. VIC is about 4x faster. I have over 10 interrupts in my design and I really need the VIC for performance. I saw the feature request #115 created 1 year and 9 months ago. Could someone give me a hint on how to implement it? I am sure someone has done it. My understanding of IIC is that all interrupts(hardware + softare) go through the exception vector(usually address 0x20 or anything defined in Q…