USB double trouble

can this be related? how can address this situation using the Keil USB software suit?

After a driver issues an abort pipe request, it must wait for all of its outstanding I/O requests on the pipe to complete, even if the abort request fails. The driver may attempt to cancel outstanding I/O requests, but it must never, under any circumstances, free IRP memory for IRPs that it has not completed or IRPs that it does not own.

can this be related? how can address this situation using the Keil USB software suit?

After a driver issues an abort pipe request, it must wait for all of its outstanding I/O requests on the pipe to complete, even if the abort request fails. The driver may attempt to cancel outstanding I/O requests, but it must never, under any circumstances, free IRP memory for IRPs that it has not completed or IRPs that it does not own.

> Bulk or Interrupt Transfer - Cancelled (Canceled)

Maybe the endpoint is disabled, or STALLed.
Or, some trouble on the hub, if you are using a hub between the device and the PC.
Just with this software sniffer log, I can't specify which one is the right one.

It's the limitation of software sniffer, which just sees the "software" traffic between the device drivers on PC, not the real bus traffic directly.

You've developed many USB projects.
Isn't it the time to get a hardware bus analyzer?
It'll answer to above question immediately, and accelerate your development.

Hardware analyzers,

Ellisys
http://www.ellisys.com/

PacketMaster
http://www.mqp.com/usbdev.htm

ITI
www.internationaltestinstruments.com/.../Store_Prod1_1480A-USB-20-Protocol-Analyzer.aspx

Beagle
http://www.totalphase.com/

Also, check out this article.
USB 2.0 Bus/Protocol Analyzer Hardware/Software Comparison
www.summitsoftconsulting.com/UsbAnalyzers.htm

Tsuneo

Isn't it the time to get a hardware bus analyzer?

Tsuneo rocks, but money still talks :-)

Let's assume the endpoint is stalled because of a pipe abort issued by the device. I tried to call 'USB_ClrStallEP' to clear it, but no availe...How Do I deal with this situation using Keil software? Maybe I'm doing the right thing in the wrong place...?

That's a bit like saying:

"I'm playing all the right notes - but not necessarily in the right order."

(Taken from Eric Morecambe, 1971.)

I'm playing all the right notes - but not necessarily in the right order

you have no idea ;-)

> I see that when I try to resend something to the device, a setup stage is triggered. Why is that?

Sound like the CDC device driver try to reset the device USB engine, by sending bus reset.
After bus reset, re-enumeration occurs. Even if the endpoint is stalled, it is released on the enumeration.

As it doesn't recover your problem, it means that your firmware doesn't implement USB_Configure_Event() properly. USB_Configure_Event() is called when Set_Configuation request comes on enumeration.
In this subroutine, your firmware should initialize the variables and flags which relate to USB communication.

For example, suppose that you have a buffer to receive large data from an OUT endpoint.
The buffer pointer is initialized to point to the top buffer in USB_Configure_Event().
Also, your firmware have any status flags related to communication, the flags are also initialized.

[code]
usbuser.c

#if USB_CONFIGURE_EVENT
void USB_Configure_Event (void) {

if (USB_Configuration) { /* Check if USB is configured */
[b] /* add your code here */[/b] }
} #endif
[/code]

Above suggestion is told just for recovery.
The original source of the trouble is still under question.

> but money still talks :-)

Call for demonstration of the analyzers to the representatives :-)

Tsuneo

Tsuneo,

Thanks for your reply. I have found the cause: the UART interrupt changing a global variable caused the CDC device to fail to reply sometimes ! Thanks a lot for your advise!