NVIC, setting priority

lpcware · ‎06-15-2016

Content originally posted in LPCWare by DennisFrie on Tue Dec 30 11:14:09 MST 2014
Hi guys
I'm trying to get my head around the interrupt priorities on LPC15xx.

In its most basic form, I have an interrupt from a timer, and an interrupt triggering on UART receive. The timer interrupt is fairly long and causes a lost char at high baud-rates, if the UART-interrupt is not triggered while in the timer interrupt.

Preferably, I would just set the UART receive interrupt with higher priority, but it doesn't seem to make any difference.

Both UART interrupt and the timer interrupt works as intended (except for the priority).

From my understanding, the interrupt priority can simply be set using the NVIC_SetPriority?

NVIC_SetPriority(SCT3_IRQn, 2); // Low priority on timer
NVIC_SetPriority(UART1_IRQn, 1); // Higher priority on UART

- but it doesn't seem to make any difference. Have I missed something obvious here?

Thanks

lpcware · ‎06-15-2016

Content originally posted in LPCWare by DennisFrie on Thu Jan 01 10:03:38 MST 2015
Thanks a lot
I updated to version 7.5 today and register-view makes a lot more sense now ;-)
That cleared up the issue of actually verifying the register-settings.

I've been testing quite a bit today and have to admit - that the issue was related to another 5 Hz task-routine, that temporarily disabled all interrupts, effectively resulting in a lost char (I know, kinda embarrassing)....

That should do it and everything now seems to be working as intended.

I sure appreciate the help, much appreciated

lpcware · ‎06-15-2016

Content originally posted in LPCWare by R2D2 on Wed Dec 31 13:47:36 MST 2014

Quote: DennisFrie
I'll give the new version of LpcXpresso a try next year - probably tomorrow, if the hangover is acceptable ;-)

Good news for your hangover :D

Your problem is a version 7.2 Peripheral view problem. Version 7.5 is working without problems :)

NVIC view is showing the first byte of the word (IPR), not every byte (IP). So we don't see 3 of 4 bytes...

A workaround in 7.2 is to add an Memory monitor with address 0xe000e400 = IP[0] and change

Format... -> Column size

to 1 (=bytes).

Now you can see how the loop is filling IP[] bytes :bigsmile:

lpcware · ‎06-15-2016

Content originally posted in LPCWare by DennisFrie on Wed Dec 31 06:07:03 MST 2014
OK, thanks a lot for your time and help.
I'll give the new version of LpcXpresso a try next year - probably tomorrow, if the hangover is acceptable ;-)

lpcware · ‎06-15-2016

Content originally posted in LPCWare by R2D2 on Tue Dec 30 16:54:42 MST 2014
I'm not sure what version 7.2 is doing :bigsmile:

Version 7.5 is working correct here (except that Peripheral view is still showing IPR[] instead IP[])...

I would strongly recommend to update (at least to verify your problem)...

lpcware · ‎06-15-2016

Content originally posted in LPCWare by DennisFrie on Tue Dec 30 16:13:08 MST 2014
Changing as expected? Writing 0xFF 4 times to a 32 bit register, I would expect to see 0xFFFFFFFF when done?
If IP[0] = NVIC_IPR0, IP[1] = NVIC_IPR1 etc. I would expect the for-loop with 40 runs, to update more than 10 NVIC_IPRx values.

I'm using LPCxpresso 7.2. I can see quite a few changes have been made since, also some related to NVIC vectors and the viewer.

It would probably be a good idea to upgrade, but as the firmware is used in production, it's a PITA to go through all the firmware verification when upgrading :p

lpcware · ‎06-15-2016

Content originally posted in LPCWare by R2D2 on Tue Dec 30 15:45:42 MST 2014
Sorry, can't follow you

