OMAP-L138 AINTC interrupt fail to acknowledge

Alin Paduraru

Hi,

I have a problem when I try to clear an interrupt (CHIPSIG3, event 31) triggered from the DSP (C67x) towards ARM.

It seems like the interrupt is not cleared after writing the correct "1" in CHIPSIG_CLR. Only second time the interrupt handler is invoked the interrupt is (?) properly cleared.

To verify this assumption I verify SRSR1 register and the corresponding bit (31) is cleared only second time.

Is there something I am missing? Some trick?

This is the code to clear the interrupt:

r = (volatile UINT32 *)((CHIPSIG_CLR))

*r = CHIPSIG3

with the proper lock/unlock for KICK0 and KICK1 registers.

So basically the problem is that I get called twice for the same interrupt.

Any ideas?

Thanks!

over 14 years ago

0 Kevin S over 14 years ago

TI__Mastermind 38170 points

Alin,

My initial thought for why the interrupt occurs more than once was that maybe the SECR bit needed to be cleared; but since you do specify that bit 31 of SRSR1 is eventually cleared, it appears this is already done.

Does the DSP trigger the interrupt more than once (polling, etc.)? I was unable to replicate your issue with a single trigger from the DSP to interrupt the ARM. Could you possibly share more information or code snippets?

Thanks,
Kevin

0 Alin Paduraru over 14 years ago in reply to Kevin S

Prodigy 30 points

Thank you for answering Kevin!

On the DSP side I am sure the interrupt is triggered only once. I feel the problem is when handling/clearing on ARM side.

It seems the flow on ARM side is like this:

PIC calls the ISR, ISR clears the proper line in SICR, then it calls the upper apps handler that in turn clears the CHIPSIG_CLR.

Does this sound like a proper way to clear the interrupt? Do I need to clear SECR1 instead of SICR?

And also another question.

In Reference guide (sprugm7d) it say:

"Interrupts from system side are active high in polarity. Also, they are pulse type of interrupts."

What does this mean, that as long as corresponding bit is set, the interrupt keeps coming? What is the longest time interval an interrupt needs to be cleared, so that no another (false) interrupt is signaled?

Thank you very much!

Best regards,

Alin

0 Kevin S over 14 years ago in reply to Alin Paduraru

TI__Mastermind 38170 points

Alin,

It seems the flow on ARM side is like this:
PIC calls the ISR, ISR clears the proper line in SICR, then it calls the upper apps handler that in turn clears the CHIPSIG_CLR.
Does this sound like a proper way to clear the interrupt? Do I need to clear SECR1 instead of SICR?

You are correct in clearing the specified bits; using the SICR register is okay to use. I believe if you clear the CHIPSIG before clearing SICR though that may do the trick! Give it a try and let me know if you still have problems and we can reassess.

Hope this helps!

-Kevin

0 Alin Paduraru over 14 years ago in reply to Kevin S

Prodigy 30 points

It works!!! Indeed, that was the problem, the order of clearing those register!

Thank you very much for the huge help you provided!

Best regards,

Alin

0 xiaoxia li over 14 years ago in reply to Kevin S

Intellectual 340 points

Hi Kevin,

I have a problem when I try to generate an interrupts(CHIPSIG2 ,enent 30) triggered from the DSP(C674x) towards ARM.

The interrupt generates per 100 microsecond. It seems like the interrupt is generated after writing the correct "1" in CHIPSIG[BIT2], while CHIPSIG_CLR[BIT2] was set to "1" at the same time. Is that to say when the interrupt is generated it was cleared right now? How to set DSP trigger the interrupt continuously?

The code below is to generate the interrupt:

USTIMER_delay(100);

SYSCONFIG->KICKR[0] = KICK0R_UNLOCK;

SYSCONFIG->KICKR[1] = KICK1R_UNLOCK;

SYSCONFIG->CHIPSIG |= (1<<2);

SYSCONFIG->KICKR[0] = KICK0R_LOCK;

SYSCONFIG->KICKR[1] = KICK1R_LOCK;

Look forward to your reply!

Processors

Processors forum

OMAP-L138 AINTC interrupt fail to acknowledge