STMCU小助手
发布时间:2022-2-11 18:28
|
问题:某客户使用 STM32F4 的 OTG 库做 USB 主机控制 Wifi 网卡。使用 BULK 传输类型时,从数据读取数据时,如果设备返回需要把设备返回的 NAK 状态告知上层应用,该如何修改 OTG 库。 调研: 先来看看 OTG 库当前对 BULK 类型传输,IN 和 OUT 方向上的 NAK 的处理方式:
一旦重新使能该通道,主机硬件又自动发送 IN 令牌来企图从设备获取数据,直到设备准备好数据后,不再回复 NAK 握手,而是回复主机要获取的数据,然后主机硬件回复 ACK 来结束本次 transfer。 BULK IN 通道对 NAK 的处理和 CTRL IN 通道对 NAK 的处理,在 ISR 中是一样的;但是在驱动库里,对 CTRL IN 有超时限制,而对 BULK IN 没有。就是说对于常用来做枚举传输的 CTRL 传输,当启动从设备获取信息,但是久久未得的情况下,会走到 Timeout 的处理分支。从代码里我们可以看到
但是 BULK IN 通道对 NAK 的接收没有超时控制,因为 BULK 传输本身的性质就是不保证带宽的,即如果主机上有很多其他优先级更高的周期类型的传输(同步 ISO 传输和中断 INT 传输),则在 BULK传输有可能无限延迟。 CTRL IN 对 NAK 有超时处理,那么 CTRL OUT 对 NAK 是如何处理的呢? 从代码里可以看到 CTRL OUT 收到 NAK 后会把该状态上传 APP,如图
因此,当 CTRL IN 收到 NAK 后,如果想把状态上传给 App,则可以模仿 CTRL OUT 对 NAK 的处理。首先, ISR 中的处理可以模仿 CTRL OUT,在 BULK 传输的处理中,对每次发送 IN 令牌的地方(USBH_BulkReceiveData)查询传输状态,如果 URB_NOTREADY 就由 App 来决定如何处理。 处理: 基于 U 盘读写的例程,在每次 USBH_BulkReceiveData 之后检查状态,如果是 URB_NOTREADY 就重新发送 IN 令牌。于是全项目搜索 USBH_BulkReceiveData,有三个地方,且都在USBH_HandleBOTXfer()中调用,即在 BOT 传输中若干次读数据阶段(多次数据包整数长度读取和最后一次的尾巴数据读取)和 CSW 阶段的读取,如图:
修改后的固件代码,请参看附件压缩包。 |
【福利三:逢7发帖赢大礼】4、基于STM32G070板子SPI flash 移植SFUD库
【福利三:逢7发帖赢大礼】基于STM32G070板子的uart shell移植设计
【福利三:逢7发帖赢大礼】3、基于STM32G070板子的YModem串口协议通信
【福利三:逢7发帖赢大礼】2、基于STM32G070板子的OLED移植U8G2库
实战经验 | ClassB功能安全认证代码与应用代码分区的实现要点
STM32G0 系列 I2C 通信异常典型案例分析与解决方案总结
经验分享 | LAT1490 两个STM32G0 I2C 通信异常的案例分析
经验分享 | STM32G0 I2C bootloader Go 命令后调试连接失败:DBG_SWEN 位复位修复
经验分享 | STM32G0B1 待机模式意外唤醒深度解析:RTC 结构体未初始化的隐形坑
经验分享 | STM32G0B1 待机模式意外唤醒深度解析:RTC 结构体未初始化的隐形坑
微信公众号
手机版