IRQs on Nano and 54415

[Ridgeglider]

I have IRQs working for Nano/54415 timers, Edgeport, ADC, PWM, PIT etc based on the examples, but still trying to understand some basics.

For example, I notice that SetIntC() looks a bit different on the 54415-based platforms:
void SetIntc( int intc, long func, int vector, int level );

On the other platforms SetintC() includes a priority setting for a given IRQ. On the Nano, the priority parameter is gone, but there's also new interrupt_controller_number parameter.

Does the lack of a priority setting mean that if two IRQs are configured at the same level but overlap, that the later one might be missed? Or, will it get stacked up and handled later?

How do the two interrupt controllers work and which should be/could be chosen for a given hardware module?

Other than the Ref manual, are there any 54415-centric appnotes describing how to correctly arrange the SR parameter in the INTERRUPT macro in conjunction with the Level parameter in SetIntC()?

The NNDK and the RunTimeLibraries does not mention setup for these new platforms.... Any help appreciated. Thanks.

[pbreed]

Interrupts do not go away... if you are servicing an interrupt and another happens that 2nd interrupt will be processes as soon as the isr level allows, its not lost.

To help with the interrupts on the MOD5441X and nanao I created a file..

intcdefs.h


it saves you the trouble of looking up the different ISR vectors and controller numbers....

For instance for PIT0 you could look in the manual and learn that its interrupt controller 2 and vector 13

Giving SetIntc(2,(long)myisrfun,13,my_level)

or

using the macros in the nburn\nano54415\include\setintc.h ...

#include <setintc.h>

SETUP_PIT0_ISR(myisrfun,my_level)


Hope that helps!

Paul

[Ridgeglider]

Paul:
Cool! That's very nice! One add'l clarification regarding correspondence between the SR parameter in the INTERRUPT macro and the Level used in SetIntC() or the new mylevel parameter as in
SETUP_PIT0_ISR(myisrfun,my_level).

As I understand it, the SR parameter in the INTERRUPT macro
1) Must not be lower than the mylevel parameter used in the corresponding SetintC() call, and
2) where:
0x2000 - Allows all interrupts
0x2100 - Blocks all interrupts below level 2
0x2200 - Blocks all interrupts below level 3
0x2300 - Blocks all interrupts below level 4
0x2400 - Blocks all interrupts below level 5
0x2500 - Blocks all interrupts below level 6
0x2600 - Blocks all interrupts below level 7
0x2700 - Blocks all interrupts below level 7

Therefore if I wrote:
INTERRUPT MyPIT_ISR, 0x2100) {....}

The corresponding SetIntc() call would look like:
SetIntc( intc, (long) MyPIT_ISR, 13, level ); //where level could be 0x2100...0x2700, but not 0x2000.

Do I have it correctly?

[pbreed]

The level parameter in the setintc shoudl be the level, not the SR..

so 1,2,3,4,5,6 (Rarerly 7)

The SR level I usually leave them all at 0x2700 in the INTERRUPT Macro...

Unless you really have a reason to change this I'd just leave it alone, that way you won't get nested interrupts,
they will be serviced in the priority then order in which they occured without loosing any.

Paul

[Ridgeglider]

Paul, could you elaborate on the notion of IRQ priority on the Nano? Not sure I follow your comment.

Most of the other NB platforms allow a priority parameter to be spec'd as part of SetIntC(). The Nano and MOD54415 lack that parameter. As I understood it, on the earlier platforms, the priority parameter allowed you to differentiate between interrupts at the same level.

For the external IRQs (1-7)the PRIORITY is fixed between 3&4. Any priority assigned to those external IRQs is ignored.

However, for all other IRQs, the old SetIntC() level and priority parameters allowed you to control how things worked. I think it was the NNDK that said "if 2 sources are at the same level, the IRQ that occurred 1st will be processed 1st. If 2 sources are at the same level, priority is determined as follows: Source w/highest PRIORITY (not LEVEL) is serviced 1st. If the 2 sources have the same priority, source w/lowest vector number is serviced 1st."

So, on the Nano, as a case in point: Serial IRQs use level 3. So too would the IRQ3 Pins[49] line. If the both occur simultaneously, what happens? My guess is that the IRQ w/ the lowest vector number is serviced 1st, ie the external IRQ3 IRQ. On the older (5270) platforms, you could have assigned a higher priority (eg more than 3-4) of say 5 to the serial routines, and then they would run first before a simultaneous IRQ3 event. This looks like it's not possible on Nano??
Is this correct?
Thanks.
Thanks.

[pbreed]

Level has and always has trumped priority.

Priority ONLY mattered if you got two interrupts of the SAME level at the same time....

IE you turn off all interrupts...

While they are off two interrupts of the same level trigger and are pending.....

When interrupts are turned back on the one with the higher priority happens first...


So in practice if you aren't turning interupts off for long periods or having interupts of higher LEVLE take a real long time to run
priority never has mattered.

In practice properly written (read short) interrupt service routines are so fast none of this matters.

If an itnerrupt service routine starts to get a bit long then put it in a high priority task that is woken up via a semaphore in the interrupt.

I always just set my INTERRUPT mask to 0x2700 and don't really worry much about the interrupt level (or priority)


The one special deviant case is if you have some kind of level sensitive interrupt (not edge sensitive) either in an internal perifpherial or as
an external hardware.... and some other interrupt routine turns off the hardware/device asking for the interrup before its interrupt gets serviced....
Then you have the slight possiblity to get a spurious interrupt trap... if you get these just make an empty interrupt routine and point the spuriopus interrupt trap at that routine...
If your doing things in assembly it woudl be very trivially faster to just poitn the vector at an RTE instruction...

[joepasquariello]

Ridgeglider,

Paul is right that interrupt level is of much greater importance than priority (within level), but I was curious about the missing "priority" argument for the 54415 version of SetIntc(), and here's what I found:

The V2 coldfire (5213, 5234, 5270, etc.) supports 7 settable priorities within each of the 7 interrupt levels, so the SetIntc() function includes priority as an argument. For the V4 coldfire (5441x), priority within the 7 interrupt levels goes by interrupt controller number and vector number, so there is no priority argument to SetIntc(). INTC0 has higher priority than INTC1 and INTC2. This is discussed in section 17.3.2 of the 54415 Reference Manual. I'm pretty sure that within an interrupt controller, the lowest numbered vector has priority.

So, while you could set priority within level any way you want in 5213, etc., priority in the 5441x is by interrupt controller and vector number.

Joe