汇集网友智慧，解决技术难题
赞0
答案很长吧 发表于 2020-11-18 09:50 不可能，一定是你设置的问题，没有设置好造成的。
评论
2020-11-18
发呆二极管 发表于 2020-11-18 00:54 能找到问题就好。反正GD的USB库确实问题挺多的，以前FS的库我就被坑过，当时做一个功能怎么调试都有问题 ...
lewlew 发表于 2020-11-17 09:44 不知道怎么联系 GD32 的技术客服或者 FAE, 所以打算自己跟进底层代码看看究竟是哪里出了问题. 接收数据 ...
发呆二极管 发表于 2020-11-16 20:21 没做过HS开发，只做过FS的，仅参与讨论，说错莫怪……包大小是分模式的吧，中断的话记得HS最高好像就512B？ ...
2020-11-17
2020-11-16
点击图片添加到编辑器内容中
点击文件名将附件添加到文章中
提交
tyw
319个答案
天意无罪
287个答案
xch
239个答案
jjjyufan
209个答案
coody
203个答案
LcwSwust
172个答案
chunyang
135个答案
地瓜patch
128个答案
问答
赞0
看来你是没被GD的库坑过
评论
2020-11-18
赞0
例程里面的 msc_udisk 完全没问题, 只有 cdc_acm 有这种问题. 一样的设置
评论
2020-11-18
赞0
我这里打了几块板子, 方便我发你验证一下吗?
评论
2020-11-18
赞0
评论
2020-11-18
赞0
是的, 之前我搞 F303 的时候就是, 换了最新固件才解决.
老固件插电脑上根本没反应
评论
2020-11-18
赞0
能找到问题就好。反正GD的USB库确实问题挺多的，以前FS的库我就被坑过，当时做一个功能怎么调试都有问题，后来发现是库的问题后，从原厂要了最新的固件库才解决，好家伙，原来他们是有新版固件库不发布……这个问题你确实是可以跟FAE提，你要是有认识的代理的话，可以通过代理联系他们找到原厂。
评论
2020-11-18
赞0
不知道怎么联系 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-17
赞0
例程代码没改, 默认应该是中断模式, 512字节一个包
评论
2020-11-17
赞0
评论
2020-11-16
赞0
1. 为了支持USB HS, 硬件上使用了 USB3300 这个 PHY, 并通过 ULPI 与芯片连接
2. 例程代码编译时开启了:
USE_USB_HS
USE_ULPI_PHY
评论
2020-11-16
您需要登录后才可以回复 登录 | 注册