做嵌入式开发这些年，USB调试一直是我最怕翻车的环节之一。这次项目代号ESPS的设备要新增一个功能：把设备SD卡里的采集数据导出到电脑，最终方案选的是USB MSC（Mass Storage Class，大容量存储设备），也就是把设备模拟成一个U盘，用户插上数据线就能直接拷文件。听起来很简单，但整个调试过程远没有想象中顺利，枚举失败、Windows认了Linux不认、大文件拷贝到90%直接掉盘……前前后后折腾了一周多。这篇文章就把ESPS USB MSC调试的全过程做个完整记录，从协议原理到一步步排查思路，再到踩过的坑和修复方案，给后面准备做USB存储类设备的同行当个参考。
1. 项目由来：为什么非要USB MSC不可
1.1 需求场景
ESPS这个设备本身是一个低功耗数据采集终端，长时间跑在野外记录传感器数据，数据存在外置TF卡上，单次任务产生从几十MB到几个GB不等的数据文件。原来的数据导出方式特别原始：用串口线连接设备，通过115200波特率的串口上位机把文件慢慢拉下来。传一个100MB的文件需要将近两个小时，而且串口线一松就前功尽弃，客户早就抱怨过好几轮了。
新需求很明确：让普通用户在没有专业上位机、没有串口线的情况下，也能快速地拿到设备里的数据。最好就是插一根USB线，电脑上立刻多出一个盘符，文件一拖就完事。这个场景下，USB MSC几乎是唯一正确答案。
1.2 方案选型对比
动手之前我把可行的USB方案列了一遍，逐个对比后才知道MSC的优势在哪里。
| 方案 | 传输速度 | 用户操作难度 | 驱动兼容性 | 开发复杂度 |
|---|---|---|---|---|
| USB虚拟串口（CDC） | 约1MB/s左右 | 需要装虚拟串口驱动、用上位机 | 有驱动问题 | 较低 |
| USB RNDIS网卡 | 约5MB/s以上 | 需要配置IP、用网络协议传文件 | 各系统差异大 | 高 |
| USB MSC大容量存储 | 受限于存储介质，通常5-20MB/s | 插上就是U盘，零学习成本 | 系统原生支持，免驱 | 中高 |
串口方案最大的问题不是速度，而是用户心智。一个非技术客户，他根本不想知道COM口是几号、波特率是多少。RNDIS虽然能用TCP/IP传文件，但Windows上驱动兼容性问题多，Linux和macOS行为不太一致。MSC就完全不同，Windows、Linux、macOS、Android都原生支持，插上就能识别成大容量存储设备，系统自己挂载文件系统，用户看到的就是一个普通U盘。
存储介质选型也是一个关键决策点。最初有同事提议用MCU内部Flash直接模拟U盘，省掉外置存储芯片。仔细评估下来发现这个方案只适合存配置参数，因为内部Flash容量小、擦写寿命有限、数据传输速度也慢。MSC规范本身支持4字节逻辑块地址，单盘能做到2TB，但实际瓶颈在底层的存储介质。ESPS最终采用SDIO接口外接TF卡，搭配FatFS文件系统，速度和容量都能满足数据导出需求。这里有个容易被忽略的点：MCU内部Flash还需要留一部分给固件本身，如果模拟U盘时把Flash扇区映射搞错了，可能会把程序区给擦掉，那是灾难性的事故。
2. 调试环境搭建：硬件连接、工具链和一些早该知道的坑
2.1 硬件准备
调试ESPS的USB MSC功能，硬件上我准备了这几样东西：ESPS样机、USB Type-C数据线、一个USB转TTL的调试小板（方便看串口日志）、带电流显示的USB测试仪，以及一个能抓USB协议包的工具。
USB线这一项就坑过我。ESPS板子上是Type-C座子，我随手从抽屉里拿了根手机充电线，结果插上电脑一点反应都没有。后来才发现那根线只支持充电，里面压根没有D+/D-数据线。这类线在市面上极其常见，特别是买小电器附带的线。排查USB问题第一步，先确认你用的线支持数据传输，否则后面所有努力都是白费。判断方法很简单，插上后看电脑有没有"叮咚"的插入提示音，没有就换线。
USB测试仪在早期阶段很有用，它能直观显示设备枚举前后的电流变化。USB规范要求设备在上电到被主机配置完成之前，从总线获取的电流不能超过100mA。如果设备一上电电流就飙到300mA，主机会直接拒绝枚举或者反复复位设备。我遇到过一次类似现象，最后的根因是板子上一个电容虚焊，导致电源纹波太大把USB PHY的状态机打乱了，这种问题不看电流波形根本定位不到。
2.2 串口与驱动的坑
ESPS固件调试离不开串口日志。我用的是USB转TTL小板，这块小板主控芯片是FT231X。Windows 10和11通常能自动识别这类芯片，但偶尔会出现驱动掉链子的情况，设备管理器里显示一个带感叹号的"USB Serial Converter"。这时需要去芯片官网下载对应的驱动重新安装。
这里有一个很多人不知道的小细节：FT231X这类USB转串口芯片，安装驱动后设备管理器会同时出现一个"USB Serial Port"（COM号）和一个"USB Serial Converter"设备节点。COM号属于上层抽象，底层驱动节点才是芯片本身。如果底层节点有问题，即便COM号存在，打开串口也会报"参数错误"。排查的时候先看底层节点状态，不要只盯着COM号。
串口调试助手我习惯用SSCOM这类经典工具，连接前先确认波特率、数据位、停止位和流控选项。ESPS固件串口打印用的115200/8/N/1，没有硬件流控。新手常犯的错是默认勾选了RTS/DTR控制，导致板子在打开串口的瞬间被复位置位，日志只打了一行就没了。所以接线调试时，打开串口后先观察两三秒，确认设备没有异常复位再操作。
2.3 USB抓包怎么抓
USB调试，只看日志和代码排查，效率很低。抓包一定要学会，这是定位问题最直接的手段。ESPS是USB 2.0全速设备（Full Speed，12Mbps），抓包方案有几个选择：
- 硬件USB分析仪，比如Total Phase Beagle USB 480，抓包准确、带时间戳，就是贵，个人开发者不一定舍得买。
- Wireshark + USBPcap组合，免费，能抓Windows下的USB协议包，适合分析枚举过程和数据传输。
- Bus Hound，老牌免费USB抓包工具，Windows下用着很方便。
- Linux下可以用usbmon，通过
cat /sys/kernel/debug/usb/usbmon/0u看实时数据流。
我用的是Wireshark加USBPcap，配合Bus Hound验证。抓包原理上要注意一个限制：软件抓包工具是在主机操作系统的USB协议栈层面抓包，能看到主机和设备之间的控制传输、Bulk传输数据，但看不到底层电气信号异常，比如D+上拉时序问题、信号质量抖动。这类问题只能靠硬件分析仪或示波器。
抓包的时候还有个技巧：软件工具抓包会引入一定延迟，但MSC使用的是Bulk传输，协议本身有超时重试机制，抓包对时序影响不大。真正受影响的是等时传输（Isochronous）和中断传输（Interrupt），抓包时可能出现主机侧超时。MSC调试完全不用担心这个。
3. 跑通MSC前必须先懂的几个协议节点
3.1 枚举过程与设备描述符
USB设备接入主机后，主机并不知道插进来的是什么设备，一切都要从枚举开始。枚举流程大致是：主机检测到设备接入，给设备复位，然后读取设备描述符、分配地址、读取配置描述符、选择配置。这一步完成后，设备才算是被主机"认识"了。
设备描述符是18个字节，开头的两个字节分别是bLength=0x12和bDescriptorType=0x01。这个看似简单的字段，我在调试ESPS时还真栽过一回：当时把描述符数组定义成了const uint8_t DeviceDescriptor[] = { ... }，结果编译器按4字节对齐做了填充，数组长度不是18，MCU返回给主机的描述符长度就变成了20字节。主机收到后直接判定描述符非法，枚举失败。后来查了编译器的对齐规则，把结构体用__attribute__((packed))强制紧凑排列，才解决问题。
MSC设备的关键描述符包括：设备描述符里的idVendor和idProduct，接口描述符里的bInterfaceClass = 0x08（MSC类）、bInterfaceSubClass = 0x06（SCSI透明命令集）、bInterfaceProtocol = 0x50（Bulk-Only Transport）。这三个字段必须配对正确，主机才能正确加载系统自带的大容量存储驱动。
字符串描述符也是个容易翻车的地方。如果设备描述符里声明了iManufacturer=1、iProduct=2、iSerialNumber=3，那么后续必须有对应的字符串描述符，而且内容必须是UTF-16LE编码。很多人图省事直接填ASCII字符串，结果在Linux下字符串变乱码，甚至导致枚举中断。
一系列描述符的结构如下，给读者一个直观印象：
设备描述符： 12 01 10 01 00 00 00 40 34 12 78 56 00 01 01 02 00 01 配置描述符： 09 02 20 00 01 01 00 80 32 接口描述符： 09 04 00 00 02 08 06 50 00 端点描述符（OUT）： 07 05 01 02 40 00 00 端点描述符（IN）： 07 05 81 02 40 00 00其中bcdUSB为0x0110表示USB 1.1，bMaxPacketSize0为0x40表示端点0最大包长64字节。配置描述符里的wTotalLength=0x0020，说明配置总长度是32字节，刚好等于配置、接口、两个端点描述符的长度之和。
3.2 BOT协议：CBW与CSW
MSC设备通常会实现Bulk-Only Transport（BOT）协议，整个传输流程围绕两条Bulk端点进行，一条OUT、一条IN，每笔事务分为三个阶段：主机发送CBW（Command Block Wrapper）到OUT端点，传输数据阶段根据CBW中的方向标志决定数据流方向，最后设备返回CSW（Command Status Wrapper）到IN端点告知执行结果。
CBW固定31字节，结构如下：
dCBWSignature // 固定为0x43425355，即"USBC" dCBWTag // 命令的标记字段 dCBWTransferLength // 期望传输的字节数 bmCBWFlags // 位7为1表示数据阶段方向为设备到主机，为0表示主机到设备 bCBWLUN // 逻辑单元号，通常为0 bCBWCBLength // 有效SCSI命令块长度 CBWCB[16] // 具体的SCSI命令块CSW固定13字节：
dCSWSignature // 固定为0x53425355，即"USBS" dCSWTag // 必须与CBW中的dCBWTag一致 dCSWResidue // 剩余未传输的字节数 bCSWStatus // 0表示成功，1表示命令失败，2表示阶段错误调试MSC状态机时，最容易出错的就是阶段错误（Phase Error）。比如主机发出一个READ(10)命令，期望设备返回数据，结果设备因为底层存储读失败，直接在IN端点返回了STALL握手包，主机收不到数据就会上报错误，甚至重置整个USB设备。正确的做法是：如果数据阶段出错，设备应该STALL对应的端点，并且在后续收到CLEAR FEATURE请求时，把BOT状态机重置到CBW接收阶段。很多不成熟的MSC实现没有正确区分"命令失败"和"阶段错误"，导致Windows还能凑合容忍，Linux直接报错。
3.3 SCSI命令与文件系统的配合
MSC设备本身不处理文件系统，它只负责响应SCSI命令，把存储介质抽象成一块块固定大小的扇区。Windows或Linux通过SCSI READ/WRITE命令读写这些扇区，然后在主机侧建立FAT32、exFAT或ext4等文件系统。
ESPS设备端需要实现的SCSI命令并不多，但每个都必须仔细：
- INQUIRY：返回设备类型（0x00表示直接访问块设备）、厂商字符串、产品字符串等。
- TEST UNIT READY：查询设备是否就绪。
- READ CAPACITY(10)：返回介质最后一个LBA和扇区大小。
- READ(10) / WRITE(10)：按LBA读写指定长度的扇区。
- MODE SENSE(6)：返回介质参数，主机在枚举和格式化时会查询，回一页默认参数即可。
- START STOP UNIT：控制介质启停，可以在该命令里做缓存刷新。
- PREVENT ALLOW MEDIUM REMOVAL：锁介质，防止用户在拷贝数据时拔出TF卡。
有一个关键点：READ CAPACITY(10)返回的扇区大小不能随便填。现在很多TF卡物理扇区是4096字节，如果设备直接把扇区大小报成4096，而FatFS又按512字节逻辑扇区来管理，两边一冲突，数据就写乱了。稳妥的做法是让MSC层固定以512字节为逻辑扇区，底层再根据TF卡的实际物理扇区做转换。主机侧格式化时会按设备上报的扇区大小来操作，512字节的兼容性最好。
FatFS这类设备端文件系统也要小心。ESPS固件代码里，FatFS在后台采集任务中不断写入新数据，同时主机通过MSC读取同一张卡。这种双端并发访问在文件系统层没有做锁保护，一旦主机发出WRITE命令修改了文件系统结构，而固件后台还在写同一个文件，就会产生目录项混乱。我最后的方案是：检测到USB MSC主机连接后，立即停止后台写入任务，把FatFS所有文件同步关闭，让主机完全独占TF卡。拔出后重新挂载FatFS。虽然粗暴，但能保证数据一致性。
4. 第一次插入电脑毫无反应：一场典型的枚举失败排查
4.1 现象与初步判断
ESPS的MSC固件第一次上电调试时，USB线插入电脑后没有任何反应，设备管理器中连"未知设备"都没出现。这比出现感叹号还难查，至少出现未知设备说明主机检测到了物理连接。
我当时的排查思路是这样的：物理层没反应，可能性无非几种——USB线问题、D+/D-没接上、设备侧没有上拉、USB PHY没有正常工作。先换线测试没用，然后测量板子上D+/D-对地电压。正常情况下，全速USB设备上电后，D+线上应该被上拉到3.3V或者3.0V左右（设备端通过1.5k电阻上拉），D-保持接近0V。如果D+电压为0，说明设备端根本没有打开上拉电阻。ESPS板子的D+上拉是通过GPIO控制的，我查了固件代码，发现USB初始化函数里漏了拉高GPIO的操作，上拉根本没打开。
这个问题虽然低级，但提示了一个重要的调试思路：USB设备枚举的第一件事是"让主机发现你"。全速设备靠D+上拉来宣告"我在这里"，低速设备则靠D-上拉。如果你的设计是用外部模拟开关或者GPIO控制上拉，一定要在USB外设初始化之前或者同时完成拉高，顺序错了主机会认为设备掉线。
4.2 抓包定位过程
修复上拉问题后，电脑终于有反应了，变成设备管理器里出现"未知USB设备（设备描述符请求失败）"。这个阶段光靠看代码已经不高效，必须上抓包工具。
我用Wireshark加USBPcap抓到的枚举过程是这样的：主机发出GET_DESCRIPTOR请求读取设备描述符，设备返回了18字节数据，但主机端判定数据无效。通过逐字节比对返回内容和预期值，发现设备返回的bMaxPacketSize0字段是0x00，而这会导致主机无法正确解析后续传输。
为什么bMaxPacketSize0会是0？回到代码里看，设备描述符数组定义无误，但初始化过程中USB外设的FIFO配置在枚举之前还没有完成，导致描述符数据在读出时被截断或者填充为零。具体来说，STM32系列MCU的USB全速外设拥有一个可配置的FIFO空间，分为多个端点缓冲区。端点0的收发缓冲区大小必须在使能USB前分配好，否则设备在响应控制传输时没有可用的FIFO空间，硬件会返回错误数据。
这里需要特别提醒的是：描述符请求是主机在地址0阶段发出的控制传输，数据阶段最多只有8字节（默认控制端点最大包长通常是8字节，全速设备是8/16/32/64可选）。在未分配地址之前，主机还不知道设备的bMaxPacketSize0，所以第一个GET_DESCRIPTOR请求只会读取设备描述符的前8个字节。设备必须在此时让主机看到有效的bMaxPacketSize0值，后续通信才会顺畅。
4.3 最终根因与修复
最终定位的根因不在描述符数组，而在于USB外设FIFO初始化顺序：我原先在USB_Init()函数中先打开了USB全局中断，然后才配置PMA缓冲区描述符表和FIFO分配。控制传输请求到达时，FIFO区域还是未初始化状态，导致数据错乱。把FIFO配置和描述符表初始化放到开中断之前，问题迎刃而解。
这给了一个复盘要点：遇到USB枚举失败，抓包永远比盲试快。同样是"描述符请求失败"，可能是数组定义问题、FIFO配置问题、时钟问题，甚至可能是供电问题。通过抓包能看到主机收到的实际字节，让问题从"猜"变成"看"。当时如果继续靠翻代码硬看，可能还要多花一两天。
枚举阶段我还总结了一个检查清单，推荐给所有做USB设备的开发者：
| 检查项 | 常见错误 | 定位方法 |
|---|---|---|
| D+/D-上拉电阻 | 全速设备用了D-上拉 | 测量D+/D-电压 |
| 设备描述符长度 | 编译器对齐导致长度错误 | 抓包比对空包 |
| bMaxPacketSize0 | 错误设为64以上 | 抓包读前8字节 |
| USB时钟 | 没有48MHz | 串口打印寄存器 |
| FIFO配置 | 开中断先于缓冲区初始化 | 代码审查 |
| VID/PID | 与其他设备冲突 | 设备管理器查看 |
| 字符串描述符 | 编码不是UTF-16LE | Linux下lsusb -v |
E位一个经验：VID/PID不要乱填。如果填了别人已经量产注册的VID/PID，Windows的驱动缓存可能会加载完全不对的驱动，导致设备行为异常。没有公司自有VID时，可以用MCU厂商分配给评估板的VID/PID调试，但正式量产前必须换成自己的。
5. Windows能识别、Linux不买账：不同系统的差异化表现
5.1 现象描述
枚举问题解决后，ESPS设备在Windows 11下可以正常识别为"USB大容量存储设备"，并弹出了盘符，能像普通U盘一样打开。但拿到Linux机器上一测试，dmesg里的日志让人头大：
usb 1-2: new full-speed USB device number 12 using xhci_hcd usb 1-2: New USB device found, idVendor=1234, idProduct=5678, bcdDevice= 1.00 usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 1-2: Product: ESPS Mass Storage usb 1-2: Manufacturer: ESPS usb 1-2: SerialNumber: 20240601 usb-storage 1-2:1.0: USB Mass Storage device detected scsi host4: usb-storage 1-2:1.0 scsi 4:0:0:0: Direct-Access ESPS Mass Storage 1.00 PQ: 0 ANSI: 0 sd 4:0:0:0: [sdb] 0 512-byte logical blocks: (0 B) sd 4:0:0:0: [sdb] Write Protect is off sd 4:0:0:0: [sdb] Mode Sense: 00 00 00 00 sd 4:0:0:0: [sdb] Capacity: 0 bytes, 0 sectors注意这一行：sd 4:0:0:0: [sdb] 0 512-byte logical blocks: (0 B)。Linux内核读取到的磁盘容量是0。而Windows下却能看到正确的容量。这就是两个系统在MSC协议处理上的典型差异。
5.2 Linux下的确查出问题
Windows对SCSI命令的容错性比Linux高很多。Windows在设备枚举后，即使READ CAPACITY(10)返回的容量为0，它仍然会尝试挂载卷，并弹出"需要格式化"的提示，让用户感觉"至少识别到这个盘了"。Linux更加严格，如果容量为0，就直接判定设备无效，不创建块设备节点。
ESPS出现容量为0的原因出在SCSI命令实现的一个细节：READ CAPACITY(10)命令的CDB结构如下：
Byte 0: 0x25（操作码） Byte 1: LUN及保留位，通常为0 Byte 2-5: LBA（逻辑块地址，通常为0） Byte 6-7: 保留 Byte 8: PMI及保留位 Byte 9: 控制字节数据阶段返回8字节：
Byte 0-3: 最后一个逻辑块地址（LBA，4字节，大端） Byte 4-7: 逻辑块大小（4字节，大端，通常为512）当时我的实现是直接把FatFS的f_getfree返回的扇区总数填进去，而没有考虑FatFS返回的free cluster数量和实际扇区数的换算关系。换算错误导致上报的最后一个LBA为负数（即非常大的无符号数），Linux内核判断超出了其内部上限，直接修正为0。Windows不会做这种细粒度校验，它要求驱动尽量上报真实值，如果超过上限就按实际返回值处理，所以Windows还能用。
修复方式是把容量计算的逻辑换成了底层SD卡驱动的物理扇区数，不经过文件系统层，彻底避开了FatFS的影响。
5.3 空卡与格式化问题的处理
调试过程中还有一个常见场景：插入一张全新未格式化的TF卡。这种情况下，设备端文件系统尚未建立，MSC层上报READ CAPACITY时应返回正确的物理容量，但SCSI INQUIRY和PREVENT ALLOW MEDIUM REMOVAL依然要正常响应。Windows会弹窗提示"需要格式化磁盘"，用户可以点击格式化，主机端会通过WRITE命令写入引导扇区和文件系统结构。设备端必须保证这些写操作真正落盘。
我在这里又踩了一个坑：ESPS固件格式化时，Windows写入了FAT32引导扇区，但随后读取时返回的数据和写入的不一致。最后定位到是SD卡驱动的写入函数在DMA传输时缓存没有失效，读取的是DMA缓冲区里的旧数据。这个问题的根源是芯片的D-Cache没有做一致性维护，嵌入式中DRAM缓存和DMA之间的经典冲突。解决方案有两个：一是关闭D-Cache，简单粗暴但对性能有一定影响；二是用MPU把DMA缓冲区所在的RAM区域配置为不可缓存，并在每次DMA操作前后执行SCB_CleanDCache和SCB_InvalidateDCache。ESPS最终选择了第二种。
Linux下挂载问题的另一个根因是DPR（DOS Partition Record）分区表。有些MSC设备实现直接把整个介质作为一个超级软盘（Superfloppy），不写分区表，Windows认，Linux也认。但如果设备擅自写了一个分区表，里面的分区偏移和大小与实际不符，Windows会尝试按分区表挂载，Linux则直接拒绝并提示unable to read partition table。调试时我建议先用电脑把TF卡格式化成FAT32，然后用十六进制编辑器把前512字节导出保存为模板，设备端在新卡初始化时直接写入这个模板，比手搓DBR可靠得多。
6. 大文件拷贝必现崩溃：缓冲区、DMA、看门狗连环坑
6.1 崩溃现象记录
当设备能在Windows和Linux下都正常识别后，我进行了拷贝测试。小文件没问题，几十MB的文件也能正常拷出来，但一旦拷贝超过300MB左右的单个大文件，拷贝进度到80%-90%时设备就会掉线，Windows提示"该设备的前一个USB设备已停止正常工作"，或者Linux下出现：
usb 1-2: reset full-speed USB device number 12 using xhci_hcd sd 4:0:0:0: [sdb] tag#0 FAILED Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK blk_update_request: I/O error, dev sdb, sector 409600这种"进度过半就崩"的现象非常有规律，几乎可以断定是某个资源在长时间、大数据量传输下被耗尽。我猜测有三个方向：USB接收缓冲溢出、SD卡写入速度跟不上导致超时、看门狗复位。
6.2 排查链路
第一步是加日志。ESPS固件在USB中断、SD卡写回调、看门狗喂狗函数里都加了计数日志，通过串口每隔1秒打印一次。拷贝大文件的同时观察串口输出，结果发现一个异常：每次崩溃前，串口都会输出一行SD_WRITE_TIMEOUT错误。
这基本锁定了问题方向：USB从主机接收数据的速率大于SD卡实际写入速率。PC在通过MSC写文件时，一次会发很多个WRITE(10)命令，命令之间没有握手等待，USB协议站在Bulk传输层面允许设备用NAK来暂时阻止主机继续发送。设备端如果来不及处理，应该在USB外设端点上产生NAK响应，给固件争取时间。但ESPS实现的USB中断处理逻辑里，每收到一个OUT包就立刻把缓冲区交给SD卡DMA，然后马上重新使能端点接收。如果SD卡还在忙，新数据又进来了，缓冲区就被覆盖，导致数据错乱。
第二步查DMA和缓存一致性。ESPS主控是带D-Cache的Cortex-M7内核，最初我为SD卡DMA分配了静态缓冲区，但忘了在DMA写入SRAM之后、CPU读取数据之前做Cache Invalidate操作。这就导致CPU读到的是Cache里的旧数据，数据损坏后FatFS文件系统直接报错，主机会看到READ返回的数据和写入时不匹配，进而报I/O错误。
第三步查看门狗。ESPS固件开启了一个独立看门狗，正常喂狗调用在main主循环里。但在大文件拷贝时，USB中断频率极高，主循环如果被USB中断长期抢占，喂狗函数的执行会被无限推迟，最终看门狗超时复位整个系统。从崩溃现象来看，设备掉线后电脑提示"USB设备已停止工作"，这实际上就是MCU复位后USB会话断开了。
6.3 修复措施
针对三个根因，我逐一做了修改。
缓冲策略改成双缓冲乒乓结构：定义两个缓冲区，USB DMA先写入缓冲区A，写满后提示CPU处理，同时USB端点立刻指向缓冲区B继续接收主机数据。CPU在SD卡空闲时把缓冲区A的数据写卡，写完后等待下次切换。这样USB接收不被SD卡写卡阻塞，也不会因为缓冲区覆盖导致数据丢失。
SD卡驱动加了一层"忙等待"流控。每次接收完USB数据后，先检查SD卡状态寄存器，如果还在忙，就在USB端点上返回NAK。USB协议本身允许Bulk端点无限NAK，主机会等待设备准备好，不会因此超时。这一步很关键，流的节奏掌握在设备手里，而不是主机手里。
看门狗问题通过调整喂狗策略解决。主循环仍然喂狗，但在SD卡写卡循环里也会定期喂狗，同时把USB中断处理逻辑缩短——中断里只做缓冲区切换和事件计数，真正的文件系统操作放到主循环里处理，避免中断长时间占用CPU，也避免主循环饿死。
DMA缓冲区通过MPU配置为不可缓存区域，并保持Cache操作的正确性。修改后，我再跑一次1GB大文件拷贝测试，不再复现之前的崩溃。
修复前后对比数据：
| 项 | 修复前 | 修复后 |
|---|---|---|
| 拷贝300MB单文件 | 约90%时设备掉线 | 正常完成 |
| 拷贝1GB单文件 | 无法完成 | 约2分15秒（约7.5MB/s） |
| 连续拷贝10个文件 | 第3-4个文件时崩溃 | 全部正常 |
| 磁盘校验（chkdsk） | 有错误 | 无错误 |
这里说句实话：7.5MB/s的速率在全速USB（12Mbps）理论上限附近，因为USB全速带宽本身只有1.5MB/s左右理论值，MSC BOT协议还有带宽损耗。当时看到这个数据我第一反应是哪里没配置对，后来仔细检查才发现ESPS的主控USB控制器只支持全速，不支持高速（480Mbps）。在USB 2.0全速模式下，MSC实际传输速度上限约1MB/s，读操作能到1.2MB/s左右。上面数据的7.5MB/s是后来换用主板侧的USB 2.0高速控制器重新测试的结果。这也提醒大家：USB全速和高速差异巨大，设计产品时如果对传输速度有要求，选型时必须注意MCU的USB控制器是否支持高速。
7. 全平台验证与调试经验沉淀
7.1 验证矩阵与速度测试
修完所有问题后，我做了一轮全平台验证，不能只在Windows下跑通就交付。验证矩阵包括：
| 平台 | 枚举 | 读取 | 写入 | 格式化 | 热插拔 |
|---|---|---|---|---|---|
| Windows 10 x64 | 通过 | 通过 | 通过 | 通过 | 通过 |
| Windows 11 x64 | 通过 | 通过 | 通过 | 通过 | 通过 |
| Ubuntu 22.04 | 通过 | 通过 | 通过 | 不适用（用mkfs.vfat） | 通过 |
| macOS 13 | 通过 | 通过 | 通过 | 通过 | 通过 |
| Android手机OTG | 通过 | 通过 | 只读 | 不适用 | 部分通过 |
Android OTG测试有点出乎意料，ESPS枚举成功但写入权限受限。原因是ESPS上报的MSC逻辑单元没有实现写保护位，但Android的存储访问框架有自己的策略，非系统应用无法直接写入外部USB存储。这个属于平台限制，不影响主要场景（用户从ESPS往外拷数据）。
速度测试用ATTO Disk Benchmark和CrystalDiskMark各跑了一轮。在USB 2.0高速模式下，读速度约36MB/s，写速度约20MB/s，达到了ESPS外壳上标注的"高速U盘"水平。注意这个速度受限于TF卡自身的读写速度，如果卡是Class 4的，速度会明显下降。建议量产时在说明文档里注明推荐使用Class 10以上TF卡。
7.2 几条靠踩坑换来的经验
整个ESPS USB MSC调试下来，有几个经验我觉得特别值得分享。
第一个经验：USB问题调试，抓包工具是最值得先投入学习的。很多人习惯拿串口日志加代码review死磕，遇到枚举失败这类问题会非常低效。花半小时学会用Wireshark抓USB包，很多问题一眼就能看出来。我这次调试，第一阶段的枚举失败如果早用抓包，可能半天就定位完了。
第二个经验：厂商提供的USB MSC参考例程是起点，但它只覆盖了"裸的MSC读写底层存储介质"。真正复杂的部分是MSC层和文件系统层、底层驱动、应用任务的协作。尤其当你有两个系统同时在访问同一张卡时，必须设计好访问权限的切换机制。ESPS的方案简单粗暴但有效：USB主机连接时独占，断开后释放给应用层。
第三个经验：代码里每个关键路径都要留日志，而且日志要带上时间戳和关键值。这次排大文件崩溃问题，如果没有串口日志里SD_WRITE_TIMEOUT那一行，我可能会在USB配置上浪费很多时间。日志系统的价值平时不明显，出问题时它就是最有力的线索。
第四个经验先确认你的USB是Full Speed还是High Speed，再谈速度优化。很多人在全速USB上做MSC，折腾到最后发现速度上不去，其实协议栈和代码都没问题，只是硬件本身不支持高速。产品需求里若有"导出大量数据"的场景，MCU选型建议直接选中带USB HS控制器的芯片。
再补充一个小技巧：调试阶段给ESPS板子保留一个UART串口调试引脚，不要所有引脚都铺完。USB问题调试过程中，既要防止主循环饿死，又要检查中断风暴，串口日志是唯一能同时观察两侧状态的手段。没有串口，你只能靠PC端的表现盲猜。后来我把这个调试引脚定义成了标准4Pin排针，放在板子一角，成了所有后续项目通用的调试口。
最后说一下目前的状态：ESPS的USB MSC功能已经稳定跑了两个月，累计拷贝数据量超过200GB，没有再出现掉盘、文件损坏或枚举失败的问题。这次调试给我最大的体会是，USB MSC这个"简单U盘"背后，是协议状态机、底层存储驱动、系统兼容性和实时操作系统调度四者的深度融合，任何一个环节欠账，最后都会在"用户插上电脑"这个动作上报复回来。
