基于 CherryUSB 调试 dwc2 usb host 笔记

RT-Thread物联网操作系统 2022-06-15 10:11:13

本文由RT-Thread论坛用户@sakumisu原创发布：https://club.rt-thread.org/ask/article/9c31ce71ead26c2b.html
背景

之前适配 DWC2 USB IP 的时候，主要是基于 st 的 hal 库来走的，当时我就对他们的 hal 库代码不满，只是无奈，迫于时间就没重构，果不其然，usb bug 一堆，随意举例，这还只是冰山一角。
https://club.rt-thread.org/ask/article/dac2a83e018f6ad2.html

https://club.rt-thread.org/ask/article/b39785f4dd8a6032.html

再论 usb 的性能，那 hal 库写的，性能直接歇菜，根本没法用。
排坑

ok，现在我们开始一步步排坑

    全局中断 SOF
    首先是全局中断 SOF ,这是一个比较坑的，尤其是带了 OS 以后，几个意思，跟我 os 抢中断呢？sof 中断 1ms会触发一次，很费中断。为什么会有这个中断开启？后面再来说，结论就是 dwc2 这个ip太辣鸡，硬件做的很随意，功能没有做到硬件上去，而这个 sof 主要就是给中断传输和同步传输用的。
    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-wIthnmr5-1655258913676)(https://oss-club.rt-thread.org/uploads/20220613/5b84aa1d18091292a73ad9f74193620e.png “QQ图片20220613230829.png”)]

HCFG 中的 bit 0-1

这也是坑，我们直接看结论，人家手册里说了，每次设置时，需要复位，st 代码中楞是一个字没看见。小坑
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-2u5ueiC6-1655258913677)(https://oss-club.rt-thread.org/uploads/20220613/31c9536bc90106277ea899242d32e1d0.png “QQ截图20220613231215.png”)]

HCINTMSK 中的 USB_OTG_HCINTMSK_NAKM

这里面中断标志那是相当多，最坑的是什么，USB_OTG_HCINTMSK_NAKM,我可以说，论坛出现的所有 NAK 的原因都是他造成的，什么枚举 NAK,U盘 NAK，都是他。究其原因，NAK 表示当前没有准备好，需要重试，但是其实并不需要，st 的代码中，进入 NAK 中断以后会关闭当前通道传输，然而，对于控制和批量传输这是没有必要的，传输是可以等到完成的。开了这个，就会造成，各种地方需要手动重发，然后读 HAL_HCD_HC_GetURBState，没有必要，关掉该中断给你带来无限可能。

原文链接：https://blog.csdn.net/rtthreadiotos/article/details/125291738

...全文