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
