Handling Incomplete Isoc IN Interrupts F7

[ttatakis]

Posted on December 15, 2017 at 19:05

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.

[waclawek.jan]

Posted on December 18, 2017 at 00:33

There is no further info for ISO In endpoints, but the idea outlined in RM for incomplete ISO Out is to infer the conflicting endpoint from that an ISO Out endpoint is enabled and its Even/Odd does match the current frame's number's LSB:

endpoint transfer is incomplete if both the following conditions are met:

– EONUM bit (in OTG_DOEPCTLx) = FNSOF[0] (in OTG_DSTS)

– EPENA = 1 (in OTG_DOEPCTLx)

This is an entirely flawed concept (the odd/even requirement as such is flawed to start with, but I've seen it in other USB cores in the past, so this must be have some for me unknown historical reasons) and in case of several ISO In endpoints unusable.

For ISO In, one would expect that OTG_DIEPINTx.ITTXFE will indicate that an In token arrived while the outgoing packet was not ready, but it does not work for ISO endpoints ('Applies to non-periodic IN endpoints only.').

So, unfortunately, I know of no way to detect this directly, but one indirect way may be to check the Tx FIFO's level of endpoints in question in OTG_DTXFSTSx.

JW

[ttatakis]

Posted on December 18, 2017 at 20:46

Checking the 

OTG_DTXFSTSx does not work.  My 2 isoc pipes step on each other quite quickly checking the EPENA and FIFO level.  I see no way around this other than a 'packet scheduler' module in my application.  A lot of extra processing for something seemingly this basic of operation.