Hello everyone,
I tried to install an driver via INF-file for USB-CDC (based on mcb2300_vcom.inf) on Windows 7 Professional x64 (in the following text called 'target system'). This is to get a COM-Port to send data via USB to an LPC2368 microcontroller.
The installation failed the first time with the message that the driver is not a x64-based system driver.
So I changed the driver as described in MSDN-article for "Cross-Platform INF Files". After a day of hard mind-work I finished the driver and tried to install it again. Now the installation starts on the target system, gives a message about the missing signature, and finishes with following message:
Driver software was found, but an error occured while installation. The device could not be started. (Code 10)
I checked the INF-file with ChkInf (WDK 7.1.0) on the target system and got only one error (no warnings):
Line x: ERROR: (E22.1.1081) Directive: CatalogFile required (and must not be blank) in section [Version] for WHQL digital signature.
I do not think this error is the reason for Code10.
I furthermore checked the usbser.sys on the target system. It's version is 6.1.7600.16385. It's date is 14.07.2009 02:06.
I do not know what to do now to make the driver work.
Finally, here is my revised INF source:
[Version] Signature="$Windows NT$" Class=Ports ClassGuid={4D36E978-E325-11CE-BFC1-08002BE10318} Provider=%MYCOMPANY% DriverVer=10/13/2010,5 [DestinationDirs] FakeModemCopyFileSection=12 DefaultDestDir=12 [Manufacturer] %MYCOMPANY%=USBDevice,NTia64,NTamd64 ;------------------------------------------------------------------------------ ; Models sections ;------------------------------------------------------------------------------ [USBDevice] %DRIVERNAME%=InstallXXUSB, USB\VID_c251&PID_1705 [USBDevice.NTia64] %DRIVERNAME%=InstallXXUSB, USB\VID_c251&PID_1705 [USBDevice.NTamd64] %DRIVERNAME%=InstallXXUSB, USB\VID_c251&PID_1705 [SourceDisksFiles] [SourceDisksNames] ;------------------------------------------------------------------------------ ; Installation ;------------------------------------------------------------------------------ [InstallXXUSB] include=mdmcpq.inf CopyFiles=FakeModemCopyFileSection AddReg=XXUSB.AddReg [XXUSB.AddReg] HKR,,DevLoader,,*ntkern HKR,,NTMPDriver,,usbser.sys HKR,,EnumPropPages32,,"MsPorts.dll,SerialPortPropPageProvider" [InstallXXUSB.Services] AddService=usbser, 0x00000002, DriverService [DriverService] DisplayName=%DRIVERNAME% Description=%DESCRIPTION% ServiceType=1 StartType=3 ErrorControl=1 ServiceBinary=%12%\usbser.sys ;------------------------------------------------------------------------------ ; String Definitions ;------------------------------------------------------------------------------ [Strings] MYCOMPANY="The name of my company" DRIVERNAME="XX USB VCom Port" DESCRIPTION="Provides a virtual COM-Port when connecting an XX via USB"
Has anyone hints for me to solve the problem and make the port work?
Best regards
> I will now start to collect information about how to interpret the logged data.
Look for error message(s) put by the logger When analyzers see packet/transaction protocol error, it puts an error message. For example, if no ACK returns in a transaction, the analyzer warns. Decent analyzer should have this function, at least.
Next, analyzers parse the contents of the transfer, and they detect protocol error. This analyzer interprets standard device requests, like "GET DESCRIPTOR DEVICE" Better analyzer parses class-specific protocol and error.
Usually, the first error points the source of the problem.
On the trace, a problem is seen here, though the analyzer doesn't put any warning.
0000008551 SETUP Add:3 EndPoint:0 GET DESCRIPTOR CONFIG Length:65545 DATA0 80 06 00 02 00 00 09 01 ACK 0000008551 IN Add:3 EndPoint:0 DATA1 09 02 43 00 02 01 00 80 32 Config descriptor (wTotalLength = 0x0043 OK) 09 04 00 00 01 02 02 00 5E Interface descriptor 0 05 24 00 10 01 Header functionnal 05 24 01 01 01 Call Management 04 24 02 02 Abstract Control Management 05 24 06 00 01 Union Function 07 05 81 03 10 00 02 Endpoint descriptor 0x81 09 04 01 00 02 0A 00 00 5E Interface descriptor 1 07 05 02 02 00 02 00 Endpoint descriptor 0x02 07 05 82 02 ACK Endpoint descriptor 0x82 <----- descriptor is cut off
For this Get_Descriptor( Config ) request, the device doesn't send full descriptors. The last endpoint descriptor is cut off in the middle. The contents of the descriptors seems fine.
Does the trace really show this log, as is? Or is it a mistake when you edit the trace?
Tsuneo
Another tip on interpreting logged trace is that, Compare the trace outline with those of another device, which is working fine.
Here are enumeration sequence outlines of CDC
CDC-ACM enumeration sequence WinXP SP2, SP3 wValue wIndex wLen Bus Reset Get_Descriptor(DEVICE) 0x0100 0x0000 0x0040 Bus Reset Set_Address 0002 0000 0000 Get_Descriptor(DEVICE) 0100 0000 0012 Get_Descriptor(CONFIG) 0200 0000 0009 Get_Descriptor(STRING) 0300 0000 00FF Get_Descriptor(STRING) 0303 0409 00FF Get_Descriptor(CONFIG) 0200 0000 00FF Get_Descriptor(STRING) 0300 0000 00FF Get_Descriptor(STRING) 0302 0409 00FF Get_Descriptor(STRING) 0300 0000 00FF Get_Descriptor(STRING) 0302 0409 00FF Get_Descriptor(DEVICE) 0100 0000 0012 Get_Descriptor(CONFIG) 0200 0000 00FF Set_Configuration 0001 0000 0000 Get_Line_Coding 0000 0000 0007 Set_Control_Line_State 0000 0000 0000 IN transaction to the Interrupt IN EP Vista SP1 wValue wIndex wLen Bus Reset Get_Descriptor(DEVICE) 0x0100 0x0000 0x0040 Bus Reset Set_Address 0002 0000 0000 Get_Descriptor(DEVICE) 0100 0000 0012 Get_Descriptor(CONFIG) 0200 0000 00FF Get_Descriptor(STRING) 0303 0409 00FF Get_Descriptor(STRING) 0300 0000 00FF Get_Descriptor(STRING) 0302 0409 00FF Get_Descriptor(DEVICE) 0100 0000 0012 Get_Descriptor(CONFIG) 0200 0000 00FF Set_Configuration 0001 0000 0000 Get_Line_Coding 0000 0000 0007 Set_Control_Line_State 0000 0000 0000 IN transaction to the Interrupt IN EP
In both outlines, two requests, Get_Line_Coding and Set_Control_Line_State follow Set_Configuration But on your trace, no request follows Set_Configuration
Did you cut off these requests when you post the trace?
First, thank you for further dealing with my problem! When I give answers that not fit to your questions or comments, please give me a hint. (Sometimes it is difficult for me to understand what is really meant since English is not my native language.)
>Tsuneo wrote:
>Look for error message(s) put by the logger >When analyzers see packet/transaction protocol error, it puts an error message. >For example, if no ACK returns in a transaction, the analyzer warns. >Decent analyzer should have this function, at least.
I used the USBee DX in its function as a data logger only. No analyzing processes were performed I guess; I got no warnings or error messages during log process. If there is no problem with my test installation, the data should be complete. The USBee DX USB data extractor manual writes: "The USB Data Extractor takes the real-time streaming data from the Full or Low Speed bus, formats it and allows you to save the data to disk or process it as it arrives."
>Next, analyzers parse the contents of the transfer, and they detect protocol error. >This analyzer interprets standard device requests, like "GET DESCRIPTOR DEVICE" >Better analyzer parses class-specific protocol and error.
Should I use another logger or try a different output format? What is meant by class-specific parsing?
>The last endpoint descriptor is cut off in the middle. >The contents of the descriptors seems fine. > >Does the trace really show this log, as is? >Or is it a mistake when you edit the trace?
I checked 2 of todays log files and yesterdays log file and all have this cut off in the middle when the device sends descriptors. It is no mistake caused by editing the trace!
I will try to get a log file while connecting to a computer that is able to work with the USBCDC device now!
> Tsuneo wrote:
>[...]two requests, Get_Line_Coding and Set_Control_Line_State follow Set_Configuration >But on your trace, no request follows Set_Configuration > >Did you cut off these requests when you post the trace?
No, I replaced lines that are equal to their previous and following line with a dot. One dot for one equal line. That was the only thing I have changed.
I will hurry up to get a trace from a installation that works fine.
OK, I think we got a solid clue which points a bug on the firmware. The device doesn't return full descriptors for Get_Descriptor( Config ) It should return 0x0043 (67) bytes, but just 64 bytes.
To make it more sure, take a trace of another fine CDC device, for reference. Compile and burn one of KEIL CDC example to your board, without any change. Confirm these points, - A fine CDC device returns full 67 bytes on Get_Descriptor( Config ) - A fine CDC device gets two more requests, Get_Line_Coding and Set_Control_Line_State, after Set_Configuration Humm.. 64 bytes. Considering that bMaxPacketSize0 (max packet size of the default endpoint) is set to 0x40 (64) bytes on the device descriptor, the bug lies in packet split process of the DATA stage on control transfer handling.
Now that we move to the firmware source code. Which example are you based on?
. I now logged the connection process beetween the device and an laptop computer running Windows 2000. The USBExtractor told me the following after a few seconds: .
USBee DX Data Extractor USB Bus Extractor Version 1.0 FullSpeed Processed 2431478 output values. Raw Sample Buffer Overflow. Your data is streaming too fast for your output settings. Lower your data rate or change to output binary files. Processed 2431478 output values. Press any key to continue...
. . .
The result of the log process is this log file:
USB Reset 0000008300 SETUP Add:0 EndPoint:0 GET DESCRIPTOR DEVICE Length:64 DATA0 80 06 00 01 00 00 40 00 ACK 0000008301 IN Add:0 EndPoint:0 DATA1 12 01 10 01 02 00 00 40 51 C2 05 17 00 01 04 20 44 01 ACK 0000008303 OUT Add:0 EndPoint:0 DATA1 ACK 0000008400 SETUP Add:0 EndPoint:0 SET_ADDRESS 2 DATA0 00 05 02 00 00 00 00 00 ACK 0000008401 IN Add:0 EndPoint:0 DATA1 ACK 0000008410 SETUP Add:2 EndPoint:0 GET DESCRIPTOR DEVICE Length:18 DATA0 80 06 00 01 00 00 12 00 ACK 0000008411 IN Add:2 EndPoint:0 DATA1 12 01 10 01 02 00 00 40 51 C2 05 17 00 01 04 20 44 01 ACK 0000008412 OUT Add:2 EndPoint:0 DATA1 ACK 0000008414 SETUP Add:2 EndPoint:0 GET DESCRIPTOR CONFIG Length:9 DATA0 80 06 00 02 00 00 09 00 ACK 0000008415 IN Add:2 EndPoint:0 DATA1 09 02 43 00 02 01 00 80 32 ACK 0000008416 OUT Add:2 EndPoint:0 DATA1 ACK 0000008418 SETUP Add:2 EndPoint:0 GET DESCRIPTOR STRING Length:255 DATA0 80 06 00 03 00 00 FF 00 ACK 0000008419 IN Add:2 EndPoint:0 DATA1 04 03 09 04 ACK 0000008421 OUT Add:2 EndPoint:0 DATA1 ACK 0000008423 SETUP Add:2 EndPoint:0 GET DESCRIPTOR STRING Length:255 DATA0 80 06 44 03 09 04 FF 00 ACK 0000008424 IN Add:2 EndPoint:0 DATA1 1A 03 44 00 45 00 4D 00 4F 00 30 00 30 00 30 00 30 00 30 00 30 00 30 00 30 00 ACK 0000008426 OUT Add:2 EndPoint:0 DATA1 ACK 0000008428 SETUP Add:2 EndPoint:0 GET DESCRIPTOR CONFIG Length:255 DATA0 80 06 00 02 00 00 FF 00 ACK 0000008429 IN Add:2 EndPoint:0 DATA1 09 02 43 00 02 01 00 80 32 09 04 00 00 01 02 02 00 5E 05 24 00 10 01 05 24 01 01 01 04 24 02 02 05 24 06 00 01 07 05 81 03 10 00 02 09 04 01 00 02 0A 00 00 5E 07 05 02 02 00 02 00 07 05 82 02 ACK 0000008430 IN Add:2 EndPoint:0 DATA0 00 02 00 ACK 0000008432 OUT Add:2 EndPoint:0 DATA1 ACK 0000008434 SETUP Add:2 EndPoint:0 GET DESCRIPTOR STRING Length:255 DATA0 80 06 00 03 00 00 FF 00 ACK 0000008435 IN Add:2 EndPoint:0 DATA1 04 03 09 04 ACK 0000008437 OUT Add:2 EndPoint:0 DATA1 ACK 0000008439 SETUP Add:2 EndPoint:0 GET DESCRIPTOR STRING Length:255 DATA0 80 06 20 03 09 04 FF 00 ACK 0000008440 IN Add:2 EndPoint:0 DATA1 24 03 4B 00 65 00 69 00 6C 00 20 00 4D 00 43 00 42 00 32 00 33 00 30 00 30 00 20 00 56 00 43 00 4F 00 4D 00 ACK 0000008442 OUT Add:2 EndPoint:0 DATA1 ACK 0000008444 SETUP Add:2 EndPoint:0 GET DESCRIPTOR STRING Length:255 DATA0 80 06 00 03 00 00 FF 00 ACK 0000008445 IN Add:2 EndPoint:0 DATA1 04 03 09 04 ACK 0000008447 OUT Add:2 EndPoint:0 DATA1 ACK 0000008449 SETUP Add:2 EndPoint:0 GET DESCRIPTOR STRING Length:255 DATA0 80 06 20 03 09 04 FF 00 ACK 0000008450 IN Add:2 EndPoint:0 DATA1 24 03 4B 00 65 00 69 00 6C 00 20 00 4D 00 43 00 42 00 32 00 33 00 30 00 30 00 20 00 56 00 43 00 4F 00 4D 00 ACK 0000008452 OUT Add:2 EndPoint:0 DATA1 ACK 0000008459 SETUP Add:2 EndPoint:0 GET DESCRIPTOR DEVICE Length:18 DATA0 80 06 00 01 00 00 12 00 ACK 0000008460 IN Add:2 EndPoint:0 DATA1 12 01 10 01 02 00 00 40 51 C2 05 17 00 01 04 20 44 01 ACK 0000008461 OUT Add:2 EndPoint:0 DATA1 ACK 0000008463 SETUP Add:2 EndPoint:0 GET DESCRIPTOR CONFIG Length:65545 DATA0 80 06 00 02 00 00 09 01 ACK 0000008464 IN Add:2 EndPoint:0 DATA1 09 02 43 00 02 01 00 80 32 09 04 00 00 01 02 02 00 5E 05 24 00 10 01 05 24 01 01 01 04 24 02 02 05 24 06 00 01 07 05 81 03 10 00 02 09 04 01 00 02 0A 00 00 5E 07 05 02 02 00 02 00 07 05 82 02 ACK 0000008465 IN Add:2 EndPoint:0 DATA0 00 02 00 ACK 0000008467 OUT Add:2 EndPoint:0 DATA1 ACK 0000008469 SETUP Add:2 EndPoint:0 SET_CONFIGURATION 1 DATA0 00 09 01 00 00 00 00 00 ACK 0000008470 IN Add:2 EndPoint:0 DATA1 ACK 0000008472 SETUP Add:2 EndPoint:0 DATA0 A1 21 00 00 00 00 07 00 ACK 0000008473 IN Add:2 EndPoint:0 DATA1 80 25 00 00 00 00 08 ACK 0000008474 OUT Add:2 EndPoint:0 DATA1 ACK 0000008476 SETUP Add:2 EndPoint:0 DATA0 21 22 00 00 00 00 00 00 ACK 0000008477 IN Add:2 EndPoint:0 DATA1 ACK 0000008479 IN Add:2 EndPoint:1 NAK 0000008479 IN Add:2 EndPoint:2 NAK 0000008479 IN Add:2 EndPoint:2 NAK The last line repeats continous several thousand times until the log file ends. (Approx. 100 lines with equal timestamp)
. The transmission of descriptors is cutted off again... What does this mean? I can use the USB connection on this laptop computer. Maybe it is a bug inside the USBExtractor program?
I started a log process with binary file output and got several hundred values logged only. But the binary file is hard to read...
Any ideas about my problem after having read the log file of a working USB connection?
Have seen your post after sending my post (editing takes some time...). I have to finish for today (driving home one and a half hour), but will quickly answer tomorrow again.
> Have seen your post after sending my post (editing takes some time...). > I have to finish for today (driving home one and a half hour), but will quickly answer tomorrow again.
I'm not your boss, so I don't say do it immediately ;-) I'm accessing from Japan. I know you are living in elsewhere, the opposite side of the globe? So, don't worry about the time lag. > I now logged the connection process beetween the device and an laptop computer
Which device? If it were the same device in problem, the trace doesn't give us new findings so much. The reference trace should be taken on another CDC device, which works fine, on the same x64 Win7 PC. This reference proves if the analyzer, USBExtractor, works fine or not.
> Any ideas about my problem after having read the log file of a working USB connection?
It's because the OS is Win2k USB class drivers on Win2k rarely check device configuration so strictly. But the version of Windows becomes newer, the device configuration check more and more strict. I know many devices, which work on Win2k, but not on XP, Vista and 7.
Tsuneo wrote: I'm not your boss, so I don't say do it immediately ;-) I'm accessing from Japan. I know you are living in elsewhere, the opposite side of the globe? So, don't worry about the time lag..
A little misunderstanding I think. I want to hurry up because I am very interested in what the problem is. It does not matter if anyone (including my boss) tells me to hurry up... ;).
Yeah, I am living elsewhere - in Germany... I do not like that choosing my country on top of a forum reply has no affect. Always see the Flag of the United States of America. :( Maybe it will be fixed one fine day. .
.
Tsuneo wrote: Which device? If it were the same device in problem, the trace doesn't give us new findings so much. The reference trace should be taken on another CDC device, which works fine, on the same x64 Win7 PC. This reference proves if the analyzer, USBExtractor, works fine or not. .
I logged the faulty device again. I have to prove the proper operation of the USBee DX with a fine working CDC device on the original target system, I immediately understood. But I was interested on the results with the faulty device on a working installation.
Tsuneo wrote: USB class drivers on Win2k rarely check device configuration so strictly. But the version of Windows becomes newer, the device configuration check more and more strict. I know many devices, which work on Win2k, but not on XP, Vista and 7..
Wow, good to know - thank you. Because of the long history of USB, Windows 2000 and later versions would have all the same behavior on connecting a USB device, I thought. Microsoft gives the impression too by using the same library names in all these windows versions for providing USB functions.
Now I will start to log a proper CDC device... I will get back as soon as possible.
Hello again,
I tried to log the USBCDC example of MDK-ARM V4.01 burned into evaluation board 'Keil MCB2300'. The result is, that the logger always hangs up. Checking the examples device descriptor in usbdesc.c I found that USB 2.0 is specified. The USBee DX USBExtractor is not able to log USB 2.0 data because it is too fast!
Back to the firmware of the faulty device I found that USB 1.1 is specified there. So I can now say definitely our firmware bases on USBCDC example that was included in MDK-ARM V3.23a or earlier.
Now, to prove that USBee logs / analyzes USB 1.1 communication exactly, what should I do?
1. Burn the USBCDC example of MDK-ARM V3.23a to my MCB2300 evaluation board
or
2. Change the bcdUSB value from 0x02 0x00 to 0x01 0x10 in the device descriptor of the MDK-ARM V4.01 USBCDC example and burn it into my MCB2300 evaluation board.
Is it possible to simply change the USB specification in device descriptor or are further changes needed to get a slower USB device?
I try to inform myself deeper about starting processes of an USB connection between host and device at the moment.
In the yesterdays log files I found that the controller read the descripors more than once. This happend on Windows 7 x64 (target system reporting USB device error) and Windows2000 (target system reporting no USB device error). Why are the descriptors read several times?
In some minutes I will start into the weekend.
Many thanks for all the information so far.
It would be great to read more answers here next week (I would be glad if you can find the time Tsuneo :) ).
Hello,
I am on my way towards a new point of understanding USB and so I found (maybe) some answers to unanswered questions in this thread. I found out that all the descriptors used in our firmware are equal to the USBCDC example given by Keil. That is completely wrong I think. I found in the configuration descriptor the bmAttributes is set to bus-powered and the bMaxPower set to 100mA. Our device is self-powered!!! We exchange data between our device and a computer via USB. To realize this, we modified the USBCDC example without any idea of its complexity. Occuring problems we solved via try-and-error method until today. As I am informed a bit now, the example uses two interfaces. Are both of these two interfaces needed if we want to use a virtual COM port? Furthermore we changed or deleted functions without knowing what these changes effect to. Some examples out of the file cdcuser.c: - changed CDC_BUF_SIZE from 256 to 512 - changed the functions CDC_RdOutBuf, CDC_Init, CDC_SetLineCoding - deleted the functions CDC_BulkIn and CDC_GetSerialState Unfortunately most changes have been not made by myself, so in most cases I do not know about the reasons and the effects. I do not know where to start searching for possible errors at the moment, so I will go on to try to understand the descriptors in the USBCDC example and their special purposes now.
Update:
I am actual reading the "Universal Serial Bus Class Definitions for Communications Devices Revision 1.2" for a better understanding of the USBCDC example provided by Keil. After reading the first pages of the document I am able to answer one of my latest questions by myself:
I wrote: As I am informed a bit now, the example uses two interfaces. Are both of these two interfaces needed if we want to use a virtual COM port?
They both are required!
To be continued...
It seems Tsuneo is busy recently.
www.usbmadesimple.co.uk/ums_1.htm
Specification
The current specification is 'Universal Serial Bus Specification, Revision 2'. This can be obtained free of charge on the USB-IF website. Please note that this specification replaces the earlier 1.0 and 1.1 Specifications, which should no longer be used. The Revision 2.0 specification covers all three data speeds, and maintains backwards compatibility. USB 2.0 does NOT mean High Speed.
Hello John and all other readers,
thank you for your reply and for the useful link. 'Universal Serial Bus Specification, Revision 2.0' I skim-read already. Yesterday I skim-read 'Universal Serial Bus Class Definitions for Communications Devices, Revision 1.2' for deeper understanding of the USBCDC example provided by Keil. Today I additionally started skim-reading 'Universal Serial Bus Communications Class Subclass Specification for PSTN Devices, Revision 1.2'.
After having skim-read some documents while having an eye on our firmware, I can say now that in general our descriptors are fine. I made some minor changes on them today, regarding the Strings Descriptors and the concatenated index fields in the Standard Device Descriptor. I also changed the bmAttributes and bMaxPower fields in the Standard Configuration Descriptor to SELF_POWERED and 0. Another minor change I made was to set bMaxPacket0 from 64 to 8.
Having tested the changed firmware again and logged the data exchange, I can present some new facts and conclusions:
Changing the bMaxPacket0 setting has no effect on the logged data and 'Code 10' still appears after installing the device on Windows7 x64. The device has always returned all descriptors for GetDescriptor( Config ) and is still doing it. I reviewed the first log and found that the returned data for GetDescriptor( Config ) are 67 bytes as expected. Returned data was splitted into 64 bytes and 3 bytes. In the todays log file I found the returned descriptors for getDescriptor( Config ) splitted into eight times 8 bytes and 3 bytes. I suggest that there is no problem with bMaxPacket0 or with the packet split process as supposed by Tsuneo some days ago.
Going foward, all facts seem to point on the missing Get_Line_Coding and Set_Control_Line_State requests. I have to find out what happens in the firmware after the SetConfiguration request. That is the last request by the host in all log files that have been made while connecting the faulty device to Windows7 x64! Any hints for further localization of the problem?
I will now make some tests with USBlyzer software, connecting our faulty device with the latest firmware and later the Keil MCB2300 with the USBCDC example of MDK-ARM V4.01 to an Windows XP x86 system...
I have actually logged the data exchanged between a Windows XP x86 computer and the faulty device after plugging the device to a PCI-to-USB Open Host Controller card of the computer. I used USBlyzer software to log the data exchange. Here is an excerpt of the results:
USBlyzer Report Capture List Type Seq Time Request Request Details Raw Data I/O C:I:E Device Object Device Name Driver Name IRP Status START 0001 11:57:41.000 ... PnP 0020 11:57:55.125 Start Device 858294A8h USBSER000 usbser 85493A50h PnP 0021 11:57:55.125 Start Device 85708938h USBPDO-6 usbhub 85493A50h PnP 0022-0021 11:57:55.125 Start Device 85708938h USBPDO-6 usbhub 85493A50h Success URB 0023 11:57:55.125 Get Descriptor from Device Dvc in 85708938h USBPDO-6 usbhub 853F7E48h URB 0024-0023 11:57:55.125 Control Transfer Get Descriptor (Dvc) 12 01 00 02 02 00 00 40... in --:--:00 85708938h USBPDO-6 usbhub 853F7E48h Success (Success) URB 0025 11:57:55.125 Get Descriptor from Device Cfg ind:0 in 85708938h USBPDO-6 usbhub 853F7E48h URB 0026-0025 11:57:55.125 Control Transfer Get Descriptor (Cfg ind:0) 09 02 43 00 02 01 00 40... in --:--:00 85708938h USBPDO-6 usbhub 853F7E48h Success (Success) URB 0027 11:57:55.125 Select Configuration 1 85708938h USBPDO-6 usbhub 853F7E48h URB 0028-0027 11:57:55.187 Select Configuration 1 85708938h USBPDO-6 usbhub 853F7E48h Success (Success) URB 0029 11:57:55.187 Class Interface Get Line Coding (Ifc:0) in 85708938h USBPDO-6 usbhub 853F7E48h URB 0030-0029 11:57:55.187 Control Transfer Get Line Coding (Ifc:0) 80 25 00 00 00 00 08 in --:--:00 85708938h USBPDO-6 usbhub 853F7E48h Success (Success) URB 0031 11:57:55.187 Class Interface Set Control Line State (Ifc:0) out 85708938h USBPDO-6 usbhub 853F7E48h URB 0032-0031 11:57:55.187 Control Transfer Set Control Line State (Ifc:0) out --:--:00 85708938h USBPDO-6 usbhub 853F7E48h Success (Success) URB 0033 11:57:55.187 Bulk or Interrupt Transfer 4096 bytes buffer in 01:01:82 85708938h USBPDO-6 usbhub 853F7E48h URB 0034 11:57:55.187 Bulk or Interrupt Transfer 10 bytes buffer in 01:00:81 85708938h USBPDO-6 usbhub 86B48730h PnP 0035-0020 11:57:55.187 Start Device 858294A8h USBSER000 usbser 85493A50h Success PnP 0036 11:57:55.187 Query Capabilities 858294A8h USBSER000 usbser 85493A50h
The missing GET_LINE_CODING and SET_CONTROL_LINE_STATE requests are visible here. I brought to light that the USB2.0 controller of my computer is not working correct. This may be the reason why USBee DX could not log all the requests. Now I have three problems with going on to search for the problem:
First one: The formerly missing requests are existent. They where missing while connecting the device to a Windows2000 x86 computer and while connecting the device to a Windows 7 x64 computer. Because of the requests beeing missed in all the USBee DX log files, I suggest that they would have been missed while connecting the device to a Windows XP x86 computer too. Now, after I have identified the problem with the USB2.0 controller and used the USBlyzer software to log the data exchange, the requests magically appeared. Therefore I suggest, that the requests existed all the time. So, what problem do I search for now?
Second one: I am not able to log the data exchange between the faulty device and a Windows 7 x64 computer with USBlyzer, because the software is provided for x86-based operating systems only. Does anyone have an idea about a suitable USB analyzer software that runs on x64-based operating systems including Windows 7?
Third one: I can not use USBee DX any longer, because USBee DX hardware requires to be connected to a different computer than the target system and USBee DX Data Extractor requires to run on a different computer than the target system. But there is no other computer with USB2.0 controller available to me.
To be continued....