Coldfire MCF5235 Interrupts

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 

Coldfire MCF5235 Interrupts

4,445 次查看
alan62
Contributor I

I have a question about interrupts on a MCF5235 Coldfire part.

I am using two interrupts, timer0 and IRQ1. IRQ1 is configured for level sensitive operation.

Timer0 has a higher priority level then IRQ1.

When IRQ1 pin goes low, and interrupt triggers and all is fine,

Occasionally during the IRQ1 service routine the timer0 interrupt occurs.

When the timer0 ISR is done it appears that the IRQ1 interrupt is retriggered.

Looking at the stack frame you will see two occurrences of the IRQ1 ISR.

During this time the IRQ1 pin is still low.

Is this normal?

Am I crazy?

How do I stop the IRQ1 from retriggering?

I do not plan on changing IRQ1 to an edge sensitive interrupt.

Is there a good application note on the Interrupt controller?

Any Ideas?

 

Thanks Alan

 

标签 (1)
0 项奖励
回复
3 回复数

956 次查看
mnorman
NXP Employee
NXP Employee
When you enter an interrupt handler, the core will load the status register's interrupt priority mask field (SR[I]) with the interrupt level of the interrupt being serviced.  This will mask out all interrupt with lesser or equal interrupt levels.  Therefore, you should not get nested IRQ1 interrupts unless you alter the SR[I] field in either your IRQ1 or Timer0 interrupt handler.
 
Note, if you exit the IRQ1 interrupt handler with the IRQ1 pin still asserted, then the interrupt will be recognized immediately and the handler will be executed again.
 
-MN
0 项奖励
回复

956 次查看
alan62
Contributor I

Thank you for your response.

What confused me was how the interrupt controller handled the existing interrupt.

Timer0 preempted the IRQ1 ISR. When Timer0 ISR was complete I expected the IRQ1 PC to be pulled of the stack and to continue.

Instead it appears that the interrupt controller upon exiting Timer0, it reviews the pending interrupts and retriggers the IRQ1 ISR. IRQ1 being level sensitive and still in a low state.

I think I have an better understanding of the interrupt controller now.

Thanks again.

Alan

0 项奖励
回复

956 次查看
mnorman
NXP Employee
NXP Employee
Actually, the state that was saved on the stack at the beginning of the Timer0 exception processing will be restored will be restored once the RTE is executed at the end of the Timer0 handler.  This will inhibit nested IRQ1 handlers as you expected (again, unless the SR[I] was modified by your IRQ1 handler). 
 
Is it possible that you are seeing this behavior as a result of the debugger operation?  You could prove this by creating a global flag that was set upon entry into the IRQ1 handler and cleared at the exit.  If you check the flag at the beginning of the IRQ1 handler, you should never find it set.
 
-MN
0 项奖励
回复