We have a composite USB device stack that is composed of a printer class, HID class, and CDC class (in that order) and we have been seeing some strange behavior on the printer class on Windows. We have built a proper WHQL driver and for the most part, everything runs great.
However, if we submit print jobs for a long enough period of time, eventually the printer class will stop receiving data while the other USB classes continue to operate as expected. Our USB sniffer verifies that Windows attempts to re-send the print job continuously. However, the firmware side never sees a USB interrupt for the incoming data so our firmware is obviously are not processing the data.
If we disconnect/reconnect the USB port (or do the same electrically), the problem is resolved and operation continues as normal. Through debugging we've found that their is always a device transfer event around the time of the problem occurring and we're not sure if that is a cause or a symptom.
If we run only the printer class (i.e. no composite) we never see the problem. The issue is only present when using the composite device stack.
Any advice on how to proceed with debugging would be greatly appreciated.
A solution has been found. See the discussion here:
Has anyone else seen this issue? We still see this issue from time to time and are curious if anyone has found the root cause. This definitely seems related to using the printer class in a composite configuration.
Hi Cory:
Could you please share us your board info and usb stack version? How can I reproduce this issue ?
Regards
Daniel
Hi Daniel, sorry for the late reply I never received a notification that there was a followup here.
We are using the MK22FN512 MCU on the FRDM-K22f board. Using the printer class as a member of a composite interface should reproduce the issue.