about USB interrupt

[soichiyamamoto]

Hi.

I have a question about USB interrupt.

Under conditions of follows, At the time of USB connect,Interrupt (USBSTS = 0x00000080) of SRI of the USB is called.

I use a USB device.

I enable ARM GIC(USBC0).

USB0_USBINTR＝0；

Q1)In the case of an interrupt of the USB, may the interrupt that I do not enable occur?

Q2)Please tell me the work around of the case.

Best Regards,

Soichi

[kef2]

Soichi,

Start of frame (SOF) interrupt flag (SRI) is periodically set all the time while USB is connected. I don't know why you find this interrupt happening while SRE bit is 0 (USBINTR reg = 0). It works properly for me. SOF interrupt is disabled while USBINTR.SRE=0, enabled while USBINTR.SRE=1.

[naoumgitnik]

Hello Edward,

Thanks for your help in this and the other issues.

Juan, Edward,

I am not a SW person; as SW persons, do you think my analogy with the other false-event case does not really help?

If so, I will remove it from the thread to not confuse anybody.

Regards, Naoum Gitnik.

juangutierrez

[kef2]

Naoum,

original requst is little fuzzy. It may be bad GIC setup and you post applies, it may be software issue (SRE seems being 0, but perhaps some other part of SW sets SRE to 1 and interrupt fires). It could be also the question why is SRI flag set while SRE is 0 and some other USB interrupt occurs.

[naoumgitnik]

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.

[soichiyamamoto]

Dear Naoum,

Thank you for promptly contacting me.

I ask you a question for your answer.

　・What of the register of ARM GIC does ISF (Interrupt Status Flag) correspond to?

Best Regards,

soichi

[juangutierrez]

This ISF mentioned in the other thread is related to the PORT module (not from ARM GIC).

In you case, I think USB module should have some register that set a flag whenever an interrupt has been generated, so this will be the register you need to make sure is cleared before enabling the interrupts.