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
Searching this forum again for possible solutions i found the following information in thread http://www.keil.com/forum/16550/:
[Version] Signature="$Windows NT$" Class=Ports ClassGuid={4D36E978-E325-11CE-BFC1-08002BE10318} Provider=%STM% LayoutFile=layout.inf DriverVer=01/06/07 [Manufacturer] %STM%=DeviceList, NTamd64 [DestinationDirs] ;FakeModemCopyFileSection=12 ;FakeModemCopyFileSection.NTamd64=12 DefaultDestDir=12 [DeviceList] %DESCRIPTION%=STMUSB, USB\VID_0483&PID_5740 [DeviceList.NTamd64] %DESCRIPTION%=STMUSB, USB\VID_0483&PID_5740 ;------------------------------------------------------------------------------ ; Windows 2000/XP Sections ;------------------------------------------------------------------------------ [STMUSB.nt] include=mdmcpq.inf ;CopyFiles=FakeModemCopyFileSection CopyFiles=DriverCopyFiles.nt AddReg=STMUSB.nt.AddReg [STMUSB.nt.AddReg] HKR,,NTMPDriver,,*ntkern HKR,,NTMPDriver,,usbser.sys HKR,,EnumPropPages32,,"MsPorts.dll,SerialPortPropPageProvider" HKR,,PortSubClass,1,01 [STMUSB.nt.Services] include=mdmcpq.inf AddService=usbser, 0x00000002, DriverService [DriverService] DisplayName=%DESCRIPTION% ServiceType=1 StartType=3 ErrorControl=1 ServiceBinary=%12%\usbser.sys HKR,,PortSubClass,1,01 [STMUSB.nt.HW] include=mdmcpq.inf ;------------------------------------------------------------------------------ ; Windows 7-64bit Sections ;------------------------------------------------------------------------------ [STMUSB.NTamd64] include=mdmcpq.inf ;CopyFiles=FakeModemCopyFileSection.NTamd64 CopyFiles=DriverCopyFiles.NTamd64 AddReg=STMUSB.NTamd64.AddReg [STMUSB.NTamd64.AddReg] HKR,,NTMPDriver,,*ntkern HKR,,NTMPDriver,,usbser.sys HKR,,EnumPropPages32,,"MsPorts.dll,SerialPortPropPageProvider" HKR,,PortSubClass,1,01 [STMUSB.NTamd64.Services] include=mdmcpq.inf
The user who posted this file used it for USBCDC with Windows 7 x64.
I found some differences to my INF file and have some questions on them:
1. LayoutFile in [Version] section is included in the posted file. I excluded it from my Inf, because msdn writes: "If possible, INF files that are not distributed with the operating system should omit this entry." So I have to leave it out, right?
2. The posted INF uses DriverCopyFiles instead of FakeModemCopyFileSection in CopyFiles directive. I read a lot about this directive. It is marked as very important to find usbser.sys on target os when using the INF on different operating systems than 2k / XP. Why the posted INF file worked on Windows 7 anyway? Could it be that the necessary usbser.sys was copied to driver directory previously?
3. The posted INF has platform-specific sections. The sections for 2k / XP have platform extensions (.NT). But msdn writes about 'Cross-Platform INF Files': "Include [...] sections that are required for an x86-based installation. Do not include an .ntx86 platform extension on the names of these sections." Do I have do include .NT sections for a 2k compliant INF file?
4. The AddReg sections in the posted INF differ from my AddReg sections. In the first line there ist HKR,,NTMPDriver,,*ntkern instead of HKR,,DevLoader,,*ntkern. Why?
Furthermore there is an additional line: HKR,,PortSubClass,1,01. What does that mean?
I would be happy to get some answers.
I checked my driver installation INF file again and again, compared to other cross-platform and cross-operating system INF files for USBCDC and finally found that my latest INF file version (and possibly many other recent versions of it) works fine! Today I read about Setupapi.dev.log file in Windows Vista and I found it in Windows 7 too. The file tells me that the INF file was correct and the driver was successful installed. An error occurs when the driver setup restarts the device:
excerpt of related section in Setupapi.dev.log: dvi: Install Device: Restarting device. 12:00:30.334 dvi: Install Device: Restarting device completed. 12:00:44.677 !!! dvi: Device not started: Device has problem: 0x0a: CM_PROB_FAILED_START. dvi: Class installer: Exit
The problem might be something inside the hardware and so I think I have to go back to the roots and check the firmware... :(
I posted a newer version of CDC INF file, here. It is tested on x86 and x64 Windows XP, Vista and 7 http://www.keil.com/forum/17039/
Tsuneo
Code 10 occurs in many reasons. In this case, usbser.sys found some error on the device at its initialization. A hardware bus analyzer or software sniffer may give you a clue for this issue.
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?
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?