PIT interruption by IRQ1 (EPORT)

[kedio]

I need to use the four available IRQ (EPORT 1, 3, 5, 7) for my application, which must be run as soon as they are triggered. I also have a Programmable interrupt timer (PIT), which scan I/O every 100 us and which doesn't need to be as much accurate as the IRQ. My problem is that IRQ1 cannot interrupt the PIT if it is triggered, although IRQ3, IRQ5 and IRQ7 can.

After some research I've found in the MCF5271 Reference Manual that "The “fixed” interrupt source is hardwired to the given level, and represents the mid-point of the priority within the level". If I understand correctly that would mean that the IRQ1 is a Level 1 interrupt. The lowest level that the PIT can be configured is Level 1, so the IRQ1 and the PIT would be on the same Level preventing IRQ1 to interrupt the PIT.

Enough context here is a few questions :

1. Is there a way to make the PIT interruptible by the IRQ1?

2. Where are IRQ2, IRQ4, IRQ6?

3. Are IRQs Level really fixed?

4. Interrupts have a Level and a priority, is the priority only to determine between two concurrent interrupts on the same Level or does a running interrupt should be interrupted by an other interrupt on the same Level, but with a highest priority?

Thank you for your help!

[Ridgeglider]

Here are some answers to your questions:
1) Can the PIT be made interruptible by IRQ1? Yes. When you setup the PIT IRQ using SetIntc(), assign it to a level that has higher precedence (eg higher IRQ Level#) than IRQ1. Note that IF two sources are at the same LEVEL, the source with the highest PRIORITY is serviced first. If two sources have the same LEVEL and PRIORITY, the source w/ lowest vector number is serviced 1st.

2) My recollection is that the IRQ2, 4, & 6 pins were not brought out to an accessible pin or pad on the Mod5270.

3) IRQ vectors 1-7 are considered EXTERNAL and therefore fixed, while vectors 8-63 are INTERNAL and programmable in terms of LEVEL and PRIORITY. The EXTERNAL (1-7) IRQs are fixed at their designated levels: (eg vector 1 is level 1, vector 2 is level 2, etc). Further they are fixed at a priority between 3 and 4. Any values assigned to LEVEL or PRIORITY for IRQ 1-7 is ignored. The Priority for these vectors is fixed to "Mid" at "3 or 4" although I have never been fully comfortable with what that "mid" priority means exactly. A long time ago 'yevgenit' made a useful post to this forum pointing out the following table in the MCF5275 Refe Manual saying that it was unfortunately not included w/ the 5270/1 manual:
http://www.freescale.com/files/32bit/do ... pdf?fpsp=1". I've included the table at the bottom and I think it communicates pretty well what that "middle" priority might mean???


4)Precedence: an IRQ w/ a higher level always gets serviced before an IRQ of lower level. So IRQ7 always takes precedence over others (hence its non-maskable status), IRQ5 over IRQ3, 3 over 1. See answer #1 above regarding the priority settings for IRQs of the same level.

[kedio]

Ok here is my SetIntc function and INTERRUPT macro for both my PIT and IRQ1:

PIT:
INTERRUPT( PIT_routine, 0x2100 ){...}
SetIntc((long)PIT_routine, 38, 1, 0);

IRQ1:
INTERRUPT(IRQ1_routine, 0x2700){...}
SetIntc((long)&IRQ1_routine, 1, 7, 8);

I don't think setting the Level and priority for the IRQ1 does anything since they are fixed, but I've set my PIT to Level 1 and priority 0 and still I see on the oscilloscope a variable delay between the trigger and the execution of IRQ1 which I don't see on IRQ3, IRQ5 and IRQ7. The delay is removed if the PIT is not set up so it seems to be the culprit, I think what is happening is that sometimes the PIT is running and IRQ1 can't seem to be able to interrupt it while the others IRQ can.

[Ridgeglider]

The delay in the PIT IRQ execution you're seeing on the scope seem plausible since it is set up at the same IRQ level (ie 1) as your IRQ1 ISR, but at lower priority (ie 0) than the 'fixed' level=1 and priority = "3-4" that IRQ1 will be forced to. In other words although you spec'd level 7, and priority=8 for the IRQ1 routine, note that they it will be forced to a level of 1 and a priority of "3-4".

I'd suggest either increasing the level (above 1), or the priority (above 4) of the PIT IRQ so takes precedence over IRQ1.

Note however, that an IRQ using the external IRQ1 vector 1 will never have priority over higher IRQs. From your opening statement, this may be a design flaw. If you want the external IRQs to have precedence over the PIT, assign the PIT to level one, and then use the external IRQ3, 5, and 7 pins. Note that the IRQ7 pin is handled quite differently than all other IRQs. If you have not seen it, take a look at http://www.netburner.com/component/docm ... rm?Itemid=


One other thing to be careful of is to insure that in the INTERRUPT( Addr_of_ISR, 0x2n00) call that the, 'n' must not be lower than the LEVEL specified in the corresponding SetIntc() call.

[kedio]

Actually I want the external IRQs to have precedence over the PIT but I need all four of them...

Are you saying that it is impossible for IRQ1 to have precedence over the PIT?

[Ridgeglider]

As I mentioned, IRQ1 will be forced to level 1 and priority of '3-4'. Accordingly, you should be able to assign a lower precedence to the PIT IRQ by configuring the PITIRQ to level 1, and priority 0, 1, 2, or (maybe ??) 3 depending on how exactly the IRQ1 forced priority of '3-4' works. I think this should work.

[pbreed]

Rather than use IRQ1, use one of the timer inputs in capture mode, that way you can set any priority you want ...
(Including 7) , the IRQ1, is indeed fixed to level 1.


Paul

[kedio]

Yes I've tried to set PIT IRQ Level to 1 and priority to 0 with:

SetIntc((long)PIT_routine, 38, 1, 0);

Still IRQ1, which should be Level 1 priority 3-4 can't seem to interrupt PIT IRQ

I've also tried Level to 3 and priority to 0:

SetIntc((long)PIT_routine, 38, 3, 0);

That makes IRQ3 unable to interrupt PIT IRQ altough IRQ3 should be level 3 priority 3-4


Changing PIT IRQ priority to 2 or 6 have no effect.
It seems that if IRQx is on the same level as the PIT the IRQ fails to interrupt the PIT independently of priority.

[Ridgeglider]

Hmmm, odd. Does your ISR clear the interrupt flag right away? Maybe if you clear late, it prevents other IRQs??

Paul's suggestion of using a timer input capture pin is a great one!

[pbreed]

This is one of those asteric data sheet items that is not at all obvious....


IRQ1 is Level 1, no matter what value you set in the interrupt controller.
IRQn is Level n, no matter what value you set in the interrupt controller.

I've taken to using timer inputs when I can as the levels are setable, and if I'm really trying to measure some kind of timing the timer capture is nice as well.. much more accurate than IRQS..