User Guide Clarification: Cortex-M4F Interrupt Priorities

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

User Guide Clarification: Cortex-M4F Interrupt Priorities

Jump to solution
671 Views
razed11
Contributor V

Hi,

In revision 12 of the user guide 3.9.3.4 it says the following:

On Cortex-M4 and Cortex-A5 core based platforms, the MQX interrupt processing is designed this way. Kinetis K MCUs support 16 hardware interrupt priority levels. Internally MQX maps even levels (0, 2, 4, .., 14) for MQX applications while odd levels (1, 3, .., 15) are used internally. MQX application interrupt levels are 0 to 7, the mapping from MQX application levels 0 to 7 to hardware priority levels (0, 2 to 14) is implemented in the _bsp_int_init() function.

I understand the 16 priority levels for the ISRs. This is independent of MQX. But it then states that maps even levels to MQX applications and that odd levels are used internally. What does this mean? Is this saying that interrupts used by the MQX framework or add-ons use odd and that any that I define should be even?

Why is 0x60 suspiciously absent from the table? All the evens between 0x00 and 0xF0 are there except 0x60. Wondering if this is a typo.

Thanks,

Kenny

Tags (1)
0 Kudos
1 Solution
322 Views
Martin_
NXP Employee
NXP Employee

Hi Kenny, the missing 0x60 is a typo, already fixed in our documents for release. If you are testing this, try to create 8 tasks with priorities 0 to 7, put breakpoints inside them and look on BASEPRI register in debugger.

For the odd priorities, the MQX dispatch process is written in assembler and internally it decreases the BASEPRI by one in certain situations to prevent interrupts of the same priority to become pending. And yes, MQX expects hardware priority of user interrupts will be only even levels. That is why all interrupts shall be installed via _bsp_int_enable() which multiplies the given prio by two.

So there are two important things about interrupt levels:

1) hardware priority only even

2) MQX managed interrupt must not be assigned with a priority higher that MQX_INTERRUPT_HW_LEVEL_MAX. (note the MQX critical section masks only interrupts up to this level, so an interrupt with priority 0 or 1 can be taken during MQX critical section).

This is important to remember when you configure drivers like Processor Expert drivers or Kinetis SDK drivers or any other custom/3rd party.

-Martin

View solution in original post

0 Kudos
1 Reply
323 Views
Martin_
NXP Employee
NXP Employee

Hi Kenny, the missing 0x60 is a typo, already fixed in our documents for release. If you are testing this, try to create 8 tasks with priorities 0 to 7, put breakpoints inside them and look on BASEPRI register in debugger.

For the odd priorities, the MQX dispatch process is written in assembler and internally it decreases the BASEPRI by one in certain situations to prevent interrupts of the same priority to become pending. And yes, MQX expects hardware priority of user interrupts will be only even levels. That is why all interrupts shall be installed via _bsp_int_enable() which multiplies the given prio by two.

So there are two important things about interrupt levels:

1) hardware priority only even

2) MQX managed interrupt must not be assigned with a priority higher that MQX_INTERRUPT_HW_LEVEL_MAX. (note the MQX critical section masks only interrupts up to this level, so an interrupt with priority 0 or 1 can be taken during MQX critical section).

This is important to remember when you configure drivers like Processor Expert drivers or Kinetis SDK drivers or any other custom/3rd party.

-Martin

0 Kudos