USB设备控制传输：自动解码与非解码机制详解与固件开发实践-拓冰建站

1. USB控制传输：设备通信的“指挥中心”

搞嵌入式USB设备开发，尤其是涉及到USB设备控制器（UDC）的固件编写，控制传输（Control Transfer）绝对是一个绕不开的核心话题。你可以把它想象成USB设备与主机之间进行“高层对话”的专用通道。所有关于设备身份识别（“你是谁？”）、能力配置（“你能干什么？”）、状态管理（“你现在状态如何？”）的关键指令，都通过这条通道来传递。对于任何一个USB设备，从插入主机到被识别、配置、再到正常工作，这一系列“握手”和“谈判”过程，绝大部分都依赖于控制传输在端点0（Endpoint 0）上完成。

为什么它如此重要？因为控制传输是USB协议中唯一一种保证传输可靠性的类型，它自带错误检测和重传机制。更重要的是，它的结构是标准化的：一个控制传输必然包含Setup阶段、可选的Data阶段和Status阶段。这种结构化的对话方式，确保了主机和设备能准确无误地理解彼此的意图。然而，对于设备端的微处理器（MPU）来说，处理这些请求意味着中断响应、数据搬运、状态判断等一系列操作，会消耗宝贵的CPU周期和内存带宽。

于是，USB设备控制器的设计者们引入了一个非常巧妙的分工机制：自动解码和非自动解码。简单来说，就是把控制传输请求分成了“简单家务”和“复杂任务”两类。像“设置地址”（SET_ADDRESS）、“获取设备状态”（GET_STATUS）这类标准、固定、频繁发生的“简单家务”，就交给硬件控制器（也就是“自动解码”机制）去自动完成，MPU完全不用操心。而像“设置配置”（SET_CONFIGURATION）、“获取描述符”（GET_DESCRIPTOR）这类需要根据设备具体功能来定制的“复杂任务”，则交给MPU（也就是“非自动解码”机制）来灵活处理。

理解这两种机制的运作细节、中断行为、握手信号（ACK/NAK/STALL）的产生时机，以及MPU需要介入的精确时刻，是写出稳定、高效USB设备固件的关键。这不仅能帮你优化系统资源，更能让你在调试那些令人头疼的枚举失败、配置错误问题时，快速定位到是硬件自动处理环节出了岔子，还是你自己的固件逻辑有bug。接下来，我们就深入拆解这两种机制，看看硬件和软件是如何协同完成这场精密对话的。

2. 自动解码控制传输：硬件驱动的“自动驾驶”

自动解码（Autodecoded）控制传输，是USB设备控制器为减轻MPU负担而设计的一种硬件加速机制。当主机发来的控制请求属于USB规范中定义明确、处理逻辑固定的标准请求时，控制器硬件能够自行识别、解析并完成整个传输过程，全程无需MPU参与。这极大地提升了设备对某些关键请求的响应速度，并显著降低了MPU的中断负载。

2.1 核心原理与涵盖的请求类型

其核心原理在于，USB设备控制器内部集成了一个“解码器”模块。当SETUP令牌包到达端点0时，该模块会实时监控紧随其后的数据包（即8字节的Setup数据），并对其进行解码。解码的内容主要是bmRequestType、bRequest、wValue、wIndex和wLength这几个字段。如果解码后发现这是一个预定义的、支持自动解码的请求，硬件就会接管后续的所有事务处理。

那么，哪些请求会被自动解码呢？根据USB 1.1规范及常见控制器的实现，主要包括以下几类：

