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
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...
Hello,
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?