You are here

IOCTL_ADAPT_ABORT_PIPE | Cypress Semiconductor


Summary: 2 Replies, Latest post by Madhu Sudhan on 25 Aug 2015 06:09 AM PDT
Verified Answers: 0
Last post
Log in to post new comments.
intronix_1408591's picture
1 post

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.

mady's picture
Cypress Employee
955 posts

Can you please update to our latest driver cyusb3.sys and try? We no longer recommend to use cyusb.sys


-Madhu Sudhan

mady's picture
Cypress Employee
955 posts


I have not heard of any such tool. But I think you can do it manually using any hex editors.


- Madhu Sudhan

Log in to post new comments.