Source of isochronous IN incomplete interrupt

[peterd.lundgren9]

Posted on September 14, 2012 at 13:13

Hi everybody!

When I enable the isochronous IN incomplete interrupt, it turns out I get a lot of these. I have two isochronous in endpoints, but cannot find where to find the source (which endpoint) this interrupt applies to.

The manual states (29.17.6 Incomplete Isochronous IN data transfers) that ''The application must read the Endpoint Control register for all isochronous IN endpoint to detect endpoints with incomplete IN data transfers.'' 

I can't find such information there though. Anyone got a hint?

Regards,

Peter

#incomplete #usb-isochronous

[thierry1]

Posted on June 04, 2014 at 18:25

I realize this is an old thread but...

Did you ever resolve your issue? How, and what was it?

Thanks.

[tomaskrueger]

Posted on September 13, 2014 at 15:51

Hi,

I am also facing this problem.

As soon as i put one single packet to the IN endpoint, i get flooded with IsocIncomplete Interrupts.

As i understand, IsocIncomplete Ints occur when sending Data on the isoc IN endpoint without an IN-token from the Host.

What is the proper reaction to this interrupt? ee. how to stop getting all these ints?

( i only sent one single packet!)

[tsuneo]

Posted on September 14, 2014 at 15:22

> IsocIncomplete Interrupts

Sound like the interrupt, indicated by IISOIXFR bit on OTG_FS(HS)_GINTSTS registers.

Bit 20 IISOIXFR: Incomplete isochronous IN transfer

 

The core sets this interrupt to indicate that there is at least one isochronous IN endpoint on which the transfer is not completed in the current frame. This interrupt is asserted along with the End of periodic frame interrupt (EOPF) bit in this register

 

> What is the proper reaction to this interrupt?

Generally speaking, the endpoint FIFO should be flushed (or overwritten) to discard the out-dated packet on the FIFO. In isoc transfer, each packet should be delivered in-time (ie. in each (micro-)frame). If the host would fail to retrieve the packet at a frame, such packet should be dropped, to deliver right packet at the next (micro-)frame.

Refer to this part of  ''Incomplete isochronous IN data transfers - Application programming sequence'' section of the manudal.

5. Program the following fields in the OTG_FS(HS)_DIEPCTLx register to disable the endpoint:

 

– SNAK = 1 in OTG_FS(HS)_DIEPCTLx

 

– EPDIS = 1 in OTG_FS(HS)_DIEPCTLx

 

6. The assertion of the Endpoint Disabled interrupt in OTG_FS(HS)_DIEPINTx indicates that the core has disabled the endpoint.

 

– At this point, the application must flush the data in the associated transmit FIFO or overwrite the existing data in the FIFO by enabling the endpoint for a new transfer in the next micro-frame. To flush the data, the application must use the OTG_FS(HS)_GRSTCTL register.

 

 

Anyway, the explanation of IISOIXFR bit on the ''Incomplete isochronous IN data transfers'' section is utterly wrong on F2/F4 FS/HS manuals. Ignore the explanation, and take the right description at OTG_FS(HS)_GINTSTS register.

 

If you would like to discuss on the implementation details,

- open your USB class (Audio / UVC / CDC, or your generic),

- and specify the library on which you are working

(STM32_USB-Host-Device_Lib_V2.1.0 or STM32Cube_FW_F4_V1.3.0)

Tsuneo

[tomaskrueger]

Posted on September 17, 2014 at 19:01

Excellent Tsuneo, ( i have seen your name around :)

Yes, i am trying to implement a UVC FullSpeed OV7670 alike Camera Device using Lib V2.1.0 .

Hardware = stm32f207, custom board.

As this relates to the UVC implementation thread:

https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Any%20example%20on%20STM32F2xx%20with%20UVC

i would like to continue discussion over there.

regards Thomas

[tomaskrueger]

Posted on September 27, 2014 at 18:14

Tsuneo,

could you give a guideline on how to implement the isochronous transmission?

UVC-Device standpoint.

Currently i am filling the fifo in the SOF interrupt, which may not be the right method.

I think the fifo must already be filled when the SOF occurs as the Host will do the IN transaction then.

Is there any feedback (TxFifo empty interrupt) to let one know to next fill the tx-fifo.

(like it is on an bulk transfer)

thanks.