阅读:7013回复:23
使用过BUS HOUND工具的高手们请进,40分题。
我的任务是采用USB连接把三星FLASH设备实现成移动硬盘,我的USB芯片用D12,设备类当然是使用MASS STORAGE类,命令格式是SCSI 传输命令集,传输协议用BULK ONLY协议。在固件中的端点描述符中我共定义了两个端点,BULK IN和BULK OUT端点,根据D12手册,它们都是2号端点。我用BUS HOUND捕捉到目前我的程序在插入枚举时总线上的数据如下:
9.0 CTL 80 06 00 01 - 00 00 12 00 GET DESCRIPTR 0us 1.1.0 9.0 DI 12 01 10 01 - 00 00 00 10 ........ 4.2ms 1.2.0 a0 0e 03 68 - 00 01 00 00 ...h.... 1.2.8 00 01 .. 1.2.16 9.0 CTL 80 06 00 02 - 00 00 09 00 GET DESCRIPTR 31us 2.1.0 9.0 DI 09 02 20 00 - 01 01 00 80 .. ..... 3.9ms 2.2.0 32 2 2.2.8 9.0 CTL 80 06 00 02 - 00 00 20 00 GET DESCRIPTR 34us 3.1.0 9.0 DI 09 02 20 00 - 01 01 00 80 .. ..... 4.9ms 3.2.0 32 09 04 00 - 00 02 08 06 2....... 3.2.8 50 00 07 05 - 82 02 40 00 P.....@. 3.2.16 00 07 05 02 - 02 40 00 00 .....@.. 3.2.24 9.0 CTL 00 09 01 00 - 00 00 00 00 SET CONFIG 28us 4.1.0 9.2 DO 55 53 42 43 - c8 3a 3d 81 USBC.:=. 4.9ms 5.1.0 24 00 00 00 - 80 00 06 12 $....... 5.1.8 00 00 00 24 - 00 00 00 00 ...$.... 5.1.16 00 00 00 00 - 00 00 00 ....... 5.1.24 (*出问题处*)9 DI 00 80 02 02 - 1f 00 00 00 ........ 997us 7.1.0 4f 54 69 20 - 20 20 20 20 OTi 7.1.8 55 6c 74 72 - 61 20 46 6c Ultra Fl 7.1.16 6f 70 70 79 - 20 20 20 20 oppy 7.1.24 31 2e 30 30 1.00 7.1.32 9.2 DO 55 53 42 43 - c8 3a 3d 81 USBC.:=. 20sc 8.1.0 24 00 00 00 - 80 00 06 12 $....... 8.1.8 00 00 00 24 - 00 00 00 00 ...$.... 8.1.16 00 00 00 00 - 00 00 00 ....... 8.1.24 可惜帖子中无法清晰的排版,前面的9代表我的设备序号,9.0代表控制管道,9.2代表我的批管道。DI 表示数据方向由设备往主机,DO表示数据方向由主机往设备。 现在我的问题出在我标识处,本来此处应该是响应上一个BULK OUT(9.2) 通道发来的CBW命令块,命令块中包含了INQUIRY命令,此处应该由BULK IN(9.2)通道向主机发回该命令的数据部分,事实上我发回的数据部分格式没有问题,但是前面的通道标识号却不知为何变成了 9 !!而我希望的是9.2,请问各位大侠:我的问题出在何处?为何bus hound不能识别我的bulk in通道序号,我在描述符中可是正确的送出了这两个端点的描述符啊。 问题很急,恳请各位大虾援手,一定给分。 [编辑 - 7/2/02 by liuwan] |
|
最新喜欢:alien7...
|
沙发#
发布于:2002-07-02 08:58
附:我的固件程序中的端点描述符部分,我觉得这里面我没有问题。大家人多眼睛亮,帮我看看:(注:D12的两个批端点都是2号端点)
const USB_ENDPOINT_DESCRIPTOR BulkInDescriptor = { 0x07, USB_ENDPOINT_DESCRIPTOR_TYPE, 0x82, //方向为IN的2号端点 USB_ENDPOINT_TYPE_BULK, SWAP(0x0040), 0, }; const USB_ENDPOINT_DESCRIPTOR BulkOutDescriptor = { 0x07, USB_ENDPOINT_DESCRIPTOR_TYPE, 0x02, //方向为OUT的2号端点 USB_ENDPOINT_TYPE_BULK, SWAP(0x0040), 0 }; |
|
|
板凳#
发布于:2002-07-02 10:51
我的情况也是这样,设备是数据输入和输出,对于Bulk in操作,我是先发了VendorRequest,然后通过endpoint2进行传输,在in的时候看不出具体的端点。可能Bus Hound就这样吧!
|
|
地板#
发布于:2002-07-02 11:04
绝对不是,我也抓取了正确的移动盘的枚举的信息和我的设备的枚举信息进行对照,正确的情况应该是每次都应该标识具体的端点号。可以肯定是这地方的问题。
|
|
|
地下室#
发布于:2002-07-02 11:38
配置可能有问题。
0x82, //方向为IN的2号端点 0x02, //方向为OUT的2号端点 最高位表示方向,低四位为设备为端点配置的地址,很显然不能都是2。 改为0x03试试。 |
|
|
5楼#
发布于:2002-07-02 11:49
配置可能有问题。 端点配置没问题吧,0x02表示D12的端点号为2的OUT端点 |
|
|
6楼#
发布于:2002-07-02 12:32
D12的两个批端点都是2号端点 那是我错了;不过这样配置的工作原理是什么呢?除了控制管道,其它都应该是单向的啊。 |
|
|
7楼#
发布于:2002-07-02 13:23
D12很奇怪,他每个端点号下包含两个端点索引,每个端点索引都是有确定传输方向和FIFO的
|
|
|
8楼#
发布于:2002-07-02 13:28
绝对不是,我也抓取了正确的移动盘的枚举的信息和我的设备的枚举信息进行对照,正确的情况应该是每次都应该标识具体的端点号。可以肯定是这地方的问题。 你的这个“正确的移动盘”用的也是D12吗? 我现在的情况和你的很相似,请看我刚发的帖子 “大家帮我诊断一下” [编辑 - 7/2/02 by panda_lu88888888] |
|
|
9楼#
发布于:2002-07-02 13:41
你的这个“正确的移动盘”用的也是D12吗? 那个芯片不是用D12的,所以它有两个序号的端点,端点号1用于BULK IN传输,端点号2用于BULK OUT传输。但是D12手册已经规定了只有2号端点才能用于批传输。 |
|
|
10楼#
发布于:2002-07-02 14:39
所以我觉得现在不是端点配置的问题,如果配置有错,bus hound就不可能收到DI的数据,还会出现USTS为no response的报错. bus hound 对端点号的显示(9)我认为也没有错,
现在的关键是host为什么不接着发read capacity命令? 你的bus hound显示的信息中,没有USTS 的内容吗?如果有,它显示的是什么? [编辑 - 7/2/02 by panda_lu88888888] |
|
|
11楼#
发布于:2002-07-02 15:04
我看你你的帖子,发现你的inquiry命令其实并没有通过,问题就在USTS上,正确的情况应该是送了数据的那个DI下面的那个DI就是对主机进行状态回复的阶段(CSW),只有出错的情况下才会来USTS,所以你下面又来了INQUIRY命令进行重试了,你的INQURIY命令没有能完成,所以接下来的命令发不来。我怀疑问题还是在这个该死的管道号码上。
PS:你的程序是用PHILIPS网站的那个例程进行修改的吗,我看了比较像,我的也是。这样有些问题我们可以多交流了。 |
|
|
12楼#
发布于:2002-07-02 15:18
例程是别人给的,估计就是PHILIPS网站上的
我用的也是D12,SCSI命令,bulk only,咱们的情况一摸一样, 你的INQUIRY命令后有其他命令出现吗? 我得CSW的最后一个BYTE是00,这是告诉HOST上次传送成功,bus hound能截取到,说明host也手到了CSW,可为什么host 还要发inquiry呢? |
|
|
13楼#
发布于:2002-07-02 15:30
没有,我也在INQUIRY命令这儿卡住了,以后就是不断的重试。成功的U盘枚举过程在INQURIY命令后还会依次来并处理下面的命令:
test unit ready prevent/allow medium removal request sense test unit ready read capacity read(10) read(10) 做完这些处理后,盘符就出现了,枚举过程就成功了。你的情况中虽然主机收到了CSW,数据也没有错,但是主机并不认可,我认为这个端点序号肯定有古怪。 |
|
|
14楼#
发布于:2002-07-02 16:09
郁闷
是不是超时了? |
|
|
15楼#
发布于:2002-07-02 16:59
我找到我程序中出错的地方了,与那个不显示端点的问题无关。看来BUS HOUND显示D12的BULK IN管道时不指示端点号是正常的。我的枚举虽然还有错误,但是驱动程序已经能加载成功,盘符也已经出来了。
不过枚举还是没有彻底成功,希望就这个问题和大虾们继续讨论下去。 |
|
|
16楼#
发布于:2002-07-02 19:09
怎么解决的?快说说??
或者给我提醒一下,拜托了!! |
|
|
17楼#
发布于:2002-07-02 20:53
是我在移植程序过程中出的错,原来的例程代码没有错。
|
|
|
18楼#
发布于:2002-07-03 09:15
是我在移植程序过程中出的错,原来的例程代码没有错。 能不能帮我分析一下,万分感谢!! |
|
|
19楼#
发布于:2002-07-03 09:36
好吧,我把我现在程序的枚举结果写在下面,你看看对照你的结果,我也正在修改其中的错误呢,因为我对原来的例程改动较大,所以很多地方可能有延时的问题,这是最难把握的,也是我最担心的问题。另外一个问题就是内存中奇偶字节对齐的问题,因为我的CPU和编译器环境的不同,这里的问题比较多,改动比较大。
Bus Hound 3.03 capture. Complements of www.perisoft.net 目前我的程序的枚举结果(盘符已经出来,但是非常慢) Device - Device ID (followed by the endpoint for USB devices) Time - Elapsed time since the start of the previous Phase Phase - ADDR= 1394 transfer address LOCK= 1394 lock transaction CDB = Command block NSTS= NT status CTL = USB control packet RSET= bus reset DI = Data In RSTS= I/O Request Status DO = Data Out SNS = SCSI Sense Data IDE = IDE task file command SSTS= SCSI Request Block Status ISOC= Isochronous Transfer USTS= USB status (9) USB Mass Storage Device [14KB/Sec] Device Phase Data Info Time Cmd.Phase.Ofs ------ ----- ------------------------- ------------- ----- ------------------ 9.0 CTL 80 06 00 01 - 00 00 12 00 GET DESCRIPTR 0us 1.1.0 9.0 DI 12 01 10 01 - 00 00 00 10 ........ 4.1ms 1.2.0 a0 0e 03 68 - 00 01 00 00 ...h.... 1.2.8 00 01 .. 1.2.16 9.0 CTL 80 06 00 02 - 00 00 09 00 GET DESCRIPTR 33us 2.1.0 9.0 DI 09 02 20 00 - 01 01 00 80 .. ..... 3.9ms 2.2.0 32 2 2.2.8 9.0 CTL 80 06 00 02 - 00 00 20 00 GET DESCRIPTR 28us 3.1.0 9.0 DI 09 02 20 00 - 01 01 00 80 .. ..... 4.9ms 3.2.0 32 09 04 00 - 00 02 08 06 2....... 3.2.8 50 00 07 05 - 82 02 40 00 P.....@. 3.2.16 00 07 05 02 - 02 40 00 00 .....@.. 3.2.24 9.0 CTL 00 09 01 00 - 00 00 00 00 SET CONFIG 14us 4.1.0 9.2 DO 55 53 42 43 - 88 c7 2f 81 USBC../. 4.9ms 5.1.0 24 00 00 00 - 80 00 06 12 $....... 5.1.8 00 00 00 24 - 00 00 00 00 ...$.... 5.1.16 00 00 00 00 - 00 00 00 ....... 5.1.24 9 DI 00 80 02 02 - 1f 00 00 00 ........ 993us 6.1.0 4f 54 69 20 - 20 20 20 20 OTi 6.1.8 55 6c 74 72 - 61 20 46 6c Ultra Fl 6.1.16 6f 70 70 79 - 20 20 20 20 oppy 6.1.24 31 2e 30 30 1.00 6.1.32 9 DI 55 53 42 53 - 88 c7 2f 81 USBS../. 1.0ms 7.1.0 00 00 00 00 - 00 ..... 7.1.8 9.2 DO 55 53 42 43 - 88 c7 2f 81 USBC../. 1.9ms 8.1.0 fc 00 00 00 - 80 00 0a 23 .......# 8.1.8 00 00 00 00 - 00 00 00 fc ........ 8.1.16 00 00 00 00 - 00 00 00 ....... 8.1.24 //此时应该来这个CSW的状态回复却没有来 9.1 DI 55 53 42 53 - 88 c7 2f 81 fc 00 00 00 - 01(命令失败) USBS..I...... 2.0ms 9.1.0 //下面好象进行了两次重试的操作,看看这些处理所用的时间就知道肯定处理有问题, //不过最后程序还是可以加载成功,盘符也出现了。我看了SCSI协议,主要原因是因为 //出错的这些命令不是SCSI设备必须要完成的几条命令之一。 9.2 DO 55 53 42 43 - 88 c7 2f 81 USBC../. 20sc 9.1.0 fc 00 00 00 - 80 00 0a 23 .......# 9.1.8 00 00 00 00 - 00 00 00 fc ........ 9.1.16 00 00 00 00 - 00 00 00 ....... 9.1.24 9.2 DO 55 53 42 43 - 88 c7 2f 81 USBC../. 20sc 10.1.0 fc 00 00 00 - 80 00 0a 23 .......# 10.1.8 00 00 00 00 - 00 00 00 fc ........ 10.1.16 00 00 00 00 - 00 00 00 ....... 10.1.24 9.2 DO 55 53 42 43 - 88 c7 2f 81 USBC../. 20sc 11.1.0 08 00 00 00 - 80 00 0a 25 .......% 11.1.8 00 00 00 00 - 00 00 00 00 ........ 11.1.16 00 00 00 00 - 00 00 00 ....... 11.1.24 9.2 DO 55 53 42 43 - 08 b6 31 81 USBC..1. 10sc 12.1.0 08 00 00 00 - 80 00 0a 25 .......% 12.1.8 00 00 00 00 - 00 00 00 00 ........ 12.1.16 00 00 00 00 - 00 00 00 ....... 12.1.24 9.2 DO 55 53 42 43 - 68 06 2c 81 USBCh.,. 10sc 13.1.0 08 00 00 00 - 80 00 0a 25 .......% 13.1.8 00 00 00 00 - 00 00 00 00 ........ 13.1.16 00 00 00 00 - 00 00 00 ....... 13.1.24 9.2 DO 55 53 42 43 - 68 ad 2f 81 USBCh./. 10sc 14.1.0 08 00 00 00 - 80 00 0a 25 .......% 14.1.8 00 00 00 00 - 00 00 00 00 ........ 14.1.16 00 00 00 00 - 00 00 00 ....... 14.1.24 9.2 DO 55 53 42 43 - 68 06 2c 81 USBCh.,. 10sc 15.1.0 08 00 00 00 - 80 00 0a 25 .......% 15.1.8 00 00 00 00 - 00 00 00 00 ........ 15.1.16 00 00 00 00 - 00 00 00 ....... 15.1.24 9.2 DO 55 53 42 43 - 68 ad 2f 81 USBCh./. 10sc 16.1.0 00 02 00 00 - 80 00 0a 28 .......( 16.1.8 00 00 00 00 - 00 00 00 01 ........ 16.1.16 00 00 00 00 - 00 00 00 ....... 16.1.24 9.2 DO 55 53 42 43 - 68 ad 2f 81 USBCh./. 10sc 17.1.0 c0 00 00 00 - 80 00 06 1a ........ 17.1.8 00 1c 00 c0 - 00 00 00 00 ........ 17.1.16 00 00 00 00 - 00 00 00 ....... 17.1.24 //出现了USTS,指示该命令出错 9 USTS 04 00 00 c0 pid stalled 56ms 18.1.0 9 DI 55 53 42 43 - 68 ad 2f 81 USBCh./. 5.0sc 19.1.0 c0 00 00 00 - 80 ..... 19.1.8 //出现了USTS,指示该命令出错 9 USTS 30 00 00 c0 endp halted 6us 19.2.0 9.2 DO 55 53 42 43 - 68 06 2c 81 USBCh.,. 240ms 20.1.0 08 00 00 00 - 80 00 0a 25 .......% 20.1.8 00 00 00 00 - 00 00 00 00 ........ 20.1.16 00 00 00 00 - 00 00 00 ....... 20.1.24 9.2 DO 55 53 42 43 - 68 ad 2f 81 USBCh./. 9.7sc 21.1.0 c0 00 00 00 - 80 00 06 1a ........ 21.1.8 00 1c 00 c0 - 00 00 00 00 ........ 21.1.16 00 00 00 00 - 00 00 00 ....... 21.1.24 9.2 DO 55 53 42 43 - 08 b6 31 81 USBC..1. 10sc 22.1.0 08 00 00 00 - 80 00 0a 25 .......% 22.1.8 00 00 00 00 - 00 00 00 00 ........ 22.1.16 00 00 00 00 - 00 00 00 ....... 22.1.24 //出现了USTS,指示该命令出错 9 USTS 04 00 00 c0 pid stalled 1.0ms 23.1.0 9 DI 55 53 42 43 - 08 b6 31 81 USBC..1. 5.0sc 24.1.0 08 00 00 00 - 80 ..... 24.1.8 //出现了USTS,指示该命令出错 9 USTS 30 00 00 c0 endp halted 5us 24.2.0 |
|
|
上一页
下一页