SET_ADDRESS（设置地址）：这是设备枚举过程中最关键的一步。主机分配一个唯一的地址给设备。硬件自动解码此请求后，会直接将新地址写入内部的设备地址寄存器。一个关键细节是：SET_ADDRESS请求的生效时刻是在其状态阶段（Status Stage）完成之后，即使状态阶段没有以ACK握手结束（例如发生错误），新地址也会生效。这确保了设备地址切换的原子性。
GET_STATUS（获取状态）：用于查询设备、接口或端点的状态。对于设备和端点（限端点0）的GET_STATUS请求，通常是自动解码的。硬件直接从内部状态寄存器（如DEVSTAT.R_WK_OK表示远程唤醒使能，SYSCON1.SELF_PWR表示自供电状态）中读取信息，并在数据阶段自动返回。
CLEAR_FEATURE / SET_FEATURE（清除/设置特性）：用于操作特定的特性。对于设备级的特性（如远程唤醒），硬件可以自动解码并设置/清除对应的寄存器位（如DEVSTAT.R_WK_OK）。对于接口级的特性，由于USB 1.1规范未定义接口特性，硬件会自动回复STALL。对于端点级的特性（如清除端点Halt），这通常属于非自动解码范畴，需要MPU干预。

注意：一个请求是否被自动解码，有时可以通过控制器的配置寄存器（如AUTODEC_DIS）来禁用。但通常对于上述标准请求，默认是使能的。硬件自动解码的判断逻辑非常严格，如果Setup数据包中的PID（包标识符）不是DATA0，或者CRC校验错误，整个事务会被直接忽略，不会产生任何中断，也不会进入自动解码流程。

2.2 事务流程与握手信号全解析

自动解码传输的事务流程非常简洁，因为MPU被完全“屏蔽”在外。我们以最常见的自动解码控制写传输（如SET_ADDRESS）和自动解码控制读传输（如GET_STATUS for device）为例，结合图表来剖析其信号流。

自动解码控制写传输（成功情况）：

[Setup Stage] 主机 -> 设备: SETUP Token + DATA0 (8字节Setup数据) 设备 -> 主机: ACK Handshake （硬件自动解码Setup数据，识别为SET_ADDRESS等请求） [Status Stage] 主机 -> 设备: IN Token 设备 -> 主机: DATA1 (0长度数据包) + ACK Handshake

整个过程中，没有MPU中断产生，状态标志位也不会更新。硬件在状态阶段自动提供一个零长度的数据包（对于控制写传输，状态阶段是IN事务）并完成ACK握手。如果Setup数据或令牌包有错误，硬件会忽略该事务，不回复任何握手包。

自动解码控制读传输（成功情况）：

[Setup Stage] 主机 -> 设备: SETUP Token + DATA0 (8字节Setup数据) 设备 -> 主机: ACK Handshake （硬件自动解码，识别为GET_STATUS等请求，并从内部寄存器准备数据） [Data Stage] 主机 -> 设备: IN Token 设备 -> 主机: DATA1 (包含状态数据的包) + ACK Handshake [Status Stage] 主机 -> 设备: OUT Token + DATA1 (0长度数据包) 设备 -> 主机: ACK Handshake

同样，全程无MPU中断。硬件在数据阶段自动从内部寄存器取出数据（例如设备状态字）发送给主机，并在状态阶段对主机发来的零长度数据包回复ACK。

自动解码传输的错误处理：硬件同样负责错误处理。如果主机发送的请求参数非法（例如，GET_STATUS请求了一个不存在的端点），自动解码机制会在数据阶段或状态阶段强制发出STALL握手信号，告知主机请求无法完成。这个STALL也是由硬件自动产生的，MPU不会感知到这次失败的请求。

2.3 MPU的“旁观者”角色与设计优势

在自动解码传输进行时，MPU在做什么？答案是：什么也不用做，可以继续处理其他任务。MPU不会收到任何与此次传输相关的中断（IRQ_SRC.SETUP,IRQ_SRC.EP0_TX,IRQ_SRC.EP0_RX均不会置位）。控制器的CTRL.SET_FIFO_EN、SYSCON2.STALL_CMD等用于控制握手信号的位，在自动解码过程中也完全不起作用。

这种设计带来了显著优势：

