USB LP interrupt CTR can not be disabled?

[yu]

Posted on July 18, 2010 at 13:49

USB LP interrupt CTR can not be disabled?

#usb #interrupt-subroutines #stm32-usb #interrupt-service-routine

[jpeacock23]

Posted on May 17, 2011 at 13:59

Completed transfer interrupt requests have to be cleared in the endpoint register.   You'll get the endpoint number and direction from the interrupt status but it's possible for more than one endpoint to complete due to latency in processing the interrupt request, so it gets complicated.

  Jack Peacock

[stforum2]

Posted on May 17, 2011 at 13:59

Are you sure that the CTR interrupt is active? 

Could it be that you are seeing that the CTR flag is set when the interrupt routine is being called due to a SOF interrupt, not due to CTR interrupt? If you disable the SOF interrupt, do you still get interrupts?

[yu]

Posted on May 17, 2011 at 13:59

Yes, even disable all LP interrupt source, the LP ISR will still be called. (of course the LP interrupt is enabled in NVIC.)

The CTR flag is set. If I do not clear the CTR flag, the ISR will never be returned, (I mean return -> re-enter-> return -> re-enter ...) and other instructions will not have any time to execute. If this behavior is not designed as is, it is definitely a bug. Harrison

[yu]

Posted on May 17, 2011 at 13:59

Hi Jack,

I know how to handle the CTR interrupt, I just want to mask the CTR interrupt. because I have already handled this request by polling the flag in a dedicate task, and clearing this flag at there. Currently, my USB library works well. But I would like to use the SOF signal as a special timer, so I enabled the LP interrupt in NVIC. Since then, the nightmare begins. Harrison

[jpeacock23]

Posted on May 17, 2011 at 13:59

From the reference manual:

''The CTR bit is set by the hardware as soon as an endpoint successfully completes a transaction, generating a generic interrupt request if the corresponding bit in USB_CNTR is set. An endpoint dedicated interrupt condition is activated independently from the CTRM bit in the USB_CNTR register. Both interrupt conditions remain active until software clears the pending bit in the corresponding USB_EPnR register (the CTR bit is actually a read only bit).'' Sounds like you have to handle CTR in the interrupt, regardless of the CTRM mask.    Jack Peacock

[yu]

Posted on May 17, 2011 at 13:59

Well, thank you Jack. I did not aware of this description. That explains the weird behavior. So, I have to clear the CTR flag in the interrupt sevice routine and set a software flag. The SOF signal now works quite well.

Harrison.