Are the interrupts of the Kinetis K20 preemptive?

[davidgraham]

I am running a K20 72 MHz MCU on a prototype board we that have
developed. I have a UART interrupt and a PORTA GPIO pin interrupt. Both interrupts
are working well but they are Tail-Chaining. The application requires the PORTA
interrupt to preempt the UART interrupt. I have tried many NVICIP register settings
to no avail. Any help or hints greatly appreciated.

Using:

Keil compiler

PE micro Multilink FX debugger

[mjbcswitzerland]

David

The K20 interrupts have 16 possible priorities and any pending interrupt with a higher priority than the one presently executing (as long as global interrupt haven't been disabled) will pre-empt.

Check that you are setting a higher priority (lower value) in the priority register in the NVIC.

Also check that you are setting the priority value correcty:

0x00 is highest priority

0x10

0x20

0x40

..

0xe0

0xf0 is lower priority.

Don't set 0x01..0x0f since these bits are not implemented and will read back 0 - it would mean that all interrupt have the same priority and so no preemption would ever occur (a common mistake of new users).

As comparison for KL parts, with only 4 levels of priority, the values to set are

0x00 - highest priority

0x40

0x80

0xc0 - lower priority

Regards

Mark

Kinetis: http://www.utasker.com/kinetis.html

K20: http://www.utasker.com/kinetis/TWR-K20D72M.html / http://www.utasker.com/kinetis/FRDM-K20D50M.html / http://www.utasker.com/kinetis/TWR-K20D50M.html / http://www.utasker.com/kinetis/TEENSY_3.1.html

For the complete "out-of-the-box" Kinetis experience and faster time to market

[davidgraham]

Hi Mark, thanks for your quick reply. I have read the information provided on the ARM Cortex M4 web site. I have also read through the K20 documentation. In short, set up looks pretty good.

The code below shows I have the priority set up with PORTA being the highest.

Address 0xE000E459 NVICIP61 USB = 0x20

Address 0xE000E43D NVICIP61 UART = 0x20

Address 0xE000E467 NVICIP103 PORTA = 0x00

I confirm this by looking both at the System Watch panel in the PE debugger and a memory watch window. (FIG 1)

FIG 2 shows a scope shot of the operation (hardware pin toggle high when we are in an interrupt)

Yellow UART0 - interrupt routine

Pink PORTA - signal that causes interrupt

Blue PORTA - interrupt routine (for this discussion disregard Blue X pulse … another PORTA interrupt source)

Put simply - we can see that the blue is not preempting the yellow but holding off until the yellow is complete.

Is there something I must do in the interrupt routine of the UART to allow the PORTA interrupt to preempt?

One curious thing came across, in the debugger I could write a value to the NVICIP61 (UART) register and it would take it (say 0x30, 0x40 etc). This is not true for
the NVICIP103 (PORTA). If a value is written such as 0x30 it reads back as 0x00. I don't think this affects anything as I want NVICIP103 to be 0x00.

Again, any ideas would be helpfull. Thanks

[davidgraham]

Hey, I think I found it ... run the numbes on the address 0xE000E43D NVICIP61 UART. If I calculate the Address for the UART IP register I come up with E000-E42D NOT E43D. Checking the math/structure in the MK20D7.h file provided from freescale. I put 0x20 at the E42D address (in the debugger) and it now works!
Something is odd ... just have to find it.

[davidgraham · Accepted solution]

Problem found ... being 0x10 off on the address triggered my brain! USE IRQ# not VECTOR#

So PORTA stauts IP register is NVICIP87 not 103 ... argh!

Working now !

THANKS!