21,616
社区成员
发帖
与我相关
我的任务
分享USB HID设备导致Windows启动失败，寻求debug方法
我用ARM做了一个HID的joystick，除了buttons之外没有加乱七八糟的功能。但很奇怪，如果我插着这个设备开电脑，我的系统就会启动失败，主板自动重启之后进入一个菜单，
1. 进入系统恢复模式
2. 正常启动Windows
如果选择正常启动Windows，依旧会失败，自动重启，反复循环。如果进入系统恢复，则找不到任何问题。
但这时候如果关掉电脑，拔掉设备之后再开机。进入上述菜单后选择正常启动Windows，接下来即可顺利进入系统。
我的系统是Windows 7 x64 Ultimate，台式机。使用同一份ISO安装的笔记本电脑插着这设备开机则不会出现这种问题。因此我怀疑是我的台式机OS出了什么问题。但因为要做产品，我不排除有客户的电脑也可能存在类似隐患。所以我需要搞清楚到底是什么原因造成了这种启动失败的问题。请问各位除了使用专业USB协议分析仪之外还有没有什么办法能在Windows重启失败并再次重启多次的情况下还能追踪USB设备数据交互的过程？多谢。
1. 进入系统恢复模式
2. 正常启动Windows
如果选择正常启动Windows，依旧会失败，自动重启，反复循环。如果进入系统恢复，则找不到任何问题。
但这时候如果关掉电脑，拔掉设备之后再开机。进入上述菜单后选择正常启动Windows，接下来即可顺利进入系统。
我的系统是Windows 7 x64 Ultimate，台式机。使用同一份ISO安装的笔记本电脑插着这设备开机则不会出现这种问题。因此我怀疑是我的台式机OS出了什么问题。但因为要做产品，我不排除有客户的电脑也可能存在类似隐患。所以我需要搞清楚到底是什么原因造成了这种启动失败的问题。请问各位除了使用专业USB协议分析仪之外还有没有什么办法能在Windows重启失败并再次重启多次的情况下还能追踪USB设备数据交互的过程？多谢。
...全文
请发表友善的回复…
发表回复
智能创建未来 2019-11-21
- 打赏
- 举报
先检查自己的板子，示波器抓抓波形，看看你的usb波形是否正常，还有USB的电源与你设备的电源一定要处理好，否则会打架，可能就会导致你的电脑无法正常工作，
Simality 2018-12-06
- 打赏
- 举报
你好，非常感谢详尽的解答，我刚找到元凶。是GET_STATUS请求中的返回值Self Powered位与Configuration Descriptor里面bmAttributes对应的供电类型标志位冲突，SubClass没有问题。
我用的是STM32，CubeMX生成的代码框架。因为是全速设备，可以用来抓包调试的设备还算便宜，今天买了USBee，打算明天收到抓包看看。但好奇心驱使我先用手边能获得的途径试试。
先前对CubeMX一些犄角旮旯的功能不是很熟，生成的工程里很多外设都用了HAL库，这次想换成LL库，所以我又生成了一遍。这次顺便就把USB设置成自供电了。而上次设置的是总线供电，我自以为对STM32的USB模板已经足够了解了，所以上次用生成的工程改成了自己想要的描述符。
我运行了相对纯净的新工程之后发现开机不会受影响。所以一点点把新工程的描述符改成有问题的旧工程那样。每次修改后接入USB前都用DeviceCleanup工具把旧设备存在过的痕迹彻底抹除。我是先确认了SubClass那项为0，然后把我的Report Descriptor移植过来。运行后发现开机不受影响，那么排除了Report Descriptor不规范的嫌疑。
剩余部分从bmAttributes着手，把Bus powered修改成self powered，去掉remote-wake up支持。接着取消boot支持，把MX默认生成的nInterfaceProtocol那项从2（mouse）改成0。后来发现MX生成的项目Endpoint 81的max packet size是4，我的是64。由于我的硬件上集成了一个FE1.1s和一个CH340E，我怕64bytes影响host对时隙分配的评估，所以我分别试了32、16、8、4，发现根本没有改善。
最后没辙了我打开BusHound把两个产品的枚举分别抓下来用UltraCompare并排比较。这两个产品改到这个程度除了PID不同之外其它完全一样。后来我留意到唯一有个GET_STATUS请求后面的回复有差异。有问题的设备回复是01 00，没问题那个回复的是00 00。那条GET_STATUS的bmRequestType是80。
翻阅了对应的回复数据格式，发现01是低字节，bit0代表Self-Powered。0为Bus Powered，1为Self Powered。因为我已确认过Descriptor里面的供电方式早就改好了。所以怀疑MX生成的时候不止一处影响到供电状态。后来查找库函数对GET_STATUS请求的相应函数，这才发现头文件usbd_conf.h里面有一个宏定义
#define USBD_SELF_POWERED 0
两个工程中的值是不同的。有问题的工程，值是0，新生成的工程则是1。修改后测试，故障排除。
这个案例暴露出我对STM32库函数和USB协议二者都不够熟悉，还是得多进修。
of123 2018-12-05
- 打赏
- 举报
如果你定义为子类 1，就要提交 Boot Interface Descriptors。见 HID 规范的附录 B。
of123 2018-12-05
- 打赏
- 举报
你是否在设备描述符中定义了子类 1 —— 可引导设备？试试将子类改为 0。
HID 规范是这样规定的：
4.2 Subclass
During the early development of the HID specification, subclasses were intended
to be used to identify the specific protocols of different types of HID class
devices. While this mirrors the model currently in use by the industry (all devices
use protocols defined by similar popular devices), it quickly became apparent that
this approach was too restrictive. That is, devices would need to fit into narrowly
defined subclasses and would not be able to provide any functionality beyond that
supported by the subclass.
The HID committee agreed on the improbability that subclass protocols for all
possible (and yet to be conceived) devices could be defined. In addition, many
known devices seemed to straddle multiple classifications—for example,
keyboards with locators, or locators that provided keystrokes. Consequently, the
HID class does not use subclasses to define most protocols. Instead, a HID class
device identifies its data protocol and the type of data provided within its Report
descriptor.
The Report descriptor is loaded and parsed by the HID class driver as soon as the
device is detected. Protocols for existing and new devices are created by mixing
data types within the Report descriptor.
Note: Because the parser for the Report descriptor represents a significant
amount of code, a simpler method is needed to identify the device protocol for
devices requiring BIOS support (Boot Devices). HID class devices use the
Subclass part to indicate devices that support a predefined protocol for either
mouse devices or keyboards (that is, the device can be used as a Boot Device).
The boot protocol can be extended to include additional data not recognized by
the BIOS, or the device may support a second preferred protocol for use by the
HID class driver.
The bInterfaceSubClass member declares whether a device supports a boot
interface, otherwise it is 0.
Subclass Codes
Subclass Code Description
0 No Subclass
1 Boot Interface Subclass
2 - 255 Reserved
HID 规范是这样规定的：
4.2 Subclass
During the early development of the HID specification, subclasses were intended
to be used to identify the specific protocols of different types of HID class
devices. While this mirrors the model currently in use by the industry (all devices
use protocols defined by similar popular devices), it quickly became apparent that
this approach was too restrictive. That is, devices would need to fit into narrowly
defined subclasses and would not be able to provide any functionality beyond that
supported by the subclass.
The HID committee agreed on the improbability that subclass protocols for all
possible (and yet to be conceived) devices could be defined. In addition, many
known devices seemed to straddle multiple classifications—for example,
keyboards with locators, or locators that provided keystrokes. Consequently, the
HID class does not use subclasses to define most protocols. Instead, a HID class
device identifies its data protocol and the type of data provided within its Report
descriptor.
The Report descriptor is loaded and parsed by the HID class driver as soon as the
device is detected. Protocols for existing and new devices are created by mixing
data types within the Report descriptor.
Note: Because the parser for the Report descriptor represents a significant
amount of code, a simpler method is needed to identify the device protocol for
devices requiring BIOS support (Boot Devices). HID class devices use the
Subclass part to indicate devices that support a predefined protocol for either
mouse devices or keyboards (that is, the device can be used as a Boot Device).
The boot protocol can be extended to include additional data not recognized by
the BIOS, or the device may support a second preferred protocol for use by the
HID class driver.
The bInterfaceSubClass member declares whether a device supports a boot
interface, otherwise it is 0.
Subclass Codes
Subclass Code Description
0 No Subclass
1 Boot Interface Subclass
2 - 255 Reserved
of123 2018-12-05
- 打赏
- 举报
USB 设备的兼容性问题，是众多厂商都头痛的。有的公司，收集几十台老旧机器做兼容性测试。
你的问题，可以通过 USB 分析仪查找故障原因。
PC 启动时，是依靠 CMOS 中存储的“硬编码”的驱动程序对 USB 设备枚举的，一般容错能力较差。
你可以用分析仪看看，对你的设备枚举执行到哪里卡住了。一般都是对某些命令没有应答，或应答错误造成的。
Windows 的启动阶段与运行阶段采用不同的运行模式，你很难在启动阶段运行软件来截获通讯信息。
用分析仪是简单直接的方法。
你的问题，可以通过 USB 分析仪查找故障原因。
PC 启动时，是依靠 CMOS 中存储的“硬编码”的驱动程序对 USB 设备枚举的，一般容错能力较差。
你可以用分析仪看看，对你的设备枚举执行到哪里卡住了。一般都是对某些命令没有应答，或应答错误造成的。
Windows 的启动阶段与运行阶段采用不同的运行模式，你很难在启动阶段运行软件来截获通讯信息。
用分析仪是简单直接的方法。
