Hello,
I have a LPC2478 than I can address via 2 data sources: A CDC device and a USB to RS-485 converter. I see something very strange: If I try to use them in parallel, the USB CDC transfers are starting to logged by my sniffer as "canceled" - it is then required to unplug and re-plug the USB cable (of the CDC device). What is happening here?
Thanks in advance!
here is a log of the moment it goes wrong:
URB 0124 13:28:16.611 Bulk or Interrupt Transfer 91 out 01:01:02 8350A030h 00000132 ACPI FC795660h URB 0125 13:28:16.611 Bulk or Interrupt Transfer 91 out 01:01:02 82F58B60h USBPDO-15 usbhub FC795660h URB 0126-0125 13:28:16.611 Bulk or Interrupt Transfer 91 out 01:01:02 82F58B60h USBPDO-15 usbhub FC795660h Success (Success) URB 0127-0124 13:28:16.611 Bulk or Interrupt Transfer 91 out 01:01:02 8350A030h 00000132 ACPI FC795660h Success (Success) URB 0128-0123 13:28:16.611 Bulk or Interrupt Transfer 174 in 01:01:82 82F58B60h USBPDO-15 usbhub FC5AD368h Success (Success) URB 0129-0122 13:28:16.611 Bulk or Interrupt Transfer 174 in 01:01:82 8350A030h 00000132 ACPI FC5AD368h Success (Success) URB 0130 13:28:16.611 Bulk or Interrupt Transfer 4096 in 01:01:82 8350A030h 00000132 ACPI FC5AD368h URB 0131 13:28:16.611 Bulk or Interrupt Transfer 4096 in 01:01:82 82F58B60h USBPDO-15 usbhub FC5AD368h URB 0132 13:28:16.861 Bulk or Interrupt Transfer 91 out 01:01:02 8350A030h 00000132 ACPI FC795660h URB 0133 13:28:16.861 Bulk or Interrupt Transfer 91 out 01:01:02 82F58B60h USBPDO-15 usbhub FC795660h URB 0134-0133 13:28:16.861 Bulk or Interrupt Transfer 91 out 01:01:02 82F58B60h USBPDO-15 usbhub FC795660h Success (Success) URB 0135-0132 13:28:16.861 Bulk or Interrupt Transfer 91 out 01:01:02 8350A030h 00000132 ACPI FC795660h Success (Success) URB 0136 13:28:17.111 Bulk or Interrupt Transfer 91 out 01:01:02 8350A030h 00000132 ACPI FC795660h URB 0137 13:28:17.111 Bulk or Interrupt Transfer 91 out 01:01:02 82F58B60h USBPDO-15 usbhub FC795660h URB 0138-0137 13:28:17.111 Bulk or Interrupt Transfer 91 out 01:01:02 82F58B60h USBPDO-15 usbhub FC795660h Success (Success) URB 0139-0136 13:28:17.111 Bulk or Interrupt Transfer 91 out 01:01:02 8350A030h 00000132 ACPI FC795660h Success (Success) URB 0140 13:28:17.361 Bulk or Interrupt Transfer 91 out 01:01:02 8350A030h 00000132 ACPI FC795660h URB 0141 13:28:17.361 Bulk or Interrupt Transfer 91 out 01:01:02 82F58B60h USBPDO-15 usbhub FC795660h URB 0142-0141 13:28:17.611 Bulk or Interrupt Transfer 0 out 01:01:02 82F58B60h USBPDO-15 usbhub FC795660h Cancelled (Canceled) URB 0143-0140 13:28:17.611 Bulk or Interrupt Transfer 0 out 01:01:02 8350A030h 00000132 ACPI FC795660h Cancelled (Canceled) URB 0144 13:28:17.861 Bulk or Interrupt Transfer 91 out 01:01:02 8350A030h 00000132 ACPI FC5ACA38h URB 0145 13:28:17.861 Bulk or Interrupt Transfer 91 out 01:01:02 82F58B60h USBPDO-15 usbhub FC5ACA38h
I see that when I try to resend something to the device, a setup stage is triggered. Why is that? and why do my transfers still get canceled?
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,
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!