【GD32的BUG】GD32F405 使用 USB HS 无法接收大于512字节的数据

只看该作者 · 2020-11-16 14:13

本帖最后由 lewlew 于 2020-11-17 09:50 编辑

单片机烧录的是 GD32F4xx_Firmware_Library_V2.1.1 固件库自带的CDC例程, 路径是:
Examples\USB\USB_Device\cdc_acm

代码只修改了 GPIO 初始化部分, 以匹配我使用的 GD32F405RGT6 的 ULPI 引脚.

烧录后插上电脑, 串口助手能正常通信, 发送小于等于 512 字节的数据完全没问题, 但是超过 512 字节的数据就会丢失.

请问这是什么情况?

只看该作者 · 2020-11-16 16:48

注意:
1. 为了支持USB HS, 硬件上使用了 USB3300 这个 PHY, 并通过 ULPI 与芯片连接

2. 例程代码编译时开启了:
USE_USB_HS
USE_ULPI_PHY

只看该作者 · 2020-11-16 20:21

没做过HS开发，只做过FS的，仅参与讨论，说错莫怪……包大小是分模式的吧，中断的话记得HS最高好像就512B？如果是bulk的话应该才没这个限制吧。

只看该作者 · 2020-11-17 08:57

发呆二极管发表于 2020-11-16 20:21
没做过HS开发，只做过FS的，仅参与讨论，说错莫怪……包大小是分模式的吧，中断的话记得HS最高好像就512B？ ...

例程代码没改, 默认应该是中断模式, 512字节一个包

只看该作者 · 2020-11-17 09:44

发呆二极管发表于 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 的技术人员能尽快解决!

只看该作者 · 2020-11-18 00:54

lewlew 发表于 2020-11-17 09:44
不知道怎么联系 GD32 的技术客服或者 FAE, 所以打算自己跟进底层代码看看究竟是哪里出了问题.

接收数据 ...

能找到问题就好。反正GD的USB库确实问题挺多的，以前FS的库我就被坑过，当时做一个功能怎么调试都有问题，后来发现是库的问题后，从原厂要了最新的固件库才解决，好家伙，原来他们是有新版固件库不发布……这个问题你确实是可以跟FAE提，你要是有认识的代理的话，可以通过代理联系他们找到原厂。

只看该作者 · 2020-11-18 08:58

发呆二极管发表于 2020-11-18 00:54
能找到问题就好。反正GD的USB库确实问题挺多的，以前FS的库我就被坑过，当时做一个功能怎么调试都有问题 ...

是的, 之前我搞 F303 的时候就是, 换了最新固件才解决.
老固件插电脑上根本没反应

只看该作者 · 2020-11-18 09:50

不可能，一定是你设置的问题，没有设置好造成的。

只看该作者 · 2020-11-18 10:35

答案很长吧发表于 2020-11-18 09:50
不可能，一定是你设置的问题，没有设置好造成的。

我这里打了几块板子, 方便我发你验证一下吗?

只看该作者 · 2020-11-18 10:36

答案很长吧发表于 2020-11-18 09:50
不可能，一定是你设置的问题，没有设置好造成的。

例程里面的 msc_udisk 完全没问题, 只有 cdc_acm 有这种问题. 一样的设置

只看该作者 · 2020-11-18 11:08

答案很长吧发表于 2020-11-18 09:50
不可能，一定是你设置的问题，没有设置好造成的。

看来你是没被GD的库坑过

只看该作者 · 2020-11-18 11:08

lewlew 发表于 2020-11-18 10:35
我这里打了几块板子, 方便我发你验证一下吗?

有多余的板子玩吗

只看该作者 · 2020-11-18 14:28

发呆二极管发表于 2020-11-18 11:08
有多余的板子玩吗

有, 可以加个联系方式吗?

只看该作者 · 2020-11-18 20:23

本帖最后由发呆二极管于 2020-11-18 20:45 编辑

lewlew 发表于 2020-11-18 14:28
有, 可以加个联系方式吗?

要是有多余的板子的话我就买个也回来玩玩试试

只看该作者 · 2020-11-18 20:44

用国产芯片，要有踩坑的觉悟和能力。

只看该作者 · 2020-11-18 21:35

imdx 发表于 2020-11-18 20:44
用国产芯片，要有踩坑的觉悟和能力。

发现BUG根源的能力有，但是修复BUG所需的一些细节，比如中断为什么丢了，可能只有官方的人才知道。

只看该作者 · 2020-11-19 09:19

需要更改头文件的，更改头文件才可以使用的。

只看该作者 · 2020-11-19 09:29

真爱吴迪迪发表于 2020-11-19 09:19
需要更改头文件的，更改头文件才可以使用的。

现在是能通信, 只是数据不完整. 改头文件可以解决?

只看该作者 · 2020-11-20 15:12

已经与 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 字节后, 依然存在收发长度不一致的问题.
正在与工程师继续沟通中...

只看该作者 · 2022-4-26 15:36

lewlew 发表于 2020-11-16 16:48
注意:
1. 为了支持USB HS, 硬件上使用了 USB3300 这个 PHY, 并通过 ULPI 与芯片连接

楼主有没有用STM32F系列单片机芯片驱动USB3300、USB3320、CH132这类ULPI接口芯片的代码？现在在学习相关知识想看看代码了解得更快一些，谢谢