紧急求救：最长的那个descriptor回送以后还需要做什么？？？

在仿真器上单步跟踪已经确定主机的80 06 00 02 00 ff 00请求已经回送数据，因为我的configuration descriptor全长0x20，经跟踪确定最后一个空数据包也已回送。
正常情况下这个时候主机应该显示“发现新设备”并且让我选择inf文件了，（这个推断没错吧？）但是为什么我这边主机不显示？而是接着又进行了两次和第一次一样的枚举？？？

然后我到设备管理器中刷新usb设备，到是能找到新设备，但这个时候显示的发现unknown device，同样不允许我选择inf。

我怀疑应该是我最后回送那个长descriptor的时候有地方遗漏，但是有实在找不出东西了，烦请各位有经验的大侠指点迷津。

正常情况下这个时候主机应该显示“发现新设备”并且让我选择inf文件了，（这个推断没错吧？）

你的推断没错，正常情况下是这样的。
根据你提供的情况可以断定你在这次描述符的回送数据时出现了问题，最有可能的问题是描述符出现问题或者是写fifo时数据发生了变化。

你可以这样检测（我自己的方法，你可以参考一下）：
1。用仿真器看你回送的数据，注意不要直接看fifo的地址，要看寄存器的变化或者把回送的数据先赋给局不变量，再用watch window察看这个变量的值
2，检测一下你回送数据后是否收到主机发来的ack中断（按你说的情况这个中断肯定是没有，因为主机在认为你回送的描述符不正确或者没有完全回送时会重新枚举）

所以我建议你先用1的方法看一下数据是否正确的写到端点中了，如果是那就只剩下一种情况：你的描述符中有错！
下面是CYPRESS的配置描述符（用汇编写的），你可以参考一下：
FullSpeedConfigDscr:  
      db   DSCR_CONFIG_LEN               ;; Descriptor length
      db   DSCR_CONFIG                  ;; Descriptor type
      db   (FullSpeedConfigDscrEnd-FullSpeedConfigDscr) mod 256 ;; Total Length (LSB)
      db   (FullSpeedConfigDscrEnd-FullSpeedConfigDscr)  /  256 ;; Total Length (MSB)
      db   1      ;; Number of interfaces
      db   1      ;; Configuration number
      db   0      ;; Configuration string
      db   10000000b   ;; Attributes (b7 - buspwr, b6 - selfpwr, b5 - rwu)
      db   50      ;; Power requirement (div 2 ma)

;; Interface Descriptor
      db   DSCR_INTRFC_LEN      ;; Descriptor length
      db   DSCR_INTRFC         ;; Descriptor type
      db   0               ;; Zero-based index of this interface
      db   0               ;; Alternate setting
      db   4               ;; Number of end points
      db   0ffH            ;; Interface class
      db   00H               ;; Interface sub class
      db   00H               ;; Interface sub sub class
      db   0               ;; Interface descriptor string index
      
;; Endpoint Descriptor
      db   DSCR_ENDPNT_LEN      ;; Descriptor length
      db   DSCR_ENDPNT         ;; Descriptor type
      db   02H               ;; Endpoint number, and direction
      db   ET_BULK            ;; Endpoint type
      db   40H               ;; Maximun packet size (LSB)
      db   00H               ;; Max packect size (MSB)
      db   00H               ;; Polling interval

;; Endpoint Descriptor
      db   DSCR_ENDPNT_LEN      ;; Descriptor length
      db   DSCR_ENDPNT         ;; Descriptor type
      db   04H               ;; Endpoint number, and direction
      db   ET_BULK            ;; Endpoint type
      db   40H               ;; Maximun packet size (LSB)
      db   00H               ;; Max packect size (MSB)
      db   00H               ;; Polling interval

;; Endpoint Descriptor
      db   DSCR_ENDPNT_LEN      ;; Descriptor length
      db   DSCR_ENDPNT         ;; Descriptor type
      db   86H               ;; Endpoint number, and direction
      db   ET_BULK            ;; Endpoint type
      db   40H               ;; Maximun packet size (LSB)
      db   00H               ;; Max packect size (MSB)
      db   00H               ;; Polling interval

;; Endpoint Descriptor
      db   DSCR_ENDPNT_LEN      ;; Descriptor length
      db   DSCR_ENDPNT         ;; Descriptor type
      db   88H               ;; Endpoint number, and direction
      db   ET_BULK            ;; Endpoint type
      db   40H               ;; Maximun packet size (LSB)
      db   00H               ;; Max packect size (MSB)
      db   00H               ;; Polling interval

