OTG主机库在不同传输类型上对NAK的处理.pdfVIP

OTG 主机库在BULK 传输上对NAK 的处理 问题： 某客户使用 STM32F4 的OTG 库做USB 主机控制Wifi 网卡。使用BULK 传输类型时，从数据读取数据时， 如果设备返回需要把设备返回的NAK 状态告知上层应用，该如何修改OTG 库。 调研： 先来看看OTG 库当前对BULK 类型传输，IN 和OUT 方向上的NAK 的处理方式： @ BULK IN 通道 If (nak) 重新使能该通道： CHENA=1, CHDIS=0 记录通道状态： Pdev-hostHC_Status[num] = HC_NAK 清零NAK 位 退出该中断处理程序(ISR) 一旦重新使能该通道，主机硬件又自动发送IN 令牌来企图从设备获取数据，直到设备准备好数据后， 不再回复NAK 握手，而是回复主机要获取的数据，然后主机硬件回复ACK 来结束本次transfer 。 BULK IN 通道对 NAK 的处理和CTRL IN 通道对 NAK 的处理，在ISR 中是一样的；但是在驱动库里， 对CTRL IN 有超时限制，而对BULK IN 没有。就是说对于常用来做枚举传输的CTRL 传输，当启动 从设备获取信息，但是久久未得的情况下，会走到Timeout 的处理分支。从代码里我们可以看到 usbh_core.c USBH_HandleControl() { case CTRL_DATA_IN : 发出IN 令牌 case CTRL_DATA_IN_WAIT : get_urb_state if (done) if (stall) if (error) if (超时) USBH Fail 但是BULK IN 通道对NAK 的接收没有超时控制，因为BULK 传输本身的性质就是不保证带宽的，即 如果主机上有很多其他优先级更高的周期类型的传输（同步ISO 传输和中断INT 传输），则在BULK 传输有可能无限延迟。 CTRL IN 对NAK 有超时处理，那么CTRL OUT 对NAK 是如何处理的呢？ 从代码里可以看到CTRL OUT 收到NAK 后会把该状态上传APP ，如图 @ CTRL OUT 通道 If (nak) 打开通道halt 中断： CHMM @ OTG_FS_HCINTMSK Halt 该通道： CHENA=0, CHDIS=1 记录通道状态：Pdev-hostHC_Status[num] = HC_NAK 错误计数清零 清零NAK 标志：@HCINTx 退出该中断处理程序(ISR)，又进入通道halt 中断 If (halt) 关闭通道halt 中断 记录通道状态以上传APP ：Pdev-host.URB_State[num] = URB_NOTREADY 然后在库代码处理控制传输时，如果检测到这个状态，就会重新发送OUT 令牌和数据包，如图 usbh_core.c USBH_HandleControl() { case CTRL_DATA_OUT : 发出OUT 令牌和数据包 case CTRL_DATA_OUT_WAIT : get_urb_state if (done) if (stall) if (error) if (URB_NOTREADY) 回到之前的case CTRL_DATA_OUT 因此，当CTRL IN 收到NAK 后，如果想把状态上传给App ，则可以模仿CTRL OUT 对NAK 的处理。 首先，ISR 中的处理可以模仿CTRL OUT，在BULK 传输的处理中，对每次发送IN 令牌的