发 帖  
原厂入驻New
[资料]

【每日一知识点】在STM32F4上OTG 主机库在 BULK 传输上对 NAK 的处理

2021-6-2 15:22:22  1804 STM32F4 OTG Bulk NAK
分享
问题:
某客户使用 STM32F4 的 OTG 库做 USB 主机控制 Wifi 网卡。使用 BULK 传输类型时,从数据读取数据时,如果设备返回需要把设备返回的 NAK 状态告知上层应用,该如何修改 OTG 库。
调研:

先来看看 OTG 库当前对BULK  类型传输,IN 和 和 OUT 方向上的NAK的处理方式:
6.2-1.png
一旦重新使能该通道,主机硬件又自动发送 IN 令牌来企图从设备获取数据,直到设备准备好数据后,不再回复 NAK 握手,而是回复主机要获取的数据,然后主机硬件回复 ACK 来结束本次 transfer。
BULK IN  通道对 NAK  的处理和 CTRL IN  通道对 NAK  的处理,在 ISR  中是一样的;但是在驱动库里, 对 CTRL IN  有超时限制,而对 BULK IN  没有。就是说对于常用来做枚举传输的 CTRL 传输,当启动从设备获取信息,但是久久未得的情况下,会走到 timeout 的处理分支。从代码里我们可以看到
6.2-2.png
但是 BULK IN 通道对 NAK 的接收没有超时控制,因为 BULK 传输本身的性质就是不保证带宽的,即如果主机上有很多其他优先级更高的周期类型的传输(同步 ISO 传输和中断 INT 传输),则在 BULK传输有可能无限延迟。
CTRL IN 对 NAK 有超时处理,那么 CTRL OUT 对 NAK 是如何处理的呢?
从代码里可以看到 CTRL OUT  收到 NAK  后会把该状态上传 APP,如图
6.2-3.png
然后在库代码处理控制传输时,如果检测到这个状态,就会重新发送 OUT 令牌和数据包,如图
6.2-4.png
因此,当 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 阶段的读取,如图:
6.2-5.png
需要对每次 BULK IN 传输后检测状态,如果收到 NAK 则重新发起刚才的那次 BULK IN 传输,如图:
6.2-6.png
经过以上修改,以 FS 和 HS 都能对 U 盘正确读取。



2
分享淘帖 显示全部楼层
· 2021-6-2 16:29:19
学习了学习了,感谢楼主

评论

高级模式
您需要登录后才可以回帖 登录 | 注册

声明:本文内容及配图由入驻作者撰写或者入驻合作网站授权转载。文章观点仅代表作者本人,不代表电子发烧友网立场。文章及其配图仅供工程师学习之用,如有内容图片侵权或者其他问题,请联系本站作侵删。 侵权投诉
发资料
关闭

站长推荐 上一条 /5 下一条

快速回复 返回顶部 返回列表