[资料]

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

2021-6-2 15:22:22 4719 STM32F4 OTG Bulk NAK

0 问题：某客户使用 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，如图然后在库代码处理控制传输时，如果检测到这个状态，就会重新发送 OUT 令牌和数据包，如图因此，当 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 阶段的读取，如图：需要对每次 BULK IN 传输后检测状态，如果收到 NAK 则重新发起刚才的那次 BULK IN 传输，如图：经过以上修改，以 FS 和 HS 都能对 U 盘正确读取。 2
举报淘帖0 只看该作者相关推荐 • 在OTG主机库对NAK的处理方案 328 • 关于STM32L4x6上OTG-FS的一些问题求解 324 • STM32F4 HAL库开发的知识点汇总，错过绝对后悔 1262 • 萌新求助，求大佬分享STM32F4定时器的知识点 632 • 关于STM32F4外设配置速查的知识点不看肯定后悔 977 • STM32F4上CCM内存的使用小结 2012 • STM32F4时钟系统的知识 1483 • 在STM32F407上做FFT的运算 1530 • 【每日一知识点】STM32F4中OTG 主机对于 NAK 的延迟处理 5466 • 请问如何在STM32F407的USB_MSC例程上实现USB_OTG_FS与PC之间的bulk模式传输数据 7063 1条评论发表评论只看该作者