# Interrupt numbers (Vector vs IRQ)

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

## Interrupt numbers (Vector vs IRQ)

Jump to solution
1,505 Views
Contributor II

Hey,

I am working with the MK60N512VMD100.

I have a question about the Interrupt enumerations. In the header, MK60N512VMD100.h I notice that the PIT channels have iterrupt numbers 84, 85, 86 and 87.

/*! Interrupt Number Definitions */
typedef enum {

...

...

INT_PIT0 = 84, /*!< PIT timer channel 0 interrupt */
INT_PIT1 = 85, /*!< PIT timer channel 1 interrupt */
INT_PIT2 = 86, /*!< PIT timer channel 2 interrupt */
INT_PIT3 = 87, /*!< PIT timer channel 3 interrupt */

...

...

Which also correspond to the interrupt vector

static __declspec(vectortable) tVectorTable __vect_table = {

...

...

(tIsrFunc)&isrINT_PIT0, /* 84 (0x00000150) (prior: 0) */
(tIsrFunc)&isrINT_PIT1, /* 85 (0x00000154) (prior: 0) */
(tIsrFunc)&isrINT_PIT2, /* 86 (0x00000158) (prior: 0) */
(tIsrFunc)&isrINT_PIT3, /* 87 (0x0000015C) (prior: 0) */

...

However, the "numbers" used to set the interrupt priorites are different. (Here I used the help tool in Code Warrior (Device Init.)

/* Common initialization of the CPU registers */
/* NVICIP68: PRI68=0 */
NVICIP68 = (uint8_t)0x00U;
/* NVICIP69: PRI69=0 */
NVICIP69 = (uint8_t)0x00U;
/* NVICIP70: PRI70=0 */
NVICIP70 = (uint8_t)0x00U;
/* NVICIP71: PRI71=0 */
NVICIP71 = (uint8_t)0x00U;

It might be that I am missing something obvious here. But how does 68, 69, 70 and 71 correspond to  84, 85, 86 and 87. To me it seems like there is a 16 number offset.

Grateful for any help,

1 Solution
971 Views
Contributor II

After checking the manual it seems there is an offset between the Vector and the IRQ that stems from the seperation between ARM core system handels and the non-core system handlers. This correspond exacly to my problem.

Attached for clearification.

1 Reply
972 Views
Contributor II

After checking the manual it seems there is an offset between the Vector and the IRQ that stems from the seperation between ARM core system handels and the non-core system handlers. This correspond exacly to my problem.

Attached for clearification.