低延迟：硬件响应速度远快于软件中断处理。
低开销：节省了MPU用于响应中断、读取FIFO、解析请求、设置握手信号的大量CPU时间。
高可靠性：硬件处理逻辑固定，避免了软件可能引入的时序错误或逻辑漏洞。

实操心得：在调试USB枚举过程时，如果发现设备地址无法设置，或者主机反复获取设备状态失败，在排除了线路问题后，首先应该怀疑自动解码硬件逻辑或相关寄存器（如地址寄存器）是否正常工作。因为这部分MPU无法干预，所以需要仔细检查控制器的初始化配置和电源状态。一个常见的坑是，设备可能没有正确进入默认（Default）或地址（Addressed）状态，导致自动解码逻辑未被激活。

3. 非自动解码控制传输：MPU主导的“手动驾驶”

当控制请求超出了硬件自动解码的范围，就需要MPU亲自上阵，这就是非自动解码（Non-Autodecoded）控制传输。这类请求通常更复杂，需要设备根据自身特性进行定制化响应，例如提供描述符、设置配置、选择接口等。处理这类传输，是USB设备固件开发的核心工作，要求开发者深刻理解USB协议和控制器的协同工作机制。

3.1 核心流程与MPU的职责

非自动解码传输严格遵循Setup-Data-Status三阶段模型，且每个阶段的事务都可能触发MPU中断，要求MPU执行特定操作。整个流程就像一场MPU与硬件控制器之间的精密舞蹈。

3.1.1 Setup阶段：请求的接收与解析

一切始于一个SETUP事务。主机发送SETUP令牌包和8字节的Setup数据。USB控制器硬件会做两件事：1）自动回复ACK握手（如果数据包有效）；2）将Setup数据存入一个专用的Setup FIFO，并产生一个Setup中断（IRQ_SRC.SETUP标志置位）。

MPU的中断服务程序（ISR）必须立即响应：

选择Setup FIFO：通过设置EP_NUM.SETUP_SEL位来“锁定”当前的Setup数据，并清除IRQ_SRC.SETUP中断标志。
读取并解析数据：从DATA寄存器连续读取8字节数据。这8个字节定义了bmRequestType（请求方向、类型、接收方）、bRequest（具体请求代码）、wValue、wIndex和wLength。
防丢失检查：在清除EP_NUM.SETUP_SEL位后，必须再次检查IRQ_SRC.SETUP标志。如果它又被置位，说明一个新的Setup包在MPU处理期间到达了（这是符合USB规范的）。此时，MPU必须丢弃刚刚读出的旧数据，重新开始处理新的Setup包。这是实现可靠通信的关键一步。
请求分类与准备：解析请求后，MPU需要判断这是控制读（如GET_DESCRIPTOR）还是控制写（如SET_CONFIGURATION）。
- 控制读：MPU需要根据请求，准备要返回的数据（例如从ROM中读取描述符），并将第一段数据（至少能填满一个数据包）写入端点0的TX FIFO，然后使能TX FIFO（设置CTRL.SET_FIFO_EN），告知硬件“数据已就绪，可以发送”。
- 控制写：MPU只需简单地使能端点0的RX FIFO（设置CTRL.SET_FIFO_EN），准备接收主机在数据阶段发来的数据。

3.1.2 Data阶段：数据的交换

数据阶段可能包含零次、一次或多次IN/OUT事务，具体取决于Setup数据中的wLength字段和实际数据量。

控制读（IN事务）：
1. 主机发送IN令牌。
2. 硬件检查TX FIFO使能状态和是否有数据。如果一切就绪，硬件自动将FIFO中的数据发出，并回复ACK给主机。
3. 数据发送完成后，硬件产生一个端点0 TX中断（IRQ_SRC.EP0_TX）。
4. MPU在TX中断服务程序中，需要检查是否还有剩余数据要发送。如果有，则继续写入TX FIFO并重新使能；如果所有数据都已发送完毕，则MPU需要为接下来的状态阶段做准备。
控制写（OUT事务）：
1. 主机发送OUT令牌和数据包。
2. 硬件检查RX FIFO使能状态。如果使能且FIFO有空间，硬件接收数据并回复ACK。
3. 数据接收完成后，硬件产生一个端点0 RX中断（IRQ_SRC.EP0_RX）。
4. MPU在RX中断服务程序中，必须从RX FIFO中读取数据并保存。当所有预期数据（由wLength指定）都接收完毕后，MPU需要解析这些数据并执行相应操作（如应用新的配置）。

