AnsweredAssumed Answered

Handling Incomplete Isoc IN Interrupts F7

Question asked by ttahut on Dec 15, 2017
Latest reply on Dec 18, 2017 by ttahut

I am working on a USB UVC implementation on an STM32F7.  I am having major problems getting reliable ISOC transactions out of the processor and I believe it has something to do with the Incomplete IN conditions and interrupts and perhaps the even/odd toggling of the PID's.  My basic question is, what's the proper way to handle the Incomplete ISOC interrupt?

In the F7 Reference Manual RM0410 page 1699, where it is talking about handling Incomplete ISOC IN interrupts, statement number 3 under the Application Programming Sequence section is as follows:

 

The application must read the Endpoint Control register for all isochronous IN

 

endpoints to detect endpoints with incomplete IN data transfers.

 

What exactly in that register tells me that the associated endpoint was one of the endpoints that caused the interrupt?

There is a HAL call back function for this interrupt, and it takes an endpoint number as one of its parameters.  However, the endpoint number that gets passed up is completely incorrect.  Tracing through interrupt handler, it never gets set properly for this call, nor does it look like there is an attempt to set it properly for this call.  I am looking a the HAL_PCD_IRQHandler() in stm32f7xx_hal_pcd.c, from the Cube F7 V1.8.0 installation.

 

I can not simply assume the endpoint in this interrupt because I will have multiple isoc endpoints and I need to be able to detect which one caused the interrupt.

Any other help with getting isoc pipes working is also appreciated.  I've been banging on this for some time and can not get it to function quite right.

Outcomes