【GD32的BUG】GD32F405 使用 USB HS 无法接收大于512字节的数据
本帖最后由 lewlew 于 2020-11-17 09:50 编辑单片机烧录的是 GD32F4xx_Firmware_Library_V2.1.1 固件库自带的CDC例程, 路径是:
Examples\USB\USB_Device\cdc_acm
代码只修改了 GPIO 初始化部分, 以匹配我使用的 GD32F405RGT6 的 ULPI 引脚.
烧录后插上电脑, 串口助手能正常通信, 发送小于等于 512 字节的数据完全没问题, 但是超过 512 字节的数据就会丢失.
请问这是什么情况? 注意:
1. 为了支持USB HS, 硬件上使用了 USB3300 这个 PHY, 并通过 ULPI 与芯片连接
2. 例程代码编译时开启了:
USE_USB_HS
USE_ULPI_PHY
没做过HS开发，只做过FS的，仅参与讨论，说错莫怪……包大小是分模式的吧，中断的话记得HS最高好像就512B？如果是bulk的话应该才没这个限制吧。 发呆二极管 发表于 2020-11-16 20:21
没做过HS开发，只做过FS的，仅参与讨论，说错莫怪……包大小是分模式的吧，中断的话记得HS最高好像就512B？ ...
例程代码没改, 默认应该是中断模式, 512字节一个包 发呆二极管 发表于 2020-11-16 20:21
没做过HS开发，只做过FS的，仅参与讨论，说错莫怪……包大小是分模式的吧，中断的话记得HS最高好像就512B？ ...
不知道怎么联系 GD32 的技术客服或者 FAE, 所以打算自己跟进底层代码看看究竟是哪里出了问题.
接收数据的关键回调是 cdc_acm_out, 调试发现该函数只在 usbd_isr 的 OEPIF 分支内被调用,
遂在 usbd_isr 内所有中断分支都打了个输出日志.
然后就观察到一个有意思的现象:
数据是在 RXFNEIF 里分批次接收的, 收了 2 次会来一个 OEPIF, 通知上层来取数据.
发送超过 512 字节的数据时, 日志是这这样的:
00> RXFNEIF
00> RXFNEIF
00> OEPIF
00> * cdc_acm_out: xfer_count=512, ep_num=3
00> RXFNEIF
也就是说, 收到 2 个 RXFNEIF 触发 OEPIF/cdc_acm_out 后, 又来了一个 RXFNEIF, 但是之后就再也没有 OEPIF 了.
调试发现超出 512 字节的数据确实在第三个 RXFNEIF 里成功收到了, 只是因为没有来 OEPIF 导致没通知到上层.
我想问题的关键应该在这里, 如果能够超时主动触发一下 OEPIF/cdc_acm_out 可能问题就解决了.
目前看来应该是固件库自身的 BUG, 希望 GD32 的技术人员能尽快解决! lewlew 发表于 2020-11-17 09:44
不知道怎么联系 GD32 的技术客服或者 FAE, 所以打算自己跟进底层代码看看究竟是哪里出了问题.
接收数据 ...
能找到问题就好。反正GD的USB库确实问题挺多的，以前FS的库我就被坑过，当时做一个功能怎么调试都有问题，后来发现是库的问题后，从原厂要了最新的固件库才解决，好家伙，原来他们是有新版固件库不发布……这个问题你确实是可以跟FAE提，你要是有认识的代理的话，可以通过代理联系他们找到原厂。 发呆二极管 发表于 2020-11-18 00:54
能找到问题就好。反正GD的USB库确实问题挺多的，以前FS的库我就被坑过，当时做一个功能怎么调试都有问题 ...
是的, 之前我搞 F303 的时候就是, 换了最新固件才解决.
老固件插电脑上根本没反应 不可能，一定是你设置的问题，没有设置好造成的。 答案很长吧 发表于 2020-11-18 09:50
不可能，一定是你设置的问题，没有设置好造成的。
我这里打了几块板子, 方便我发你验证一下吗? 答案很长吧 发表于 2020-11-18 09:50
不可能，一定是你设置的问题，没有设置好造成的。
例程里面的 msc_udisk 完全没问题, 只有 cdc_acm 有这种问题. 一样的设置 答案很长吧 发表于 2020-11-18 09:50
不可能，一定是你设置的问题，没有设置好造成的。
看来你是没被GD的库坑过{:titter:} lewlew 发表于 2020-11-18 10:35
我这里打了几块板子, 方便我发你验证一下吗?
有多余的板子玩吗{:titter:} 发呆二极管 发表于 2020-11-18 11:08
有多余的板子玩吗
有, 可以加个联系方式吗? 本帖最后由 发呆二极管 于 2020-11-18 20:45 编辑
lewlew 发表于 2020-11-18 14:28
有, 可以加个联系方式吗?
要是有多余的板子的话我就买个也回来玩玩试试{:titter:} 用国产芯片，要有踩坑的觉悟和能力。 imdx 发表于 2020-11-18 20:44
用国产芯片，要有踩坑的觉悟和能力。
发现BUG根源的能力有，但是修复BUG所需的一些细节，比如中断为什么丢了，可能只有官方的人才知道。 需要更改头文件的，更改头文件才可以使用的。 真爱吴迪迪 发表于 2020-11-19 09:19
需要更改头文件的，更改头文件才可以使用的。
现在是能通信, 只是数据不完整. 改头文件可以解决? 已经与 GD32 工程师取得联系, 得到了一个暂时缓解的办法.
基于 F4XX 2.1.1 固件库版本 按以下流程操作:
1. 修改 Firmware/GD32F4xx_usb_library/driver/Source/drv_usbd_int.c:353 行
把
if ((1U == ep_num)
修改为
if ((3U == ep_num)
2. 修改 Firmware/GD32F4xx_usb_library/device/class/cdc/Include/cdc_acm_core.h:41 行
把
#define USB_CDC_RX_LEN 64
修改为
#define USB_CDC_RX_LEN USB_CDC_DATA_PACKET_SIZE
之所以说暂时缓解, 是因为测试发现, 发送 13313 字节后, 依然存在收发长度不一致的问题.
正在与工程师继续沟通中... lewlew 发表于 2020-11-16 16:48
注意:
1. 为了支持USB HS, 硬件上使用了 USB3300 这个 PHY, 并通过 ULPI 与芯片连接
楼主有没有用STM32F系列单片机芯片驱动USB3300、USB3320、CH132这类ULPI接口芯片的代码？现在在学习相关知识想看看代码了解得更快一些，谢谢
页:
[1]