3.1.3 Status阶段：操作的最终确认

状态阶段是主机确认整个控制传输是否成功的最后一步。

控制读传输的状态阶段是一个OUT事务，主机发送一个零长度的数据包。MPU需要通过使能RX FIFO并回复ACK，来向主机确认“读操作成功完成”。
控制写传输的状态阶段是一个IN事务，设备需要发送一个零长度的数据包。MPU通过使能一个空的TX FIFO并回复ACK，来向主机确认“写操作成功完成”。

关键点：MPU通过控制CTRL.SET_FIFO_EN位来主导状态阶段的握手。如果MPU尚未准备好（例如，控制写的数据还未处理完），它可以保持FIFO禁用，导致硬件回复NAK，主机则会重试。如果发生不可恢复的错误，MPU可以通过设置SYSCON2.STALL_CMD位，强制在状态阶段回复STALL。

3.2 关键寄存器与握手控制详解

MPU通过操控一系列寄存器来控制非自动解码传输的流程和握手信号。理解这些寄存器的用途是编写正确固件的基础。

寄存器/位	主要作用	在非自动解码控制传输中的典型操作
`IRQ_SRC.SETUP`	Setup中断标志	MPU读取Setup数据后，通过设置`EP_NUM.SETUP_SEL`来清除。
`EP_NUM.SETUP_SEL`	选择Setup FIFO	在Setup中断中设置为1，以读取数据；读取完成后必须清零。
`CTRL.SET_FIFO_EN`	使能端点0 FIFO	控制读：在Setup阶段后、Data阶段前设置为1，表示TX FIFO有数据；在Status阶段前，如果TX FIFO为空，设置为1表示发送零长度包。控制写：在Setup阶段后设置为1，准备接收Data阶段数据；在Status阶段，如果RX FIFO使能且为空，表示准备接收零长度包。
`STAT_FLG.FIFO_EN`	反映FIFO使能状态	只读标志，用于查询当前FIFO是否已被主机事务占用。
`SYSCON2.STALL_CMD`	强制STALL命令	当MPU遇到无法处理的错误时（如不支持的请求、参数错误），设置此位将导致当前及后续所有事务（直到下一个Setup包）都回复STALL。这是报告错误的标准方式。
`CTRL.SET_HALT`/`STAT_FLG.EP_HALTED`	设置/查询端点Halt状态	用于响应SET_FEATURE/CLEAR_FEATURE (ENDPOINT_HALT)请求。`STAT_FLG.EP_HALTED`反映由`CTRL.SET_HALT`引起的Halt状态，但不反映由`SYSCON2.STALL_CMD`引起的STALL。

握手信号的控制逻辑：

ACK：当FIFO使能（CTRL.SET_FIFO_EN=1）且FIFO状态就绪（TX有数据或RX有空间），并且没有强制STALL命令（SYSCON2.STALL_CMD=0）和端点Halt（STAT_FLG.EP_HALTED=0）时，硬件自动回复ACK。
NAK：当FIFO未使能（CTRL.SET_FIFO_EN=0）时，硬件回复NAK。MPU利用此机制来延迟响应，直到它准备好数据或处理完数据。
STALL：当SYSCON2.STALL_CMD=1或STAT_FLG.EP_HALTED=1时，硬件回复STALL，表示功能错误或端点被停止。一旦在控制传输中发出STALL，必须持续STALL直到下一个Setup包到来，这是USB协议的要求。

3.3 典型非自动解码请求处理实例

