求教!老鸟帮忙分析下这段BUS HOUND打印的信息.

Device  Phase  Data                      Description       Cmd.Phase.Ofs(rep)
------  -----  ------------------------  ----------------  ------------------
   8.0  CTL    a3 00 00 00  01 00 04 00  GET STATUS               1.1.0(2)    
   8.0  DI     01 01 01 00               ....                     1.2.0        
   8.0  CTL    23 01 10 00  01 00 00 00  CLEAR FEATURE            3.1.0        
   8.0  CTL    a3 00 00 00  01 00 04 00  GET STATUS               4.1.0(2)    
   8.0  DI     01 01 00 00               ....                     4.2.0        
   8.0  CTL    23 03 04 00  01 00 00 00  SET FEATURE              6.1.0        
   8.0  CTL    a3 00 00 00  01 00 04 00  GET STATUS               7.1.0        
   8.0  DI     03 01 10 00               ....                     7.2.0        
   8.0  CTL    23 01 14 00  01 00 00 00  CLEAR FEATURE            8.1.0        
   8.0  CTL    a3 00 00 00  01 00 04 00  GET STATUS               9.1.0(2)    
   8.0  DI     03 01 00 00               ....                     9.2.0        
   8.0  CTL    23 03 04 00  01 00 00 00  SET FEATURE             11.1.0        
   8.0  CTL    a3 00 00 00  01 00 04 00  GET STATUS              12.1.0        
   8.0  DI     03 01 10 00               ....                    12.2.0        
   8.0  CTL    23 01 14 00  01 00 00 00  CLEAR FEATURE           13.1.0        
   8.0  CTL    80 06 00 02  00 00 ff 00  GET DESCRIPTOR          14.1.0        
   8.0  DI     09 02 20 00  01 01 00 c0  .. .....                14.2.0        
               19 09 04 00  00 02 08 06  ........                14.2.8        
               50 00 07 05  81 02 40 00  P.....@.                14.2.16      
               00 07 05 03  02 40 00 00  .....@..                14.2.24      
   8.0  CTL    a3 00 00 00  02 00 04 00  GET STATUS              15.1.0        
   8.0  DI     00 01 00 00               ....                    15.2.0        
  23.0  CTL    80 06 00 01  00 00 12 00  GET DESCRIPTOR          16.1.0        
  23.0  DI     12 01 10 01  00 00 00 08  ........                16.2.0        
               45 53 34 12  00 01 01 02  ES4.....                16.2.8        
               00 01                     ..                      16.2.16      
  23.0  CTL    80 06 00 02  00 00 09 02  GET DESCRIPTOR          17.1.0        
  23.0  DI     09 02 20 00  01 01 00 c0  .. .....                17.2.0        
               19 09 04 00  00 02 08 06  ........                17.2.8        
               50 00 07 05  81 02 40 00  P.....@.                17.2.16      
               00 07 05 03  02 40 00 00  .....@..                17.2.24      
  23.0  CTL    00 09 01 00  00 00 00 00  SET CONFIG              18.1.0        


不知道为什么停在这里了...在SET CONFIG的请求里我有返回状态的啊....

哪位大哥..帮忙分析下啊.....卡在这个地方了...很困惑啊....

似乎你的设备已经配置成功了.
你可以试一试输入或输出数据就能看到后面的IN或OUT包了.

在网上找了很久,终于找到很久之前别人写的一点东西.感觉对我们刚学的人比较有帮助就全贴出来了....我感觉下面提到的第4个问题和我遇到的很像,现在正在按那个思路排除问题中.希望对遇到类似问题的朋友有帮助吧...分割线以下是别人写的......

-------------------------------------------------------------------------------------------------------------------------

在枚舉階段的固件編寫中,我主要參考PHILIPS公司提供的D12型 USB芯片代碼(有參考比自己從零開始要容易很多).由于該代碼是基于51單片機編寫的,與我所用的16位單片機在性能和結構上有較大差異,因此在固件移植過程中,所遇到的問題大多來源于此.

 

下面是我在移植过程中碰到的四个主要问题。

 

第一个问题，出现在默认态阶段，主机用默认地址读取设备描述符。当MCU收到USB芯片产生的中断时，无法正确读出USB芯片中断寄存器中的值。

这个问题发生在整个枚举过程的一开始，准确的说是第一步，所以我开始怀疑MCU与USB芯片的通信是否真正建立；而在此前，我对它们之间的通信能力一直深信不疑；因为我曾经用MCU发出测试专用指令来读取USB芯片的ID值，并且正确地读到了USB芯片的ID值，从理论上讲MCU与USB的通信已经建立．解决这个问题大约用了半天时间，后来我在MCU读中断寄存器命令后加了一段延时程序，问题得到解决，即中断产生后MCU正确读出了USB芯片中断寄存器的值

我分析原因是MCU发送命令的速度太快，当发送了读USB中断寄存器值命令后，就迅速发送取数据命令，而USB芯片的速度要慢的多，在MCU读数据时还未来得及把数据准备好。之前我读取USB芯片ID值的测试指令是循环发出的，刚开始虽然数据没准备好，但随着指令的循环发出，后面指令自然可以把前面指令准备的数据发出。

 

