2 Replies Latest reply on Aug 25, 2015 5:51 AM by madhul_36


      Has anyone had luck using IOCTL_ADAPT_ABORT_PIPE? When I call DeviceIoControl with IOCTL_ADAPT_ABORT_PIPE, it returns success, but seems to do nothing. Here's how/why I'm using it:


      My host software needs to recover from an error condition where the device can't accept any more packets on EP2 OUT. I have setup the FX2 firmware to stall the endpoint when it cannot accept the packets (because hardware interfaced by GPIF is unexpectedly busy, and blocks GPIF, which I abort after a timeout). The sequence looks like this:


      1. FX accepts some packets, then starts NAK'ing all EP2 OUT packets because hardware is busy.


      2. FX time-out (implemented in firmware using hardware timer) occurs, and firmware stalls EP2.


      3. The host driver (Cyusb.sys) sees the endpoint is stalled, and suspends sending packets.


      4. Host software overlapped transfer times-out waiting for transfer to complete.


      5. Host software asserts IOCTL_ADAPT_ABORT_PIPE in an attempt to end the transfer.


      6. Host software asserts IOCTL_ADAPT_RESET_PIPE to unstall the endpoint.


      That all seems to work, except that once the endpoint stall condition is cleared in step 6, the host resumes trying to send remaining packets from the original transfer OUT over EP2 (which are still NAK'd)  - even after the host software exits! The only way I can get the host to stop sending the packets is to reset the USB port.