以最复杂的SET_CONFIGURATION请求为例，看看MPU需要完成哪些动作：

Setup阶段：MPU收到中断，读取8字节Setup数据，解析出bRequest=0x09，wValue为配置值。
判断与准备：如果配置值有效（例如为1），MPU开始准备应用新配置。
Data阶段：这是一个控制写传输，但SET_CONFIGURATION的Data阶段长度为0，所以实际上没有OUT事务。MPU在Setup阶段后使能RX FIFO即可。
状态阶段前的关键操作：在进入状态阶段之前，MPU必须完成一系列硬件状态设置：
- 复位所有端点：通过设置各个端点的CTRL.RESET_EP位，清空其FIFO，重置数据PID为DATA0。
- 配置电源状态：如果是自供电设备，根据新配置设置SYSCON1.SELF_PWR位。
- 设置未用端点为Halt：对于新配置中未使用的端点，设置其CTRL.SET_HALT位，防止主机访问。
- 更新设备状态：如果配置值非0，写SYSCON2.DEV_CFG=1使设备进入“已配置”状态；如果配置值为0，写SYSCON2.CLR_CFG=1使设备退回“已寻址”状态。这个操作会触发设备状态改变中断（DS_CHG）。
状态阶段：完成上述操作后，MPU通过使能一个空的TX FIFO（对于控制写，状态阶段是IN事务）来回复ACK，完成整个传输。

踩坑记录：一个常见的错误是，MPU在状态阶段回复ACK太快，而在ACK之后才去执行复位端点等操作。这可能导致主机在设备尚未完全准备好新配置的情况下，就发起对新端点的数据传输，从而造成通信混乱。正确的顺序必须是：在状态阶段握手完成前，完成所有必要的硬件状态配置。

4. 自动解码与非自动解码的对比与选型策略

理解了两种机制的独立运作后，将其放在一起对比，能让我们更清晰地看到USB设备控制器设计的精妙之处，并在实际开发中做出正确决策。

4.1 机制对比全景图

下面的表格从多个维度对比了两种机制的核心差异：

对比维度	自动解码控制传输	非自动解码控制传输
处理主体	USB设备控制器硬件	微处理器（MPU）固件
典型请求	SET_ADDRESS, GET_STATUS (Device/Ep0), CLEAR/SET_FEATURE (Device)	GET_DESCRIPTOR, SET_CONFIGURATION, GET/SET_INTERFACE, SET_FEATURE (Endpoint)
MPU干预	无。全程无中断，不参与任何握手和数据搬运。	深度参与。需响应Setup、Data、Status各阶段中断，进行数据读写和握手控制。
中断产生	不产生任何USB中断。	Setup阶段产生`IRQ_SRC.SETUP`中断，Data阶段产生`IRQ_SRC.EP0_TX/RX`中断，Status阶段产生相应中断。
握手控制	硬件自动完成所有ACK/NAK/STALL握手，MPU控制位无效。	MPU通过`CTRL.SET_FIFO_EN`、`SYSCON2.STALL_CMD`等寄存器间接控制握手。
错误处理	硬件自动处理。包错误则忽略；请求参数错误则在Data/Status阶段自动STALL。	MPU负责处理。通过检查数据有效性、资源情况等，在遇到错误时主动设置`SYSCON2.STALL_CMD`。
速度与开销	极快，零MPU开销。	较慢，MPU开销大（中断响应、数据搬移、协议解析）。
灵活性	无。处理逻辑固定，仅限标准请求。	高。可处理任意自定义请求（Vendor-specific）和复杂逻辑。

4.2 开发中的选型与设计考量

这种硬件/软件分工的设计，要求开发者在编写USB设备固件时，必须有清晰的边界意识。

首先，要明确“什么该管，什么不该管”。对于GET_STATUS、SET_ADDRESS这类请求，你的固件代码里不应该出现它们的处理函数。如果你在调试时发现MPU收到了这些请求的中断，那很可能意味着自动解码功能未被正确启用，或者控制器配置有误。你需要检查相关配置寄存器（如AUTODEC_DIS）以及设备的基本状态（是否已上电、时钟是否稳定）。

