Dear Soichi,
This issue looks quite similar to the other one - interrupt on a different event, also being falsely flagged immediately after (or, IMO, as a result of) enabling that interrupt.
Unfortunately, the thread describing it for the Freescale FAEs only (the author - our FAE from Japan), but, luckily, it looks like there are no secrets in it, so I am copying some fragments thereof explaining the "false-alarm" mechanism and how to prevent it.
Please, take into account that the signals/registers names are different in the below excerpt from our SW person's reply, but, IMO, the principle is identical.
A, SW person:
- Probably the INTC or whatever module detecting the edge transition is comparing against a legacy stored LOW value. So, when configuring the IRQC, this triggers such comparison (External Signal against the LOW stored value). So, one thing is to make sure the ISF (Interrupt Status Flag) is cleared before configuring the IRQC.
- Also you may want to ENABLE the Interrupt for External signal AFTER configuring the IRQC. Since the interrupt seems to be already enabled this might trigger a pending interrupt (ISF already set) as soon as IRQC changes.
- If the problem is not avoided by clearing the ISF, then you can handle this event by SW in the ISR (Interrupt SW Routine). There you can check if this is false IRQ (Interrupt Request) or is valid one. You can store the state of the external signal and compare it and see if there was a transition or not in the external signal.
Q, FAE:
However, why is the interrupt flag set before configuring the IRQC?
A, SW person:
I mean is a possibility that the ISF is set but SW needs to make sure it is cleared before enabling the interrupts and before configuring the edge detection by IRQC.
If you think this is a totally different issue, please, let me know, and I will delete the above explanation.
Regards, Naoum Gitnik.