FullSpeedConfigDscrEnd:  

感谢你的耐心回复。

你说的两个方法我都试过了
首先，通过跟踪发现向fifo写的数据和我的descriptor是一致的。
写完后也收到了主机发出的tx0_ack信号，表明数据包已接收到。

按照你的说法主机既然重新枚举，那说明他没有发这个信号。可是我确实收到了呀？？？？
然后请问最后ep0在接收到这个tx0_ack信号后应该完成什么动作〉？我现在做的是
flush_tx0；
tx0_enable；

这样有错误吗？

实在是太迷惑了！！！！！

我顶

谁来帮帮我啊？？？？？

你要是确定全部发送过去了，那就很可能是你的描述符的问题，贴出来让大家看看。

const byte CFG_DESC[] =
       {CFG_LENGTH,       /*length of this desc.    09*/
                         CONFIGURATION,     /*CONFIGURATION descriptor 02*/
                         0x20,0x00, //0x22,0x00,         /*total length returned   */
                         0x01,               /*number of interfaces    */
                         0x01,               /*number of this config   */
                         140, //CFG_STR_OFS,       /*index of config. string */
                         0x40, //ATTRIBUTES,        
                         0x32,                 /*max power (100 mA)      */

                         0x09, //length of descriptor (9 bytes)
                         0x04, //descriptor type (INTERFACE)
                         0x00, //interface number (0)
                         0x00, //alternate setting (0)
                         0x02, //number of endpoints
                         0x07, // interface class (7..defined by USB spec)
                         0x01, //interface sub-class (1..defined by USB spec)
                         0x02, //interface protocol (2..defined by USB spec)
                         0x00, //nterface string index
                        
                         0x07, //descriptor length ( 7 bytes)
                         0x05, //descriptor type (ENDPOINT)
                         0x01, //endpoint address (OUT endpoint, endpoint 1)
                         0x02, //endpoint attributes (BULK OUT)
        0x40,0x00, //maximum packet size (64 bytes)
        0x00, //NOT SUPPORT
       
        0x07, //descriptor length ( 7bytes)
        0x05, //descriptor type (ENDPOINT)
        0x82, //endpoint address (IN endpoint, endpoint 2)
        0x02, //endpoint attributes (BULK IN)
        0x40, 0x00, //maximum packet size (64 bytes)
        0x00, //NOT SUPPORT}

没看出什么太大的毛病，当初我的就是试出来的，你不妨也用一下这种方法
1，你在收到这个命令之前是不是收到了一个80 06 00 02 00 00 09 00，如果时的话证明你的配置描述符没什么问题，不过我还是建议你把index of config的140该为0，这里暂时用不到这个，还有把0x20,0x00, //0x22,0x00, /*total length returned */
该为0x00,0x20试试
2，不清楚你用的什么usb芯片和控制器，所以有些问题不敢确定
3，你的interface描述符里的interface number应该设为1

以上是我的个人意见，希望能对你有所帮助。

1，你在收到这个命令之前是不是收到了一个80 06 00 02 00 00 09 00，如果时的话证明你的配置描述符没什么问题，不过我还是建议你把index of config的140该为0，这里暂时用不到这个，还有把0x20,0x00, //0x22,0x00, /*total length returned */
该为0x00,0x20试试
2，不清楚你用的什么usb芯片和控制器，所以有些问题不敢确定
3，你的interface描述符里的interface number应该设为1
 

在此感谢你的回答：
1：80 06 00 02 00 00 09这个请求是收到了，并且已经把我的config descriptor回复。
140那项我试过0，改成140是为了看看会不会去找我的string，事实是没任何结果（confuse!!!)
0x20 0x00这个的修改我马上试，不过规范里规定的不就是高低字节反置吗？我的cpu是big endin得。
2：我的芯片是国半的9604，arm cpu。
3：这个我也马上改：）

希望继续看到你的建议，再再次感谢！！！

string是在config之后才有的，你的config还没有通过，该成140也没用呀，getcongfig之后是setconfig，完成了之后设备就工作正常了，在这之后可能还有你的string等。

收到。

请问系统在什么情况下显示搜索到新设备？在收到我最长的那个config描述符？还有别的情况吗？
我现在回送完后主机有时会显示找到新设备，有时则不会，但是即使会搜索到，当我指定inf文件的时候，主机却说指定的文件不包含可用信息（vid pid都是匹配的），这是为什么？
还有就是即使我的程序暂停的情况下，在设备管理中刷新，也会搜索到一个unknown device，指定inf是情况同上。
这其中什么奥妙？？？