第二个问题出现在默认态阶段，主机用默认地址读取设备描述符。MCU收到USB芯片产生的中断，却无法进入到正确的中断服务程序。

在第一个问题解决后，立刻又出现了这一问题。通过串口监控，我很快发现，解析中断信息的程序中，有一段程序的功能是互换一个BYTE数据的高低字节位，这一功能主要是针对51单片机数据存放的结构与USB接口芯片的数据结构高低位颠倒而设置的。通过实验我发现:这款16位单片机也不具有51单片机的这一特点，所以只要去掉这段高低字节互换的程序，问题就解决了。

 

第三个问题，出现在地址态阶段，主机获取设备描述符。USB设备响应主机要求，发送16字节的设备描述符给主机，主机不能收到。

因为16字节的数据是通过MCU发送到USB芯片，再由USB芯片发送到

主机的。所以需要判断数据是在哪一个环节没有被正确传输的。我利用串口监测到: MCU收到主机的读中断(读取设备描述符命令)后，会送出了16字节的设备描述符到USB芯片；但是用BUS HOUND(一种基于主机端的USB总线监视软件)监视主机端发现:主机并没有收到这16字节的数据。因此我判断问题出在数据从MCU到USB芯片这一环节——即由MCU发出的设备描述符没有被USB芯片接收到。通过实验，我发现USB芯片没有接收到MCU发来的数据是因为USB芯片的速度较慢，对它来说，每一笔由MCU发出的数据在数据线上保持的时间太短，以致USB芯片无法将数据存放到其寄存器中。当改变MCU的相关设置，延长数据在数据线上保持的时间后，问题得以解决。

      

        第四个问题，出现在配置态阶段，主机设置描述符。通过BUS HOUND监视，主机在SET_CONFIGURATION后停止枚举。

        这个问题是我碰到的最难解决的困难，难就难在一直找不出主机停止枚举的原因，不知道问题产生在哪个环节。通过BUS HOUND可以清楚地看到：主机发出了正确的SET_CONFIGURATION命令，接下来USB设备只需回送一个空包（数据为0）通知主机已收到该命令；可是主机的枚举过程进行到这里却戛然而止。为什么?难道是设备没有发出应答空包，或者是主机没有收到应答空包，还是设备回送的空包有错误?我大约用了5天时间来找支持这些假设的理由。不过，除了证明假设不成立外，一无所获。

第六天，在一次检查BUS HOUND的数据时终于有了新发现。我发现：在SET_CONFIGURATION命令之前，主机发出了GET_DESCRIPTOR来获取全部的描述符合集共46字节数据，设备回复的描述符中在第20多字节时多了一个0字节；不过我并不清楚是否是这个问题对下一步产生了影响，在我看来只要主机在枚举过程中发出了下一步枚举命令，那就表明在此之前的枚举都是正确的(后来的事实证明情况并非如此)，后一步的枚举不成功应该与前一步无关。但是因为我再也找不到任何可疑之处，所以只好去寻找那一个字节的0是从哪里来的?又经过了一天的摸索，终于找到了问题的症结。我的描述符数据是以结构体的形势存放的，当MCU收到主机发出的获取描述复命令时，就通过指针的指示将结构体中的数据发出。这些数据大多数是CHAR型，少数几个是INT型(症结)，对16位单片机来说INT型数据存放是从偶地址开始的，因此，一旦在INT型的数据前有奇数个CHAR型数据，那就天下大乱了，INT型数据会空出一个奇数的地址位，从其后的偶数地址位开始存放数据。这样中间就多出1位的0字节数据。因此当主机那边收到时这笔数据时，从这一位起其后的数据就全部错位了。当我把INT型数据改用2个CHAR型表述时，一切就正常了； 同时，在此之后的SET_CONFIGURATION也能顺利进行下去，直到枚举结束。

看来枚举的 GET_DESCRIPTOR阶段如果主机得不到正确得描述符信息，并不会影响该阶段的枚举，而是对SET_CONFIGURATION阶段产生影响，使枚举无法继续。我想这应该是由主机端驱动程序来决定的。

非常幸运，利用BUS HOUND观察到的有限数据中，在最后的几字就出现了异常，否则，这个问题不知道要困扰我多久(BUS HOUND可以显示主机端接收到设备发来的数据，但数据的长度仅为32个字节)

 

 

写在最后

对设备端固件开发而言，如果有专用的USB总线分析仪是最好不过了，不但能监视到主机端收发的数据，而且可以监视到设备端收发的数据，这样，开发的效率会大大提高，开发时间可以大大降低。但如果开发条件像我一样有限，至少应该保证有串口和BUS HOUND这种USB总线监视工具(从网上可以下载)，其中，串口可以在枚举的开始阶段使用，监控MCU的相关数据；BUS HOUND则可以在枚举的后期发挥更大的作用，因为此时传输的数据量较大，串口已不太适合作为监视工具了。

此外，在USB设备的枚举程序编写中，我遇到的最大挑战来自于8位单片机与16位单片机的结构上的差别，比如数据存取速度，数据高低字节的存放次序，数据类型与存放地址相关的特点等。从我前面列出的问题来看，大部分问题均源自于此；因此在学习某种单片机时，就要准确地掌握不同类型的MCU特性，这样就一定可以降低开发难度，缩短开发时间。