Changing IRQ 19 / 20 / 22 is changing IP[] here as expected :((

And a loop is changing them all to 0xe0...

for(i=0; i<40;i++)
 {
  NVIC->IP = 0xFF;
 }

Which LPCXpresso version are you using?

lpcware · ‎06-15-2016

Content originally posted in LPCWare by DennisFrie on Tue Dec 30 15:18:50 MST 2014
If that's the case, how come NVIC_IPR5 changes, when writing to IP[20]?

Looking at NVIC_IPR19 while writing IP[19] gives the same result, no change.

Running a quick for-loop and changing 40 indexes, only 9 changes. Looks a lot like only the first 8 bits can be written when using the IP access.
[img]https://dl.dropboxusercontent.com/u/3947315/OnlyChangesSome.png[/img]

lpcware · ‎06-15-2016

Content originally posted in LPCWare by R2D2 on Tue Dec 30 15:06:42 MST 2014

Quote: DennisFrie
I feel stupid - but I've no idea what's going on...

You are not showing the correct peripheral view registers :)

While changing SCT3_IRQn / 19 you are not showing IP19 (which is named incorrect IPR19 in Peripheral view)...

lpcware · ‎06-15-2016

Content originally posted in LPCWare by DennisFrie on Tue Dec 30 14:59:32 MST 2014
Yup, what I figured - but using the IP doesn't quite seem to work as expected..

Only writing to certain IP-indexes seems to make a difference.

As an example.
Before seting IP[19]
[img]https://dl.dropboxusercontent.com/u/3947315/Step1.png[/img]

After seting IP[19] - no difference at all
[img]https://dl.dropboxusercontent.com/u/3947315/Step2.png[/img]

After seting IP[20] - value changed..
[img]https://dl.dropboxusercontent.com/u/3947315/Step3.png[/img]

I feel stupid - but I've no idea what's going on...

Only IP[16], IP[20] etc. seems to make a difference - I guess IP[0], IP[4] etc. would work too. hmm

lpcware · ‎06-15-2016

Content originally posted in LPCWare by R2D2 on Tue Dec 30 14:49:08 MST 2014
User manual is describing 32bit IPR registers, LPCOpen is using 8bit IP registers :~ :~

Peripheral view is also showing this 8bit structure...

So if you use:

UART1_IRQn         = 22
SCT3_IRQn          = 19

you should look at bit 5..7 of 8bit IP[19] and IP[22]

Perhaps we'll see additional IRQ names in a future LPCXpresso version

See also: http://www.lpcware.com/content/forum/lpc15-ipr-confusion

lpcware · ‎06-15-2016

Content originally posted in LPCWare by DennisFrie on Tue Dec 30 14:23:05 MST 2014
Looking at the function, it seems to be SCB -> SHP and NVIC -> IP that's used.
SHP is commented as "System hanbdlers priority registers and IP as Interrupt priority register - but IP is saved as an 8 bit value...
__IO uint8_t IP[240]; /*!< Offset: 0x300 (R/W) Interrupt Priority Register (8Bit wide) */

__STATIC_INLINE void NVIC_SetPriority(IRQn_Type IRQn, uint32_t priority)
{
  if(IRQn < 0) {
    SCB->SHP[((uint32_t)(IRQn) & 0xF)-4] = ((priority << (8 - __NVIC_PRIO_BITS)) & 0xff); } /* set Priority for Cortex-M  System Interrupts */
  else {
    NVIC->IP[(uint32_t)(IRQn)] = ((priority << (8 - __NVIC_PRIO_BITS)) & 0xff);    }        /* set Priority for device specific Interrupts  */
}

lpcware · ‎06-15-2016

Content originally posted in LPCWare by DennisFrie on Tue Dec 30 14:02:28 MST 2014
Thanks for pointing out the obvious thing to check first - as it turns out, the bit haven't been set.
[img]https://dl.dropboxusercontent.com/u/3947315/InterruptPriority.png[/img]

Oh well, time to debug...

Thanks

lpcware · ‎06-15-2016

Content originally posted in LPCWare by R2D2 on Tue Dec 30 13:17:27 MST 2014

Quote: DennisFrie
From my understanding, the interrupt priority can simply be set using the NVIC_SetPriority?

Yes :)

Quote: DennisFrie
Have I missed something obvious here?

If debugger is showing your IPR values, no :((

NVIC, setting priority

NVIC, setting priority

lpc15xx