其次，非自动解码处理是固件复杂度的主要来源。编写这部分代码时，需要特别注意：

状态机管理：一个非自动解码传输跨越多个阶段和多次中断。固件必须维护一个清晰的状态机（例如，使用一个全局变量记录当前处于SETUP_RECEIVED、DATA_IN_PROCESSING、WAITING_STATUS等状态），以确保在正确的中断里做正确的事。
数据缓冲与分片：对于GET_DESCRIPTOR这类可能返回大量数据的请求，描述符长度可能超过端点0的最大包长（通常为8或64字节）。MPU需要实现数据分片逻辑：在Setup阶段后先填充第一包数据到TX FIFO；在后续的每个TX中断中，判断是否还有剩余数据，有则继续填充，没有则准备状态阶段。
超时与错误恢复：主机可能在任何时候（甚至在数据阶段中）发送新的Setup包，取消当前传输。固件必须能妥善处理这种“提前终止”，及时复位传输状态，准备处理新请求。IRQ_SRC.SETUP标志的二次检查机制正是为此而生。
STALL信号的正确使用：STALL是一个强错误信号。一旦发出，必须持续到下一个Setup包。对于不支持的请求（如SET_DESCRIPTOR）、无效的参数（如超出范围的接口号），应在Setup阶段解析后立即设置SYSCON2.STALL_CMD。切勿在STALL后，又错误地处理了后续事务。

性能优化提示：虽然非自动解码需要MPU处理，但可以通过优化中断服务程序来减少开销：

快速响应Setup中断：在Setup中断中，只做最必要的读取和解析，将耗时的操作（如从Flash读取大描述符）放到主循环或后台任务中。
合理使用NAK延迟：如果MPU暂时无法准备数据（例如，需要从低速存储器中读取），可以通过暂时不使能FIFO来回复NAK，为主机提供重试的机会，避免因超时导致主机错误地认为设备故障。
FIFO操作优化：使用DMA或MPU的批量加载指令来操作FIFO数据，减少单字节操作带来的开销。

5. 实战调试：常见问题排查与解决思路

理论最终要服务于实践。在实际开发中，控制传输相关的问题往往表现为枚举失败、设备无法识别或配置错误。掌握一套系统的排查方法至关重要。

5.1 问题现象与排查路径速查表

