Will the KL17 allow higher priority interrupts to interrupt a lower priority interrupt?

[rickstuart]

Someone here said the KL17 interrupt priority only decides which interrupt is executed first.  That if the KL17 was in the middle of an interrupt the KL17 would disable all other interrupts until the current interrupt returned.  Even higher level interrupts.  Is that true?

-thanks

[egoodii]

There is more than one kind of 'interrupt level' or 'priority'.  The vector-table order defines what happens if more than one interrupt (of the same ARM priority) happen 'at once' -- lower would take precedence.  However, the NVIC implements the IPR Interrupt Priority Registers of ARM priority, which in this incarnation of the ARM architecture has two bits per interrupt for four complete levels of priority.  Higher priority interrupts (those with lower IPR numbers) can interrupt already-executing lower priority interrupt routines.  When an interrupt happens, its priority from IPR is copied to BASEPRI and that defines what higher priority must be presented to re-interrupt.  As related to another of your questions, yes CPSID/E i DOES work with PRIMASK LSB to disable/enable ALL 'configurable priority interrupts', which includes not only all from NVIC but some system interrupts as well, like SYSTICK.  You can read/write PRIMASK, and the CMSIS 'compiler extentions' for direct access are listed in section 3.2 of the M0+ user-guide linked below.

BUT the 'priority level' process allows the user to mask just SOME interrupts by writing to BASEPRI (available only on M3 and M4-core implementations -- sorry, the M0+ core of the KL family does NOT have this):

Base Priority Mask Register

The BASEPRI register defines the minimum priority for exception processing. When BASEPRI

is set to a nonzero value, it prevents the activation of all exceptions with the same or lower

priority level as the BASEPRI value.

I use this, for instance, to prevent execution of critical interrupt handlers only in VERY LIMITED circumstances where there might be a conflict, knowing that other things one might not want to be generally interruptable will tolerate these CRITICAL hits -- in one case FTM-module encoder-rollover-interrupt where I MUST 'very quickly' get a read of the overflow direction to insure proper counter-extension handling.  That I set to the highest priority, and all other sources 'less'.

Most of this 'very basic ARM architecture stuff' is 'minimally documented' in NXP literature -- refer to ARM itself for details -- like:

http://infocenter.arm.com/help/topic/com.arm.doc.ddi0484b/DDI0484B_cortex_m0p_r0p0_trm.pdf

http://infocenter.arm.com/help/topic/com.arm.doc.dui0662b/DUI0662B_cortex_m0p_r0p1_dgug.pdf  but

A particular description of the NVIC is here, albeit specific to the M1 but extensible to this M0+ device:

http://infocenter.arm.com/help/topic/com.arm.doc.dai0211a/DAI0211A_interrupt_behaviour_of_cortexm1.p...