做嵌入式的人总会在某个版本需求里遇到一句话把设备里的数据导出到U盘。这活儿在电脑上就是拖拽一下文件但放到单片机里就变成了一次“三层挑战”——底层要用USB主机控制器识别U盘并枚举中间要按Mass Storage Class协议发SCSI命令读写扇区上层还得把FatFs文件系统挂上去才能出现人人熟悉的文件名和目录。任何一个环节掉链子插上U盘就是“没反应”。这篇文章以GD32450Z这颗带USBHS内部PHY的MCU为例把“主机模式 U盘文件读写 FatFs集成”整套流程完整拆开讲透从为什么选内部PHY、USB协议栈怎么初始化到FatFs的5个底层接口怎么移植再到我实际调试中踩过的供电、枚举、扇区对齐等坑。适合手上有GD32F450或同系列芯片、准备做U盘存储、固件升级、参数导入导出项目的朋友特别是那些不想一上来就外挂USB3300这类ULPI PHY芯片的人。1. 整体方案与选型逻辑1.1 为什么选内部PHY而不是外挂ULPI PHYGD32450Z的USBHS控制器支持两种PHY工作模式一种是直接用芯片内部的USB PHYDP/DM信号从PA11、PA12引出另一种是走ULPI接口外接USB3300、USB3320这类高速PHY芯片。很多开发者在拿到USBHS需求时第一反应是“高速USB肯定要外挂PHY”但其实这颗IC的内部PHY在主机模式下也能干活而且对大多数U盘读写场景来说完全够用。我做这个项目时为什么锁定内部PHY核心原因是成本、布线和调试难度三方面的综合考虑。外挂一颗高速PHY芯片硬件上要多出十几根ULPI控制线PCB布线需要按高速差分信号处理BOM成本也多出小几块钱而内部PHY只需要DP/DM两根差分线再加上VBUS开关控制外围电路极其简单。对比表格如下方便大家按自己项目情况取舍对比项内部PHY外部ULPI PHY引脚数量少DP/DM VBUS/ID多约12根ULPI信号线BOM成本低高需要额外PHY芯片布线难度低只需处理一对差分线高需要控制ULPI总线时序高速稳定性一般受MCU封装和PCB影响更稳定独立PHY驱动能力强调试便利性方便无需额外初始化需要配置ULPI接口时序需要提醒的是内部PHY模式下的480Mbps高速传输对PCB走线的差分阻抗、串阻匹配还是比较敏感的。如果是打样实验板用杜邦线或普通飞线连接U盘建议先把USB控制器配置成全速FS模式验证协议流程等逻辑全通了再切回高速模式做稳定性测试。1.2 主机模式下的三层软件架构USB主机模式跟从机模式最大的区别在于从机只需要被动响应主机发来的请求而主机必须自己承担总线调度、设备复位、枚举、传输超时处理等一系列工作。打个比方从机模式像接电话的人等铃响、接起来、说“你好”主机模式则像打电话的人要先拨号、确认对方在不在、自我介绍、然后才能谈正事。拨号没人接、对方说话含糊、说到一半断线全都得主机负责处理。GD32450Z做U盘读写时软件上天然分成三层USB控制器驱动层负责初始化USBHS控制器、处理连接/断开中断、完成设备枚举、配置端点、发起批量传输。MSC协议层在USB之上解析Mass Storage Class的BOT传输协议向U盘发送CBW命令块、收发数据、读取CSW状态最终暴露出来的是“按扇区读写”的裸设备接口。FatFs文件系统层只认扇区读写接口不关心底下是不是U盘。它把“文件”翻译成“扇区”后调用MSC层提供的disk_read、disk_write函数完成实际存储。三层之间是清晰的依赖关系。调试时最大的忌讳是三层问题混在一起查U盘没枚举成功就怀疑FatFs配置不对文件写不进去就怀疑USB传输有问题。我自己的习惯是先逐层验证——USB枚举通了、SCSI读扇区没问题了最后才把FatFs挂上去。后面第5章的排查记录会详细展开这个思路。2. 硬件准备与USB主机协议栈初始化2.1 时钟、引脚与VBUS供电配置GD32450Z的USBHS模块需要48MHz的PHY时钟。这里要注意不是把系统主频改成48MHz而是通过RCU和USBPHY配置把PLL分频出来的48MHz时钟送给USBHS模块。在项目中我一般直接参考GD官方库里的SystemInit配置确保USB_PHY时钟来源正确再单独使能USBHS的RCU时钟。引脚方面内部PHY模式下核心引脚如下PA11USB_DPPA12USB_DMPA9VBUS驱动控制主机模式下用于使能5V VBUS输出PA10ID引脚主机模式下一般配置为接地或者由库内部按主机模式处理这几个引脚在部分开发板上可能被LED、按键或其他外设复用上板前一定要先查原理图。GPIO初始化时PA11/PA12按复用功能配置PA9作为输出控制VBUS电源开关PA10按ID输入或输出低处理。不同开发板的VBUS电路设计差异很大有的是MCU引脚直接驱动MOS管有的是用专门的电源开关芯片代码里要按实际硬件极性调整控制电平。主机模式下VBUS供电是最容易被忽略的硬件细节。U盘在枚举和读写瞬间电流可能到几百毫安直接用MCU引脚驱动5V是不现实的必须用外部电源管理芯片或MOS管开关从系统5V电源取电。建议VBUS输出端放一个100uF电解电容加上若干0.1uF陶瓷电容避免U盘启动瞬间把5V拉垮。Vbus控制逻辑也要留足电流裕量这和后面遇到的“插上U盘CPU复位”现象直接相关。2.2 主机模式枚举流程与BOT传输协议USB主机模式下的软件首先要完成设备枚举这一步决定了后面能否进入MSC传输。枚举流程本质上就是主机按协议规范向设备发一串标准请求检测到设备连接后主机对总线执行复位驱动SE0状态让设备恢复到默认地址0状态。读取设备描述符的前8字节得到端点0的最大包长度。再次复位设备然后通过默认地址0发送SET_ADDRESS请求给U盘分配一个唯一地址。使用新地址读取完整的设备描述符和配置描述符从配置描述符里解析出接口类型、端点地址和端点属性。发送SET_CONFIGURATION请求激活U盘的工作配置。查询U盘的MaxLUN通常为0确认它支持多少个逻辑单元。这个流程每一步都有超时要求比如SET_ADDRESS之后需要等待一段时间再继续操作读描述符时如果设备没准备好要能容忍NACK重试。工程上建议把枚举过程放进状态机而不是用阻塞式大循环硬等否则遇到慢速U盘或供电不稳时程序很容易卡死在某个请求上。枚举完成后MSC传输走的是BOT协议。这个协议的特点是“命令-数据-状态”三段式主机先通过批量OUT端点发送31字节的CBWCommand Block Wrapper其中包含命令块标识、数据传输长度和SCSI命令内容。根据命令方向主机通过批量端点收发数据。主机通过批量IN端点读取13字节的CSWCommand Status Wrapper从状态字段判断这次命令成功还是失败。U盘读写文件的本质就是主机用SCSI READ(10)和WRITE(10)命令对U盘做扇区级访问CBW里带上起始逻辑块地址和传输块数数据阶段搬运扇区内容CSW确认执行结果。这里有一个非常实用的经验所有USB传输都必须加超时CSW读取尤其不能死等。有些U盘在异常情况下会不回CSW没有超时机制的话整个程序会彻底卡死。3. FatFs文件系统移植与底层对接3.1 ffconf.h关键配置说明FatFs是一个典型的嵌入式文件系统它本身不关心存储介质是什么只要介质驱动提供“读扇区”“写扇区”“获取容量”这几个底层能力。它的所有功能开关都集中在ffconf.h头文件里。针对U盘读写这个场景我推荐按下面的配置裁剪#define FF_USE_LFN 1 // 开启长文件名支持 #define FF_MAX_LFN 255 // 长文件名最大长度 #define FF_MAX_SS 4096 // 最大扇区大小兼容4K扇区U盘 #define FF_VOLUMES 1 // 只挂载一个卷 #define FF_USE_MKFS 1 // 如果要做格式化开启这个选项 #define FF_USE_STRFUNC 0 // 不需要f_gets/f_puts的字符串扩展几个重点说明一下。FF_MAX_SS一定要设成4096别看市面上大多数U盘都是512字节扇区但4K扇区的盘确实存在如果这里写死512FatFs遇到4K盘会直接报错。FF_USE_LFN开启后会占用一部分RAM不过对GD32450Z这种200MHz主频、192KB RAM的芯片来说完全不是问题。如果项目只用固定文件名FF_USE_LFN可以关掉省资源。FF_VOLUMES代表卷数量一般U盘场景只挂一个卷就够所以设成1。FF_USE_MKFS是f_mkfs格式化功能如果你打算在设备上直接格式化U盘这项必开如果U盘永远是电脑格式化好的可以关闭减少代码量。3.2 disk_read、disk_write等底层接口实现FatFs要求底层提供5个核心函数disk_initialize、disk_status、disk_read、disk_write、disk_ioctl。移植的难点不在函数本身而在如何把USB主机MSC层“搬运某个扇区”的能力干净地包装成FatFs认识的块设备接口。先看disk_initialize和disk_status。这两个函数一个做初始化一个查介质状态。在U盘场景下USB的初始化实际上在枚举阶段就已经完成了这里只需要判断“U盘是否已挂载”并返回对应状态码就行。如果U盘被拔出disk_status要返回STA_NOINIT这样FatFs在后续操作时会主动报错而不是傻等。disk_read和disk_write是核心。每次被调用时底层要做的事情就是把传入的起始扇区号和扇区数量翻译成SCSI READ(10)或WRITE(10)命令然后交给MSC层完成一次BOT传输。下面是我项目里的实现逻辑示例DRESULT disk_read(BYTE pdrv, BYTE *buff, LBA_t sector, UINT count) { UINT i; if (pdrv ! 0) return RES_PARERR; if (disk_ok ! 1) return RES_NOTRDY; // 逐扇区调用MSC层读接口 for (i 0; i count; i) { if (msc_read_sectors(sector i, buff i * SECTOR_SIZE, 1) ! MSC_OK) { return RES_ERROR; } } return RES_OK; }这里有一个特别容易踩的坑FatFs可能传入未对齐的缓冲区。比如f_read时用户给的是局部变量数组地址没有按4字节对齐而USB主机如果开启了DMA传输对缓冲区对齐是很敏感的。我采用的方案是如果缓冲地址没对齐就先用一个4字节对齐的内部缓存接收数据再拷贝到FatFs给的缓冲区。虽然多了一次拷贝但稳定性提升明显。disk_ioctl负责返回介质参数和完成控制操作。FatFs挂载时主要调用这几个命令GET_SECTOR_COUNT返回U盘总扇区数。GET_SECTOR_SIZE返回扇区大小这个必须和U盘实际值一致。GET_BLOCK_SIZE返回擦除块大小用于格式化时对齐分配单元。CTRL_SYNC写入完成后刷新缓存对USB设备可以返回RES_OK表示完成。CTRL_TRIM可选用于告知设备哪些扇区不再使用普通U盘可以不实现。移植完成后务必先做一个“裸读测试”枚举成功后不挂FatFs直接通过MSC层读U盘逻辑扇区0也就是主引导记录MBR把前16字节打出来看看。如果这一层能读出EB 3C 90之类的引导标记说明USB和SCSI链路是通的后面再上FatFs就会很顺。4. 实操从枚举到U盘文件读写4.1 状态机设计与代码框架USB主机模式最忌讳用一个大循环从头跑到尾因为U盘随时可能被拔出、枚举可能失败、传输可能超时必须用一个状态机把整个生命周期管理起来。我在项目里把状态划分如下HOST_IDLE空闲状态等待U盘插入。HOST_CONNECTED检测到连接执行总线复位和地址分配。HOST_ENUM读取描述符、设置配置。HOST_READY枚举完成挂载FatFs进入就绪态。HOST_IO正在执行文件读写操作。HOST_ERROR出错状态显示错误信息并等待重新插拔。状态机的核心循环放在主循环或1ms定时器里反复调用。每次进入一个状态先把该状态下要做的USB请求发出去然后记录当前状态和超时时间下一次循环检查传输是否完成、是否超时再决定是否跳转。下面是一个简化版的调度逻辑void usb_host_task(void) { switch (host_state) { case HOST_IDLE: if (usb_dev_connected()) { host_state HOST_CONNECTED; host_tick 0; } break; case HOST_CONNECTED: if (usb_do_reset_and_set_address() OK) { host_state HOST_ENUM; } break; case HOST_ENUM: if (usb_do_enumeration() OK) { if (f_mount(fs, 0:, 1) FR_OK) { host_state HOST_READY; } } break; case HOST_READY: // 处理文件读写任务 break; default: break; } }这里有一个值得强调的小细节每次U盘拔出后之前FatFs挂载过的卷必须卸载否则状态机回到空闲态后再插入U盘FatFs会认为介质没变化导致读写失败。处理办法是检测到断开事件时调用f_mount(fs, , 0)执行一次卸载操作再清空内部状态。4.2 文件读写实测与代码演示当状态机进入HOST_READY后文件操作就是普通的FatFs调用。下面是一段我在项目中实际用过的代码实现“写一个文本文件再读回来校验”FIL fil; UINT bw, br; FRESULT fr; // 写文件 fr f_open(fil, 0:/LOG.TXT, FA_CREATE_ALWAYS | FA_WRITE); if (fr FR_OK) { f_write(fil, log_buf, sizeof(log_buf), bw); f_sync(fil); // 写完一段就同步一次防止拔盘丢数据 f_close(fil); } // 读文件 fr f_open(fil, 0:/LOG.TXT, FA_READ); if (fr FR_OK) { f_read(fil, read_buf, sizeof(read_buf), br); f_close(fil); } // 校验 if (memcmp(log_buf, read_buf, sizeof(log_buf)) 0) { printf(File read/write check OK!\n); }这段代码看着简单但实际跑的时候有几个点要注意。0:/LOG.TXT里的0:是FatFs的卷号前缀对应配置里的FF_VOLUMES编号没有这个前缀会返回FR_INVALID_DRIVE。写文件中间调用f_sync非常重要因为FatFs有扇区缓存不主动同步的话刚写完就拔U盘文件系统目录项可能还没来得及落到介质上数据会丢。实测中我还做了一项比较狠的测试循环写入100个文件每个文件1KB写完断电再用电脑读取校验。结果发现只要供电稳定、底层SCSI命令执行正确GD32450Z内部PHY主机模式跑U盘读写非常稳。全速模式下实测写速度大概在100KB/s左右高速模式能做到接近1MB/s对日志转储这种应用完全够用。5. 常见问题与排查技巧实录5.1 插上U盘没反应先查供电和VBUS控制这是我遇到最多的问题也是第一个要看的方向。插上U盘后程序毫无反应不要急着怀疑枚举代码先用万用表量VBUS引脚有没有稳定的5V再看PA9控制的电源开关是否正常打开。很多开发板把VBUS直接接在系统5V上觉得“反正U盘吃到电就行”实际上主机模式需要软件控制VBUS的上电时机——先检测到设备连接再开启VBUS最后执行复位。VBUS一直有电的话连接检测引脚的状态会异常枚举自然起不来。供电不足的症状更具迷惑性U盘插上后能检测到信号但一执行总线复位或读取描述符就失败有些U盘品牌甚至会在电平跌落时让MCU跟着复位。遇到这种情况先给VBUS加一个大容量电容再检查电源电路能否提供500mA以上电流。我的经验是U盘枚举这一下是最吃电流的等它进入工作状态后电流反而会降下来。5.2 枚举成功但文件系统挂载失败扇区大小与对齐问题如果你的串口已经打印出“USB枚举成功”但f_mount返回FR_DISK_ERR或者FR_NOT_READY那问题大概率出在底层介质参数没有对上。排查询问顺序是这样的先在MSC裸读测试里读逻辑扇区0确认能读到数据。如果连扇区0都读不出来检查disk_read里的GET_SECTOR_SIZE返回值和U盘真实扇区大小是否一致特别是遇到4K扇区U盘不统一的扇区大小会让文件系统完全无法解析。如果裸读能读到MBR但FatFs还是挂不上再看disk_ioctl里是否正确实现了GET_SECTOR_COUNT。有个项目里我把扇区总数算错了FatFs拿到一个比实际小的容量挂载时目录解析直接越界。另外一个高频问题是缓冲区对齐disk_read里如果用了DMA而FatFs回调传入的buf起始地址恰好只做了2字节对齐就会偶发数据错乱。解决方法是加一个强制4字节对齐的内部中转缓冲区数据先进中转区再拷走实测能消除绝大多数诡异问题。5.3 卡死、速度慢超时机制与多扇区传输USB主机模式下卡死几乎都是同一个原因某个USB请求发出去后程序一直在等传输完成标志但U盘因为内部错误永远不回CSW。解决方法是给每一个传输阶段都设置超时。比如等待CSW可以设置500ms超时超时后执行批量端点复位再重置整个传输状态。虽然U盘异常不常见但这个保护机制能在拔盘瞬间避免整个设备进入假死状态。速度慢的原因则集中在两点。第一底层用了单扇区读写FatFs每读一个扇区都要做一次完整CBW-CSW流程协议开销巨大。优化办法是在MSC层实现多扇区连续传输把一次文件读请求的多个扇区合成一个SCSI命令发出。第二USB工作在全速模式。全速带宽本身只有12Mbps理论极限也就1.5MB/s实际还要扣掉协议开销。如果项目对速度有要求一定要确认硬件走线的差分质量和串阻匹配然后把USB控制器切到高速模式。我在实际使用中还发现一个通用经验把FatFs的读写缓冲区和扇区数对齐到U盘内部块大小写性能会有肉眼可见的提升。比如U盘报告GET_BLOCK_SIZE是32个扇区那写文件时尽量让每次底层写入的扇区数接近32的倍数能明显减少U盘内部的读改写开销。最后再分享一个我自己这几年养成的调试习惯USB设备和文件系统这种多层协作的项目一定不要所有功能写完再上电调试那样出了问题完全不知道从哪里查起。先调通USB枚举再调通SCSI读扇区最后才挂FatFs每一层都要有独立的验证手段——串口打印状态、裸读扇区数据、文件读写校验。每一次都确认“这层真的通了”再往下一层走看起来多花了一点时间实际上反而是最快到终点的方式。后续如果还想把这个方案用得更深可以考虑在同一个USB主机接口上同时支持U盘和HID设备或者把f_mkfs集成进来做一键格式化这套底层架构都是可以直接复用的。
)
