USB cancel transfer

[martindusek]

Hi,

on MK22 and latest SDK my USB device initiate usb IN transfer (send data from my USB device to USB host) using USB_DeviceSendRequest function. Can you please provide steps neccesary to cancel this request in my firmware?

Thanks

[mjbcswitzerland]

Hi

The data is passed to the FS USB when the OWN bit is set in the USB buffer descriptor control word.
To stop it being sent the OWN bit would need to be cleared to inform that the buffer is presently controlled by the SW and not the FS USB controller. Then the prepared data can be de-installed.

However this will cause a race state due to the fact that you will not be 100% sure that you cleared the OWN flag before the FS US controller starts its operation so additional checks will be needed afterward to know whether it was in fact sent or not (and react accordingly).

Regards

Mark

[martindusek]

Hi Mark,

that seems quite low level and complicated to me. I might try it though if there is no other solution to my problem.

I also saw USB_DeviceCancel function but when used it does some weird things to my endpoints. I guess it is not suitable for what I need.

Let's also describe my scenario. I have a scanner device. When it has an image available to be sent to host it informs host that new image is available via interrupt IN endpoint and then It sends the scanned image over bulk IN endpoint to host. The host can stop reading bulk IN endpoint anytime and it must then inform usb device (over interrupt OUT endpoint) to stop sending the image and to throw away the rest of the image data. As it is almost certain that usb device calls USB_DeviceSendRequest (to send image data over bulk IN endpoint) when the host already stopped reading bulk IN endpoint then the device must somehow "undo" that USB_DeviceSendRequest.

Martin

[mjbcswitzerland]

Hi Martin

There is a thread about the cancel function: https://community.nxp.com/thread/449726 

It may be intended as part of clearing a stall (?)

If you are "sure" that the host is no longer sending IN tokens to the device there is no risk and queued data can be flush (but the prepared buffer descriptors also need to be cancelled). As noted, this means just resetting the OWN bits in the buffer descriptors so that they are no longer pending. Whether the USB device stack you are using can do it inherently is another question so if it doesn't support this you will need to add a function to do it.

Essentially is is not complicated since you just need to know where the endpoint's buffer descriptors are and reset the OWN flag in their control words (there will be one or two depending on the driver's operation and the amount prepared). Whether there are further complications will depend on the way that the driver queues its data and makes use of swap buffers and so whether anything here needs to be unwound in the firmware driver or not.

Regards

Mark