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
Hello Tsuneo,
Many thanks for your reply. I started thinking my thread was invisible for other forum users... ;)
Yesterday I started to use a hardware to log the data between the laptop computer (Windows 7 x64) and our device. The hardware is called USBee DX (see http://www.usbee.com) and is able to log bus communications. I used it the first time ever and have no idea about all its possibilities yet, but I logged usb data and saved it trough a text file. The logging situation was:
- installed the USBCDC driver on target system and disconnected our device - made connections between digital inputs of USBee DX and Dplus, Dminus and GND pins of the USB connector on our device - started log process using USBextractor software (part of USBee DX data extraxtors) with USBee DX device connected to another computer - made USB connection between target system and our device - after exclamation mark appeared in device manager of the target system I stopped the log process.
Actually I don't know how to interpret the collected data. That is why I post it now.
I will now start to collect information about how to interpret the logged data. It would be greatful if you could give me some hints on the posted log file!
Because of the forum software told me that "The message is too long", I made dots where an identical line in log follows a line. For every deleted line is one dot.
Here is the log:
Log01.txt 0000008449 SETUP Add:0 EndPoint:0 GET DESCRIPTOR DEVICE Length:64 DATA0 80 06 00 01 00 00 40 00 ACK 0000008449 IN Add:0 EndPoint:0 NAK ....... 0000008449 IN Add:0 EndPoint:0 NAK 0000008449 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 0000008449 OUT Add:0 EndPoint:0 DATA1 ACK 0000008480 SETUP Add:0 EndPoint:0 SET_ADDRESS 3 DATA0 00 05 03 00 00 00 00 00 ACK 0000008480 IN Add:0 EndPoint:0 NAK .... 0000008480 IN Add:0 EndPoint:0 NAK 0000008480 IN Add:0 EndPoint:0 DATA1 ACK 0000008543 SETUP Add:3 EndPoint:0 GET DESCRIPTOR DEVICE Length:18 DATA0 80 06 00 01 00 00 12 00 ACK 0000008543 IN Add:3 EndPoint:0 NAK ... 0000008543 IN Add:3 EndPoint:0 NAK 0000008543 IN Add:3 EndPoint:0 DATA1 12 01 10 01 02 00 00 40 51 C2 05 17 00 01 04 20 44 01 ACK 0000008543 OUT Add:3 EndPoint:0 DATA1 ACK 0000008543 SETUP Add:3 EndPoint:0 GET DESCRIPTOR CONFIG Length:255 DATA0 80 06 00 02 00 00 FF 00 ACK 0000008543 IN Add:3 EndPoint:0 NAK 0000008543 IN Add:3 EndPoint:0 NAK 0000008544 IN Add:3 EndPoint:0 NAK . 0000008544 IN Add:3 EndPoint:0 NAK 0000008544 IN Add:3 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 0000008544 IN Add:3 EndPoint:0 NAK ........ 0000008544 IN Add:3 EndPoint:0 NAK 0000008544 IN Add:3 EndPoint:0 DATA0 00 02 00 ACK 0000008544 OUT Add:3 EndPoint:0 DATA1 ACK 0000008544 SETUP Add:3 EndPoint:0 GET DESCRIPTOR STRING Length:255 DATA0 80 06 44 03 09 04 FF 00 ACK 0000008544 IN Add:3 EndPoint:0 NAK ......... 0000008544 IN Add:3 EndPoint:0 NAK 0000008545 IN Add:3 EndPoint:0 NAK 0000008545 IN Add:3 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 0000008545 OUT Add:3 EndPoint:0 DATA1 ACK 0000008545 SETUP Add:3 EndPoint:0 GET DESCRIPTOR STRING Length:255 DATA0 80 06 00 03 00 00 FF 00 ACK 0000008545 IN Add:3 EndPoint:0 NAK .......... 0000008545 IN Add:3 EndPoint:0 NAK 0000008545 IN Add:3 EndPoint:0 DATA1 04 03 09 04 ACK 0000008545 OUT Add:3 EndPoint:0 DATA1 ACK 0000008545 SETUP Add:3 EndPoint:0 GET DESCRIPTOR STRING Length:255 DATA0 80 06 20 03 09 04 FF 00 ACK 0000008545 IN Add:3 EndPoint:0 NAK ..... 0000008545 IN Add:3 EndPoint:0 NAK 0000008546 IN Add:3 EndPoint:0 NAK ... 0000008546 IN Add:3 EndPoint:0 NAK 0000008546 IN Add:3 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 0000008546 OUT Add:3 EndPoint:0 DATA1 ACK 0000008550 SETUP Add:3 EndPoint:0 GET DESCRIPTOR DEVICE Length:18 DATA0 80 06 00 01 00 00 12 00 ACK 0000008550 IN Add:3 EndPoint:0 NAK .......... 0000008550 IN Add:3 EndPoint:0 NAK 0000008550 IN Add:3 EndPoint:0 DATA1 12 01 10 01 02 00 00 40 51 C2 05 17 00 01 04 20 44 01 ACK 0000008550 OUT Add:3 EndPoint:0 DATA1 ACK 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 NAK ..... 0000008551 IN Add:3 EndPoint:0 NAK 0000008551 IN Add:3 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 0000008551 IN Add:3 EndPoint:0 NAK ........ 0000008551 IN Add:3 EndPoint:0 NAK 0000008551 IN Add:3 EndPoint:0 DATA0 00 02 00 ACK 0000008551 OUT Add:3 EndPoint:0 DATA1 ACK 0000008551 SETUP Add:3 EndPoint:0 SET_CONFIGURATION 1 DATA0 00 09 01 00 00 00 00 00 ACK 0000008551 IN Add:3 EndPoint:0 NAK .................... 0000008551 IN Add:3 EndPoint:0 NAK 0000008551 IN Add:3 EndPoint:0 DATA1 ACK
Thank you for reading this huge post.
I performed a USB data log again while connecting the device to the target system via USB cable. I saw an interesting behaviour: For some seconds (maybe 3 sec) no exclamation mark was to be seen in device manager of the target system, but the device was shown. I wondered if the USB communication works well now, but then the device got an exclamation mark. :( While there was no exclamation mark, the logger counted approx. 5200 Byte(?). After some seconds the exclamation mark appeared and the logger counted approx 7300 Byte(?). I don't know exactly if the logger counts the logged Byte, that is why I added an (?). But i will find out. I conclude, that the problem may be identified at the end of the logged data. At the end of the posted log file there is no OUT transmission any more - Am I right to think that this is the timepoint where the host (target system) signals the connection as failed and add an exclamation mark in device manager?
> 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.