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
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 :) ).