枚举过程中的挑盘问题

我在枚举过程中，发送setup包给U盘，大部分盘都可以顺利返回确认包，但是有一个盘返回的总是超时包，我用bushound抓了它和电脑的数据传输，是同样的setup包，都是80 06 00 01 00 00 12 00，但是为什么我的就不能发送成功？

我的也是这样：（
对于某些设备发送setup包成功的几率很低
经常会超时，
不过你是每次都超时的吗？？

你是说HOST发送80 60 00 01 00 00 12 00命令设备响应超时吗?是谁
的设备?你的?还是已有的?一般这个命令不会超时呀,这是设备必须回
复的命令,HOST通过他来确定设备类和驱动程序.
建议检查方法:
1.确定命令正确发出.用BUSHOUND侦测总线,看看命令是否发出.
2.DEBUG固件程序.看看是否收到命令,跟踪处理过程,看看是否回复.
不同USB设备可能对一些不同的命令进行不同的处理,或者干脆不处理
该命令,而是把他STALL了,在这种情况下,如果你做的是HOST端,那就
要重新获取HUB状态,清掉设备STALL状态,重新枚举.

你是说HOST发送80 60 00 01 00 00 12 00命令设备响应超时吗?是谁的设备?

是我读写u盘成功后得意忘形的收集了许多u盘来读写，接过其中有几个u盘读不成功，其中有一个最严重的就是这样，第一个setup包都不能正常回复
 

建议检查方法:
1.确定命令正确发出.用BUSHOUND侦测总线,看看命令是否发出.
 

我没有办法用BUSHOUND来检查，因为我做的是HOST啊，怎么查？没有办法装bushound，但是我觉得既然其他u盘能正常收到，它也该的啊。我还专门抓了一下windows系统的包，结果和我的一样啊。
 

2.DEBUG固件程序.看看是否收到命令,跟踪处理过程,看看是否回复.
不同USB设备可能对一些不同的命令进行不同的处理,或者干脆不处理
该命令,而是把他STALL了,在这种情况下,如果你做的是HOST端,那就
要重新获取HUB状态,清掉设备STALL状态,重新枚举.

不行啊

不过你是每次都超时的吗？？

是的，100％的概率

有几个原因:
1.供电不足(胡说八道).
2.没发下去(搞不清楚).
3.设备有问题(胡搅蛮缠).
综上所诉,你先发个命令,获取HUB端口状态,看看是否有设备接入.

3.设备有问题(胡搅蛮缠).
 

我把u盘用fat格式化之后就好了，不知道是不是因为以前是用fat32格式化的。
但是在枚举的set_interface这个步骤还是不行。InterfaceSerNum = pIfc->iAltString;这个步骤得到InterfaceSerNum＝0是不是说明u盘不支持多个interface？
那要怎么处理？

适当延长枚举设备时的复位时间

适当延长枚举设备时的复位时间

不是吧，我觉得我的枚举要的时间已经够长了，其他的不用了吗？