我现在在发最长的描述符之前设了断点，也就是说不给主机发那个描述符，这个时候程序运行，然后插入电缆，主机一样会显示“搜索到新设备”，而我指定inf时告诉我指定文件没有可用信息。

按照我最早的推断，应该是回送了最长的描述符之后主机才会做出反应啊？那现在这情况是因为什么呢？
难道主机仅仅凭上拉电阻就判断出设备连接而发现设备？

在设备管理器中刷新，找到usb的过程是否也是进行了一次枚举？为什么我的bus hound没有显示呢？？？

当d+数据线上的1.5k上拉电阻连上后，主机会显示找到新硬件，此时设备没有被枚举，所以即使你指定了inf，设备管理器里也会显示unknown device，这就是你遇到的后一种情况。

当config描述符全部返回后，主机如果收到正确，会再次显示找到新设备，要求你载入设备驱动，如果你的驱动没问题，那么设备就会继续枚举，一般情况下，下面的枚举是再次获得config，然后build pipe list，如果成功的话，设备会收到setconfig命令，你只要发一个空包过去即可，然后设备就工作正常了。

根据你说的第一个情况，有可能你的getconfig已经成功（我现在回送完后主机会显示找到新设备），但是在下面的枚举中出了问题，罪可能的问题是设备驱动中setconfig出错，你虽然收到了00 09 01 00 00 00 00 00，但是驱动没有正确配置设备（一般情况是build端点的时候除了问题），然后主机会发送00 09 00 00 00 00 00 00要求你把设备置于未配置状态！

如果你的inf中vid和pid和固件中的是匹配的，那么就是设备驱动的问题，你用softice调试一下吧，一般问题出现在selectInterface处
下面是连个标志函数
        //通过检查描述符的方法来进行主机端的配置
     interfaceList[0].InterfaceDescriptor =
     USBD_ParseConfigurationDescriptorEx(ConfigurationDescriptor,
    ConfigurationDescriptor,
-1,         // Interface - don\'t care
-1,         // Alternate Setting - don\'t care
-1,         // Class - don\'t care
-1,         // SubClass - don\'t care
-1);        // Protocol - don\'t care
ASSERT(interfaceList[0].InterfaceDescriptor != NULL);


urb = USBD_CreateConfigurationRequestEx(ConfigurationDescriptor, &interfaceList[0]);

或者时出现在configDevice处，你可以用softice在这两个地方设断点调试一下

如果你发先你的驱动中在搜索接口是用的函数是USBD_ParseConfigurationDescriptor（），那么问题很有可能就在这里了，这个函数是一个比较古老的函数了，你要是在msdn上查这个函数的话，它会建议你使用USBD_ParseConfigurationDescriptorEx（）函数，后面那个函数也是一样。

还有，上面那贴提到的应该是configDevice在前，在它里面会调用selectinterface,你的驱动里的函数名可能不是这个，但作用都是一样的啦。

***********
按照我最早的推断，应该是回送了最长的描述符之后主机才会做出反应啊？那现在这情况是因为什么呢？
难道主机仅仅凭上拉电阻就判断出设备连接而发现设备？
*************
是

**********
在设备管理器中刷新，找到usb的过程是否也是进行了一次枚举？为什么我的bus hound没有显示呢？？？
**********
我觉得不是

太感谢你了！！！

还有问题
我现在可以收到set config这个命令了，但却不是00 09 01 00 00 00 00 00，而是00 09 00 00 00 00 00 00。
我在程序中检测到的主机发出的命令依次是：
80 06 00 01 00 00 40 00
00 05 02 00 00 00 00 00
80 06 00 01 00 00 12 00
80 06 00 02 00 00 09 00
80 06 00 02 00 00 ff 00
（以上顺序还很正常，而且我都会送了相应的描述符，奇怪的是接下来的两个命令）
80 06 00 01 00 00 12 00
80 06 00 02 00 00 09 00
（不知道主机为什么会发这两个）
（然后就是set config了）
00 09 00 00 00 00 00 00

进入unconfig状态。
主机的set config命令中的wValue的值应该是由我回送的config desc中bConfigurationValue的值决定的吧？
那为什么我收到的set conf中的Value却是00呢？？？

mark

你有按我说的方法看你的驱动程序了吗？只要你能载入驱动，那么就可以用softice调你的驱动了。

我前面也说过，你收到00 09 00 00 00 00 00 00的原因有很多，一种是驱动无法在你发回的配置描述符中找到接口信息，一种是无法找到端点信息，或者是其他的，不好说。