问题现象	可能原因（自动解码相关）	可能原因（非自动解码相关）	排查步骤与工具
设备插入后无反应，主机无法发现	1. 控制器电源/时钟未就绪。 2. 端点0未正确初始化。 3. 自动解码逻辑故障，SET_ADDRESS失败。	不适用（枚举早期问题）	1. 示波器/逻辑分析仪检查USB D+/D-线是否有信号。 2. 检查控制器复位、时钟、供电寄存器。 3. 监控设备地址寄存器，看SET_ADDRESS后是否变化。
主机能发现设备但获取描述符失败	通常不是主因。	1.GET_DESCRIPTOR请求处理错误：未正确使能TX FIFO；描述符数据错误或格式不对；数据分片逻辑错误。 2.中断丢失：MPU未及时响应Setup或TX中断。 3.握手错误：错误地发出了STALL。	1.抓取USB数据包：使用USB协议分析仪，查看主机发出的Setup包和设备回复的数据包、握手包，这是最直接的证据。 2.检查固件状态机：在Setup、TX中断入口加调试输出，确认是否被触发及执行顺序。 3.检查描述符内容：确保长度、类型、数据都符合USB规范。
设备枚举成功，但设置配置（SET_CONFIGURATION）后无法通信	不适用。	1.SET_CONFIGURATION处理不全：MPU未在状态阶段前复位所有端点、设置Halt状态。 2.新端点未正确初始化：配置后使用的端点其FIFO大小、类型等未设置。 3.设备状态未更新：`SYSCON2.DEV_CFG`位未设置，设备未进入Configured状态。	1. 检查SET_CONFIGURATION请求的`wValue`是否正确。 2. 在SET_CONFIGURATION的MPU处理代码中，逐步检查是否执行了端点复位(`CTRL.RESET_EP`)、Halt设置、`DEV_CFG`设置等操作。 3. 监控设备状态寄存器(`DEVSTAT.CFG`)，确认是否进入已配置状态。
主机请求被反复STALL	1. 自动解码请求参数非法（如向不存在的端点发送GET_STATUS）。	1. MPU对所有不支持的请求都错误地回复了STALL。 2. 在处理某个请求时发生错误，MPU设置了`SYSCON2.STALL_CMD`但未在下一个Setup包后清除（通常硬件会自动清除）。 3. 端点因错误被设置为Halt状态(`CTRL.SET_HALT`)。	1. 分析协议，确认主机请求是否合法。 2. 检查固件中STALL命令的设置条件，确保仅对真正错误或不被支持的请求使用。 3. 检查`STAT_FLG.EP_HALTED`位，确认端点是否被意外停止。
数据传输不稳定，偶尔超时	不常见。	1.MPU响应过慢：中断服务程序执行时间太长，导致无法及时响应Data阶段的下一个IN/OUT请求，主机因超时而放弃。 2.NAK策略不当：过度使用NAK延迟，超过了主机容忍的重试次数。 3.FIFO管理错误：Data阶段数据未及时读出或写入，导致FIFO上溢或下溢。	1.优化ISR：将非关键操作移出ISR，使用DMA。 2.测量中断延迟：使用GPIO翻转和示波器测量从中断发生到FIFO操作完成的时间。 3.调整NAK逻辑：确保在合理的时间内（如几毫秒内）能够准备好数据并回复ACK。

5.2 核心调试技巧与工具

软件仿真与调试输出：在开发初期，充分利用IDE的仿真器和调试器。在关键的中断服务程序和状态判断处设置断点，单步跟踪MPU的响应流程，观察寄存器值的变化，尤其是IRQ_SRC、EP_NUM、CTRL、STAT_FLG等与控制传输密切相关的寄存器。
GPIO辅助调试：这是嵌入式调试的“穷人之光”。在代码的关键路径（如Setup中断入口、TX中断入口、STALL设置点）上添加GPIO引脚电平翻转语句。用逻辑分析仪或示波器观察这些引脚的电平变化和时间关系，可以非常直观地看到固件的执行时序和流程是否与预期相符。
硬件协议分析仪：这是解决复杂USB通信问题的终极武器。如Beagle、Ellisys、LeCroy等USB协议分析仪，可以无损地捕获总线上的每一个包（Token、Data、Handshake），并以时间线的方式清晰展示出来。当你遇到“主机发了什么，设备回了什么”这类黑盒问题时，协议分析仪的数据能让你一目了然。例如，你可以直接看到设备是否对SETUP包回复了ACK，是否在GET_DESCRIPTOR的Data阶段发出了数据，数据内容是什么，状态阶段的握手是否正确。
利用控制器的调试功能：一些高端的USB设备控制器可能内置了调试模块，可以记录最近发生的事务或错误状态。查阅数据手册，看是否有此类调试寄存器可供利用。

最后的心得：调试USB控制传输，本质上是调试一个由硬件和软件共同实现的精密状态机。务必建立清晰的时序概念：Setup、Data、Status三个阶段是顺序的，但中断是异步的。固件代码必须足够健壮，能够处理主机任何可能的行为（如提前发送新Setup包）。从最简单的设备开始（例如，只实现一个端点0，能正确回复设备描述符和配置描述符），逐步增加功能，并在每一步都用工具验证总线上的行为，这是最稳妥的开发路径。当你能够清晰地描绘出一次完整枚举过程中，每一个数据包和中断的来龙去脉时，你对USB控制传输的理解就真正到位了。