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 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.
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
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....
I wrote: Does anyone have an idea about a suitable USB analyzer software that runs on x64-based operating systems including Windows 7? I will now try to use SourceUSB...
Before I will start in the weekend, here is the latest update:
I successful logged the data exhange between our device and a Windows 7 x64 running laptop computer. I used SourceUSB 3.2.0 to log the data. In the log on row 22 to 26 I can see six times INVALID_PARAMETER on Irp Status column... What does that mean?
Best regards and many thanks for all useful answers
See you next week
Good morning to everyone,
I have analyzed the requests captured by SourceUSB now. I found out that the host sends a SELECT_CONFIGURATION request and then the INVALID_PARAMETER status occurs on the request completion. After that, a previous started START_DEVICE request also shows INVALID_PARAMETER status on request completion, followed by some successful REMOVE_DEVICE PNP requests at the end of the captured data.
Now I have to find out, why the SELECT_CONFIGURATION ends with INVALID_PARAMETER...
Here is an excerpt of the captured requests:
TYPE # Request I/O TIME DO Cfg:Ifc:Epa ISO Err/ZLP CBW CSW Irp Request Irp Status ========================================================================================================================================================================================================================= ... URB (blue field) 20 SELECT_CONFIGURATION -- 12.23830986 noname(0xfffffa8003f6e820) --- --- --- --- 0xfffffa8003f02500 --- URB (blue field) 21 SELECT_CONFIGURATION -- 12.23831272 'USBPDO-7' --- --- --- --- 0xfffffa8003f02500 --- URB (light blue field) 22 SELECT_CONFIGURATION -- 12.29962444 'USBPDO-7' --- --- --- --- 0xfffffa8003f02500 INVALID_PARAMETER URB (light blue field) 23 SELECT_CONFIGURATION -- 12.29962540 noname(0xfffffa8003f6e820) --- --- --- --- 0xfffffa8003f02500 INVALID_PARAMETER URB* (light blue field) 24 SELECT_CONFIGURATION -- 12.29963017 'USBPDO-7' --- --- --- --- 0xfffffa8003f02500 INVALID_PARAMETER URB* (light blue field) 25 SELECT_CONFIGURATION -- 12.29963112 noname(0xfffffa8003f6e820) --- --- --- --- 0xfffffa8003f02500 INVALID_PARAMETER PNP (light green field) 26 START_DEVICE -- 12.29964542 'USBSER000' --- --- --- --- 0xfffffa80040596b0 INVALID_PARAMETER PNP* (light green field) 27 START_DEVICE -- 12.29968071 'USBSER000' --- --- --- --- 0xfffffa80040596b0 INVALID_PARAMETER ...
Does anyone have an idea for the reasons why the INVALID_PARAMETER status occurs?
Hello to everyone who is still reading my 'diary' here,
I logged enumeration of Keil MCB2300, burned with vCOM Demo of MDK-ARM 4.01 and MDK-ARM 3.23a, in Windows 7 x64 with SourceUSB 3.2.0 today. Both versions of the demo work on Windows 7 x64. I mean, I do not know exactly if they work in all details, but SourceUSB shows no INVALID_PARAMETER on 'Irp Status' column and device manager shows no exclamation mark after enumeration process.
I compared the logged data with fresh enumeration data of our device and found a significant difference (after I had changed the display of column 'Time' from Elapsed Timings to Delta Timings in the SourceUSB window that shows the captured requests): I saw a time delay of about 50 ms between the start of the SET_CONFIGURATION URB request and its completion during the enumeration of our device. While enumerating the Keil MCB2300 a time delay of only 0.35 ms occured!
Should our device respond to SET_CONFIGURATION request a little faster?
In the next step I logged the enumeration process of our device in Windows XP x86 with SourceUSB again. I found the same time delay of about 50 ms between start and completion of the SET_CONFIGURATION URB request. But enumeration of our device succeeds in this operating system.
While skim-reading many USB related documents and web pages I read a lot about timing issues with different host controllers. Could different host controller types be the reason for unsuccessful enumeration in Windows 7 x64???
I will now check what type of host controllers are used in the computers I have here and then will have to inform about timing differences on different host controllers while enumeration process. In addition I will try to make the response to the SET_CONFIGURATION request a little faster.
I would be very happy if someone could give hints regarding my latest post.
finally the problem seems to be solved. After days and weeks of waiting for answers here and trying to find answers by myself, I started a thread in another forum. There I got a suggestion to use USB2.0 Command Verifier Tool (USB20CV R1.4.2.4) from usb.org. I installed it on Windows 7 x64 (not an easy task ;o) ) and found two general errors in our configuration descriptors:
* The bmAttributes field in the Configuration Descriptor was set to an invalid value. For historical reasons one bit (D7) has to be set to "1" and this bit was set to "0" in our firmware.
* The wMaxPacketSize of the bulk endpoint descriptors was set to an invalid value. The value is not allowed to exceed 64 bytes for FullSpeed USB devices. The value was set to 512 bytes in our FullSpeed device firmware.
I made the required changes to our firmware and now our device starts in Windows 7 x64. Further tests will show if there are more problems with our firmware.
Thank you for all answers here so far, especially to Tsuneo.
Gud stuff.I was stuck with the same issue,added the last two patches the device is detected in Win7 32bit. Thanks Robert Suess and Tsuneo for sharing your efforts