1. 项目概述一份迟到的嵌入式USB开发“宝藏图”如果你正在或即将基于飞思卡尔Freescale现为NXP的一部分的Kinetis、ColdFire或HCS08系列微控制器进行开发并且项目涉及USB功能——无论是让设备变身成一个U盘MSD、一个虚拟串口CDC、一个人机接口设备HID还是更复杂的复合设备那么你大概率绕不开官方提供的USB协议栈。今天要深入剖析的就是其版本号为4.0.3的发布说明。这份2012年底的文档乍看只是一份陈旧的产品更新日志但对于真正扎根于这些平台的嵌入式开发者而言它更像是一张被忽略的“宝藏图”里面不仅标注了可用的资源更清晰地标出了哪些地方有“暗礁”。这份发布说明的核心价值在于它系统性地定义了Freescale USB Stack v4.0.3的生态边界。它明确告诉你这个协议栈能在哪些芯片上跑从低端的HCS08到高性能的Cortex-M4支持哪些开发环境CodeWarrior 10.x, IAR EWARM 6.40.2, Keil uVision4以及配套的评估板型号。更重要的是它用大篇幅的“已知问题与限制”和密密麻麻的支持矩阵提前为你预演了开发过程中可能遇到的绝大多数坑。例如它直言不讳地指出某些型号因内存限制无法运行主机应用某些评估板的硬件设计导致OTG功能测试受限甚至市面上一些U盘因为不严格遵守规范而可能无法被识别。这种坦诚在官方文档中尤为珍贵。对于新手这份文档是入门指南帮你快速搭建正确的开发环境避开不支持的芯片和工具链组合。对于老手它是排查问题的第一参考许多令人抓狂的“玄学”问题其根源可能早在十多年前就被记录在案。接下来我将带你逐层拆解这份文档不仅还原其内容更结合我多年使用该协议栈的经验补充那些文档里没写但至关重要的实操细节、配置原理和避坑技巧让你在嵌入式USB开发的道路上走得更稳。2. 核心更新解析v4.0.3到底改了什么每次版本迭代修复和新增的功能都直接反映了官方对稳定性和应用场景的侧重。v4.0.3作为一个维护版本其更新日志看似简短但每一条都关乎项目的稳定性。2.1 MSD主机栈与文件系统修复这是v4.0.3最实用的更新之一。“MSD host stack, MSD and FAT File System example fixes”这句话背后是针对大容量存储设备如U盘读写稳定性的重要提升。在嵌入式系统中实现USB主机读取U盘是一个高频需求但也极易遇到兼容性问题。早期的协议栈版本在处理某些非标准U盘或进行频繁文件操作时可能会发生卡死、数据错误或无法识别的问题。注意这里的“修复”往往是针对特定案例的。官方不会列出所有修复的bug细节这意味着你从更旧版本迁移项目时如果遇到MSD相关的不稳定现象升级到v4.0.3是首要步骤。但别指望它能解决所有U盘兼容性问题文档后面的“已知问题”部分明确指出了市场U盘质量参差不齐的现实。2.2 96MHz系统时钟支持“Enable support for the 96MHz system clock for the supporting Kinetis parts.” 这一条关乎性能和时钟配置的灵活性。USB协议对时钟精度有严格要求通常需要0.25%以内的精度许多USB PHY物理层接口的时钟来源于内核或系统时钟。Kinetis部分型号支持多种时钟配置方案96MHz是一个常见的高性能运行频率。在协议栈中USB模块的时钟配置例如USB DCD模块的时钟分频设置需要与实际的系统时钟匹配。如果协议栈底层代码没有适配96MHz强行使用可能会导致USB通信根本无**常建立或者数据传输速率错误。这个更新意味着官方在底层驱动中增加了对该频率的配置支持开发者在使用96MHz作为系统主频时无需再手动修改底层时钟初始化代码直接使用协议栈提供的配置即可降低了因时钟配置错误导致开发受阻的风险。2.3 Processor Expert组件继承架构重构“Processor Expert components inheritance re-architecture” 这条更新对于使用Processor ExpertPE图形化配置工具的开发者影响深远。PE是飞思卡尔/恩智浦提供的一款强大的代码生成工具可以通过拖拽组件和配置参数来生成底层驱动代码。USB协议栈为其提供了对应的组件如USB_LLD, USB_Device, USB_Host等。“继承架构重构”通常意味着优化了组件之间的依赖关系和代码组织结构。在重构前可能存在着组件耦合过紧、生成代码冗余或配置项混乱的问题。重构后可能会带来以下好处更清晰的配置流程组件属性页可能被重新分类父子组件关系更明确。更高效的生成代码减少了不必要的代码重复生成的代码更简洁。更好的可维护性为后续增加新功能或支持新芯片奠定了基础。实操心得如果你是从旧版本PE项目升级遇到组件错误或配置丢失很可能就是由于这次重构。稳妥的做法是不要直接覆盖旧项目。而是新建一个v4.0.3协议栈下的PE工程重新配置组件再将你的应用层逻辑迁移过去。虽然麻烦但能避免很多因架构变化引发的深层兼容性问题。3. 开发环境与硬件平台全览选择正确的工具和硬件是项目成功的基石。这份发布说明详细列出了经过测试的组合这是你的“安全清单”。3.1 三大IDE支持深度解析协议栈官方支持CodeWarrior 10.2/10.3、IAR EWARM 6.40.2和Keil uVision4 4.50。这不仅仅是“能用”而是指提供的示例工程、库文件编译配置和调试设置都针对这些版本进行了适配。CodeWarrior (CW) 10.x这是飞思卡尔自家的IDE对Kinetis, ColdFire, HCS08全系列支持最原生、最全面。在v4.0.3中它依然是唯一支持HCS08平台的IDE。其优势在于与Processor Expert工具集成度最高配置生成最方便。缺点是软件相对庞大且后续版本已停止更新。IAR Embedded Workbench for ARM在ARM Cortex-M内核的Kinetis芯片上IAR以其高效的编译器著称。v4.0.3支持到6.40.2版本。如果你追求极致的代码体积和运行效率IAR通常是比CW更好的选择。需要注意IAR项目的链接脚本.icf文件和启动文件需要正确配置堆栈大小因为USB协议栈会动态分配内存。Keil uVision4这是ARM开发领域的另一个巨头支持MDK-ARM编译器。v4.0.3支持到4.50版本。Keil的优势在于庞大的用户群和丰富的中间件生态。选择Keil通常是因为团队熟悉或项目历史原因。避坑指南切勿随意升级IDE版本。例如文档支持Keil uVision4 4.50如果你使用Keil5虽然可能通过迁移工程编译通过但可能会遇到微妙的兼容性问题如特定的编译器优化导致USB中断时序错乱。最保险的做法是在虚拟机或独立环境中保留文档指定的IDE版本用于该协议栈开发。3.2 评估板矩阵你的硬件“白名单”文档列出了长达数十款的评估板从FREEDOM-KL25Z到TWR-K70FN1M。这份列表的意义在于硬件电路已验证板载的USB接口电路包括D/D-走线、阻抗匹配、电源管理设计是符合规范的。示例工程可直用协议栈包中针对这些板子的示例工程其引脚定义、时钟初始化、LED/按键配置都是开箱即用的。调试有参照当你的自制硬件出现USB问题时以先用对应的评估板运行示例程序快速定位是软件问题还是硬件设计问题。例如对于TWR-K70FN1M这块高性能板卡文档特别指出其高速USBUSB 2.0 High-Speed和EHCI支持需要搭配TWR-SER2扩展板因为K70芯片本身可能只集成了USB控制器而高速PHYUSB3300 ULPI收发器在扩展板上。如果你忽略这一点直接连接高速模式根本无法工作。3.3 桌面与目标系统要求这部分内容看似简单但常被忽视。文档指出“系统要求由开发工具决定”并推荐了2GHz处理器、2GB内存的配置。对于现代电脑这似乎不是问题但如果你在资源紧张的虚拟机中运行这些老版本IDE特别是CodeWarrior可能会遇到编译缓慢、软件卡顿的情况。对于嵌入式目标平台文档强调“没有超出每块板子运行所需电源、电缆、跳线设置等的特殊要求”。这其实是在提醒开发者USB通信对电源质量非常敏感。很多DIY板子USB不稳定的罪魁祸首就是电源纹波过大。务必确保你的目标板在USB枚举和传输数据时供电电压稳定、干净。使用评估板时也要注意其跳线是否将USB口正确连接到目标MCU而不是其板载的调试器USB口。4. 协议栈内容结构与深度解读解压Freescale USB Stack的发布包你会看到一个结构清晰的目录树。理解这个结构是高效利用这份资源的前提。4.1 目录结构解析通常其根目录下会包含以下几个关键文件夹\docs或\Documentation存放所有用户手册和API参考即文档中提到的USBAPIRM.pdf,USBUG.pdf等。这是你的首要学习资料。\src协议栈的核心源代码。通常按device,host,otg以及class如cdc,hid,msd和driver硬件抽象层进行组织。切忌直接修改这里的文件除非你完全理解其影响。\examples或\demo_apps针对不同评估板和USB类别的示例工程。这是你学习的起点和调试的参照。\tools或\utilities可能包含一些测试工具、脚本或PC端辅助程序。\cw10,\iar,\keil针对不同IDE的工程文件和工作区文件。4.2 用户文档指南文档中列举的7份PDF是黄金资料USBAPIRM.pdf / USBHOSTAPIRM.pdf / USBOTGAPIRM.pdf这是API参考手册字典级别的存在。开发时需常备查询每个函数的参数、返回值和使用上下文。USBUG.pdf / USBHOSTUG.pdf / USBOTGUG.pdf这是用户指南教科书级别的存在。建议通读它讲解了协议栈的架构、初始化流程、数据流模型和典型编程模式。特别是USBUG.pdf对于设备栈开发至关重要。USBHWCONFIG.pdf硬件配置指南。详细说明了如何为不同的评估板和芯片配置USB相关的引脚、时钟、中断等。当你移植到自定义硬件时这份文档是硬件驱动层配置的绝对依据。USBPEXQSG.pdfProcessor Expert组件快速入门指南。如果你使用PE这是必读的它能帮你快速上手图形化配置USB功能。经验之谈不要只看示例代码。很多深层机制和配置约束都在用户指南里。我曾遇到过USB设备在某些主机上枚举失败的问题最后在USBUG.pdf里找到关于设备描述符配置的细微要求才得以解决。养成“编码前翻指南”的习惯。5. 设备、主机与OTG支持矩阵精讲文档第6章的表格是核心信息的高度浓缩它明确回答了“我的芯片我的需求我的工具”这个组合是否被支持。5.1 设备Device模式支持设备模式即MCU作为从设备如U盘、鼠标、串口适配器。矩阵横向是芯片型号纵向是USB设备类。HCS08系列仅支持CDC、HID、Audio、DFU、MSD、PHDC且仅支持CodeWarrior。由于HCS08内存和性能有限不支持复杂的Battery Charging检测和Host模式。ColdFire系列支持类别更全但Battery Charging仅在MCF51JF128上支持。这通常是因为该功能需要特定的硬件检测电路DCD模块。Kinetis系列支持最全面覆盖所有主流类别且三大IDECW, IAR, Keil都支持。这是飞思卡尔当时主推的ARM Cortex-M平台。关键点解读“N/A”表示该芯片硬件不支持此功能。例如L2KKinetis L系列没有DCD模块故不支持Battery Charging。IDE缩写CW 10.x指CodeWarrior 10.xIAR EW 6.X指IAR Embedded Workbench for ARM 6.xuV 4.x指Keil μVision 4.x。矩阵告诉你对于MK20DX256VLL7芯片的CDC设备应用你可以选择CW、IAR或Keil中的任意一个来开发。5.2 主机Host模式支持主机模式即MCU作为主机去连接和管理USB设备如读取U盘。HCS08明确标注“No host applications... due to memory limitations”。因其RAM和Flash太小无法承载相对复杂的主机协议栈和文件系统。ColdFire Kinetis支持CDC、HID、Audio、MSD、PHDC以及FAT FS文件系统。注意FAT FS是主机模式下访问U盘所必需的。兼容性警告再次强调MSD主机应用对U盘的兼容性不是100%取决于U盘本身对规范的遵守程度。5.3 On-The-Go (OTG) 模式支持OTG模式允许设备在主机和设备角色间动态切换。支持面最窄仅Kinetis部分型号和ColdFire的MCF51JF/JM系列支持且仅限HID和MSD两类应用。这是因为OTG协议更复杂需要额外的ID引脚检测和VBUS电源管理电路如文档提到的MAX3353芯片支持。重要限制文档特别指出TWR-K20DX50评估板因为D/D-线路直接硬连接到板载微型USB接口未使用MAX3353电荷泵电路因此其OTG和DCD功能未经过该电路方案测试。这意味着如果你基于此板做OTG需要自行验证硬件设计或参考其他包含MAX3353电路的板子设计。6. 已知问题与限制的实战应对这是整份文档最具“干货”的部分它几乎预见了开发者会遇到的所有主要难题。6.1 内存限制与动态分配问题描述“Because of dynamic memory allocation needs, the limited SRAM available on some devices might not be sufficient to run some host and On-The-Go applications.”原理剖析USB主机协议栈在枚举设备、创建管道、处理传输时需要动态分配内存堆内存。对于SRAM只有几KB的低端型号如某些HCS08、ColdFire V1可能刚刚够设备栈运行但绝对无法承载主机栈。实操应对选型阶段如果项目必须使用主机功能在芯片选型时就要将SRAM大小作为关键指标。对于Kinetis L系列如KL25Z有16KB RAM运行简单的主机应用如读取HID设备是可行的但同时运行FAT文件系统读取大容量U盘就会很紧张。配置优化在IDE中加大堆heap空间。以IAR为例需要在链接配置文件.icf中调整HEAP_SIZE。在Keil中需要在启动文件或散列文件中定义堆大小。内存诊断使用工具监控堆内存使用情况防止内存碎片化导致分配失败。可以考虑使用协议栈提供的静态配置选项如果存在替代部分动态分配。6.2 U盘兼容性问题问题描述文档举了U盘不遵守规范的多种情况如MSD类协议不符、FAT格式签名错误、存在隐藏分区、上电就绪时间超规等。实战策略采购清单为项目测试准备一个“经过验证的U盘清单”。购买一些主流品牌如SanDisk, Kingston的经典型号非最新款作为测试基准。增强鲁棒性在代码中对USB命令的返回值做更严格的检查并增加重试机制。例如发送SCSI INQUIRY命令失败后不是立即报错而是延迟几百毫秒重试一到两次。日志输出在调试阶段将USB枚举和MSD初始化的关键步骤信息通过串口打印出来。当某个U盘失败时通过日志可以清晰看到是在发送TEST_UNIT_READY命令时超时还是在读取BPBBIOS参数块时发现异常签名从而针对性处理。格式化工具要求终端用户使用Windows系统自带的格式化工具选择FAT32格式分配单元大小默认来格式化U盘避免使用第三方工具产生非标准分区。6.3 RAM Disk配置陷阱问题描述“The RAM Disk support in the MSD Device applications must be tailored to the available RAM...”问题本质在MSD设备示例中模拟U盘的功能通常是在SRAM中划出一块区域作为虚拟磁盘。LENGTH_OF_EACH_LBA每个逻辑块地址的字节数通常是512和TOTAL_LOGICAL_BLOCKS_ADDRESS总逻辑块数的乘积决定了这个虚拟磁盘的大小。致命错误如果这个大小设置得超过了芯片的可用SRAM会导致内存溢出程序行为不可预测甚至无法启动。正确配置首先明确你的芯片有多少可用SRAM扣除协议栈、全局变量、堆栈占用。在disk.h中确保(LENGTH_OF_EACH_LBA * TOTAL_LOGICAL_BLOCKS_ADDRESS) 可用SRAM并留出足够余量。例如KL25Z有16KB RAM协议栈和系统可能占用4-6KB那么RAM Disk最多只能设置10KB左右即大约20个LBA10*1024 / 512。6.4 Processor Expert生成代码的手动修改这是最“硬核”的一个已知问题文档给出了具体的代码修改步骤。这是因为早期PE工具生成的代码在结构体内存对齐pack和状态机处理上存在瑕疵。修改1 2结构体打包#pragma pack目的是确保LDD_USB_Device_TTD_Head和USB_LDD_TTD_Struct这两个结构体以1字节对齐方式编译。如果不这样做在特定编译器和优化选项下结构体成员之间可能会有填充字节padding导致协议栈访问成员时错位引发数据损坏或硬件异常。修改方法就是分别在PE_LDD.h和USB_LDD.c文件中找到这两个结构体定义在其前后加上#pragma pack(1)和#pragma pack()。修改3中止所有传输的回调函数清零在USB_LDD_DeviceDisableAllEp函数的循环中添加对CallbackFnPtr的清零。这是为了防止在禁用端点后残存的回调函数指针被错误调用。这是一个安全性和稳定性的补丁。修改4OTG状态机条件修正在USB_LDD_OtgStateMachine函数的LDD_USB_OTG_A_WAIT_VFALL状态中修正条件判断。原始代码可能存在逻辑错误导致状态无法正确迁移。这个修改确保了OTG角色切换逻辑的正确性。血泪教训务必逐字核对并应用这四项修改。我曾因遗漏了第三处修改导致设备在频繁插拔时偶尔发生死机调试了整整两天才定位到这个文档中已写明的问题。建议将这份修改清单作为你使用v4.0.3协议栈PE组件的标准操作流程SOP的一部分。7. 嵌入式USB开发入门实战指引基于这份发布说明和协议栈一个典型的USB设备开发流程如下我们以在TWR-K60N512评估板上实现一个CDC虚拟串口为例。7.1 环境搭建与工程导入获取资源从NXP官网下载Freescale USB Stack v4.0.3完整包。同时安装好CodeWarrior 10.6或文档指定的版本。选择示例在协议栈的examples目录下找到TWR-K60N512子文件夹再进入cdc或device_cdc目录。打开工程用CodeWarrior打开cw10目录下的工程文件.mcp。理解工程结构浏览工程中的文件通常包含main.c应用入口初始化硬件和协议栈。app.c/h应用层任务处理USB事件如连接、断开、数据接收。usb_descriptor.c重中之重包含设备描述符、配置描述符、接口描述符、端点描述符等。这是USB设备与主机“对话”的语言。协议栈库文件。7.2 关键配置点详解时钟配置在main.c的硬件初始化部分确认系统时钟、核心时钟、总线时钟设置正确并且USB模块的时钟源通常来自PLL被正确使能和分频最终为USB模块提供准确的48MHz或60MHz时钟取决于芯片。引脚复用确认USB的DPD和DMD-引脚被正确配置为USB功能而非普通的GPIO。这通常在引脚控制模块PORT的初始化中完成。描述符定制在usb_descriptor.c中你需要修改USB_DEVICE_DESCRIPTOR厂商IDidVendor、产品IDidProduct、设备版本号bcdDevice。切勿使用示例中的默认ID应向USB-IF申请或使用测试用的PID/VID。USB_CONFIGURATION_DESCRIPTOR配置供电模式总线供电/自供电、最大电流bMaxPower单位2mA。USB_INTERFACE_DESCRIPTOR接口类bInterfaceClass、子类、协议。对于CDC这里是0x02Communications and CDC Control。端点描述符指定用于数据传输的端点号、方向、类型控制/中断/批量、最大包大小。7.3 数据收发流程剖析CDC设备通常包含两个接口一个控制接口用于管理和一个数据接口用于传输数据。数据接口使用Bulk端点。发送数据设备-主机应用层准备好数据。调用协议栈API如USB_Class_CDC_Send_Data(endpoint_num, buffer, length)。协议栈将数据填入端点对应的FIFO并启动传输。传输完成后协议栈会调用你预先注册的回调函数通知你发送完成。接收数据主机-设备在初始化时你需要为接收端点IN端点预先提交一个接收请求USB_Class_CDC_Recv_Data。当主机发送数据过来硬件触发中断协议栈底层驱动将数据从FIFO搬移到你提供的缓冲区。数据接收完成后协议栈调用你的接收完成回调函数。在回调函数中处理数据并必须立即重新提交一个接收请求以准备接收下一包数据。这是流式传输不中断的关键。7.4 调试技巧与心得串口日志是你的眼睛在项目初期务必保留一个硬件串口用于打印调试信息。将USB枚举的关键步骤如USB_Init调用、描述符获取、配置设置状态打印出来。使用Bus Hound或USBlyzer在PC端使用USB协议分析软件。当你的设备插入电脑时这些软件可以捕获所有USB通信数据包。你可以清晰地看到主机发送了哪些标准请求如GetDescriptor, SetConfiguration你的设备返回了什么从而快速定位是描述符错误还是请求响应错误。从官方示例开始小步修改不要一开始就试图从头创建工程。以最接近你需求的官方示例为基础每次只修改一个地方比如先改个PID/VID测试枚举是否成功测试通过后再进行下一步。注意端点缓冲区大小端点描述符中的wMaxPacketSize必须与芯片USB模块该端点实际FIFO大小匹配且不能超过USB规范对该速度等级的限制全速批量端点最大为64字节。设置错误会导致数据截断或传输失败。电源管理如果是总线供电设备在描述符中声明的最大电流bMaxPower不能超过USB规范通常500mA且要确保你的板子实际功耗接近此值。过大会导致某些主机端口过流保护。8. 常见问题排查与解决方案实录即使严格按照指南操作在实际开发中仍会遇到各种问题。以下是我在多个项目中遇到的典型问题及解决思路。问题现象可能原因排查步骤与解决方案设备插入电脑无反应无提示音设备管理器无变化1. 硬件连接问题VBUS未供电D/D-接反或短路2. 芯片USB模块时钟未使能或频率错误3. 芯片未运行程序或程序卡死在初始化前段1. 用万用表测量USB接口VBUS是否有5VD/D-对地电阻是否正常非短路。2. 检查代码中USB外设时钟门控如SIM_SCGC4电脑提示“无法识别的USB设备”或“设备描述符请求失败”1. 设备描述符格式错误或内容非法2. 端点0控制端点的FIFO或缓冲区设置错误3. 设备响应描述符太慢超时1. 使用Bus Hound捕获通信过程看主机发出的第一个GetDescriptor(Device)请求你的设备是否回复回复的数据是否与代码中定义的一致。重点检查描述符总长度、类型、字段值。2. 检查芯片手册确认控制端点EP0的收发缓冲区大小和地址配置正确。3. 在GetDescriptor请求的处理函数中加入延时模拟或优化代码确保在规定时间USB规范要求内响应。枚举成功但驱动安装失败黄色感叹号1. PC端缺少对应的驱动程序如自定义CDC驱动2. 设备提供的兼容IDCompatible ID不匹配3. 设备返回的字符串描述符如厂商字符串、产品字符串编码错误1. 对于CDC类Windows通常内置驱动usbser.sys。检查设备管理器详细信息查看硬件ID。确保你的设备描述符中的类/子类/协议码bDeviceClass/bDeviceSubClass/bDeviceProtocol与驱动期望的一致。2. 对于HID类通常无需额外驱动。检查报告描述符是否正确。3. 确保字符串描述符使用Unicode编码UTF-16LE且第一个字节为长度和类型。批量传输数据不稳定时快时慢或丢包1. 端点FIFO大小小于主机发送的包大小2. 应用层处理数据太慢导致端点NAK未就绪过多3. 未及时重新提交接收请求4. 中断被长时间关闭影响USB中断响应1. 确认wMaxPacketSize设置正确且应用层缓冲区足够大。2. 优化应用层代码提高数据处理速度。或者使用双缓冲Ping-Pong Buffer机制在一个缓冲区被应用处理时另一个缓冲区用于接收新数据。3.确保在接收回调函数的最后立即调用Recv_Data提交新的接收请求。4. 避免在中断服务程序ISR或高优先级任务中进行长时间操作影响USB中断的及时响应。使用Processor Expert生成代码编译通过但运行异常1. 未应用文档中提到的4处手动代码修改2. PE组件配置有误如时钟源、引脚分配3. 生成的初始化代码顺序与硬件要求不符1.首先核对并完成“已知问题”章节中的4项代码修改这是最常见的原因。2. 在PE中仔细检查USB组件属性时钟配置、VBUS检测使能、DP/DM引脚选择等。3. 对比PE生成的初始化代码和官方纯代码示例的初始化顺序必要时在main()中调整初始化调用顺序如先初始化时钟再初始化USB模块。最后嵌入式USB开发是一个对细节要求极高的领域。这份Freescale USB Stack v4.0.3的发布说明连同其完整的协议栈和示例提供了一个坚实且经过验证的起点。它的价值不仅在于其实现的功能更在于它明确划定的边界和坦诚指出的陷阱。我的经验是成功的关键在于三点严格遵循硬件参考设计、透彻理解协议栈的API和回调机制、以及善用工具进行分层调试硬件测试、协议分析、日志输出。当你遇到问题时第一反应应该是回到这份文档和对应的用户指南USBUG.pdf中寻找线索而不是盲目地在网上搜索。很多时候答案早已写在里面。