AT32F437 USB HOST RT-thread u盘读写不稳定

只看该作者 · 2023-12-9 10:45

本帖最后由 TopV 于 2023-12-9 10:51 编辑

      主芯片AT32F437VMT7配合RT-Thread Studio 开发环境，RT-Thread 版本 4.1.0

      使用USB host 接U盘，发现很不稳定，简单的读写没问题，长期写入测试，会不定时出现USB口卡死的问题，调试发现是drv_usbfsh.c 里面的drv_pipe_xfer函数进入死循环了，此问题手里有三个U盘，新旧不一，牌子不同，有两个会出现此故障，一个不会。
      不清楚是不是RT-thread usb host框架的问题，RT-thread 论坛上也有很多反馈usb host 此问题的，都是各显神通，没有最终定论。

      希望咱雅特力可以给力些，看咱usb host驱动上还有啥完善的不，否则usb host 看着挺好，但无法实际工程应用，很是遗憾了。
      曾经想使用CherryUSB包来替换咱的usb 驱动，发现at32F437的usb host 不支持dma 没发使用CherryUSB了。。。。。

只看该作者 · 2023-12-11 12:55

能否提供有故障的U盘给我们确认？

只看该作者 · 2023-12-11 13:46

可以，给个地址我，我邮寄一个老的4G U盘，这个最容易出问题

只看该作者 · 2023-12-11 13:46

muyichuan2012 发表于 2023-12-11 12:55
能否提供有故障的U盘给我们确认？

可以，给个地址我，我邮寄一个老的4G U盘，这个最容易出问题

只看该作者 · 2023-12-12 09:22

雅特力收件地址：重庆市九龙坡区科城路60号康田西锦荟1栋10F
电话：86-23-6868 8899
收件人：李先生

只看该作者 · 2023-12-14 13:27

已经发出了，估计天气不好，要晚两天到了

只看该作者 · 2023-12-19 14:52

本帖最后由 TopV 于 2023-12-19 16:48 编辑

muyichuan2012 发表于 2023-12-12 09:22
雅特力收件地址：重庆市九龙坡区科城路60号康田西锦荟1栋10F
电话：86-23-6868 8899
收件人：李先生 ...

你好，查单号，应该是已经收到了，麻烦后续反馈下U盘测试情况吧

只看该作者 · 2023-12-22 09:25

您好，收到您寄来的u盘后进行了问题复现且调试，看起来是原驱动对个别u盘的适配上不是很完美。
附上一份调整后的drv_usbotgh.c驱动文件，我这边用您寄来的u盘测试看起来ok了，您可先测试看看。
谢谢您的问题反馈。

drv_usbotgh.zip (2.49 KB)

只看该作者 · 2023-12-22 10:49

多谢了，我下载测试下，给力！

只看该作者 · 2023-12-22 15:39

本帖最后由 TopV 于 2023-12-22 15:49 编辑

sheltonyu 发表于 2023-12-22 09:25
您好，收到您寄来的u盘后进行了问题复现且调试，看起来是原驱动对个别u盘的适配上不是很完美。
附上一份调 ...

新驱动，U盘实测效果挺好的，感谢！感谢！雅特力真给力

可以再咨询个问题吗？同样是基于RT-thread的，版本 4.1.0。使用USB device 实现虚拟U盘功能，可以让电脑直接访问at32F437的flash，功能已经实现，虚拟出2M的U盘空间。

但电脑往虚拟U盘中写入文件时，尤其时大于1M的文件时，电脑写入进度条会经常卡死，此时RT-thread并不会死机，拔插USB口后，电脑重新写入现象依旧。实际测试就是写入普通的pdf文件。麻烦看下这个是哪里问题呢？

实际测试时，如果修改rt-thread的内核文件usbdevice_core.c，将rt_usbd_thread_entry内的_data_notify(device, &msg.content.ep_msg);修改如下，

此时写入卡死的情况就没有再出现过了，就是写入速度不快。这样做应该不是最好的解决办法，盼大佬解惑了

只看该作者 · 2023-12-25 13:30

TopV 发表于 2023-12-22 15:39
新驱动，U盘实测效果挺好的，感谢！感谢！雅特力真给力

可以再咨询个问题吗？同样是基 ...

您好，使用usb device虚拟u盘，我有进行了实测，未复现出您所描述的问题现象。
我是将at32f435zmt7内部flash的后2M空间虚拟成了u盘，并存放单个文件大小为1.49MB的pdf文件，未出现进度条卡死的情况，且文件存储正常（因存储过程会有对flash进行一段一段擦写的动作，所以进度条会有一顿一顿的现象，进度条显示存放速度为80KB/s左右）。
请注意以下几点：
1. 实际芯片flash size及sector size，与代码中的是否一致
2.用来虚拟u盘的内部flash范围是否越界或是否存在与代码覆盖的情况
3.应用中用到了很多外设？因为从您的描述来看加上开关中断的临界区会好转，这个现象有点像各个外设的中断间的影响造成。我的测试环境只开了usb和console uart
4.可以选择chip_support_package中最新版at32支持包来测试看看是否是新旧支持包的差异造成。
如若问题还是存在，请将您的问题工程发出来，我再测试看看。

只看该作者 · 2023-12-26 14:20

本帖最后由 TopV 于 2023-12-26 14:32 编辑

sheltonyu 发表于 2023-12-25 13:30
您好，使用usb device虚拟u盘，我有进行了实测，未复现出您所描述的问题现象。
我是将at32f435zmt7内部fl ...

多谢答复，之前自己没有交代清楚，确实自己的 AT32F437工程里面应用外设较多。之前测试时使用的是0.1.3的包，下面测试时，已经更新至0.1.6。其他外设的端口均没有外接线路，只测试usb。自己今天又反复测试了下，当关闭网口，进程如下时：虚拟U盘写入发生死机的概率很小，

而当开启网口后，即使网口不收发数据，不插入网线，虚拟U盘写入仍会经常性卡死，进程如下

在网口开启的状态下，即使取消开启emac中断，即注释掉nvic_irq_enable(EMAC_IRQn, 0x07, 0);程序不再进入EMAC中断的情况下，虚拟U盘写入仍旧卡死。

rt-thread的工程都比较大，超出附件允许范围了，麻烦再测试下启用网口时的情况

只看该作者 · 2023-12-26 17:36

本帖最后由 sheltonyu 于 2023-12-26 17:37 编辑

TopV 发表于 2023-12-26 14:20
多谢答复，之前自己没有交代清楚，确实自己的 AT32F437工程里面应用外设较多。之前测试时使用的是0.1.3 ...

您好，我有将以太网加上后，一边ping包一边往U盘存放文件，测试也是ok的
附上我的测试工程，可在您的环境上试试看。

为了方便后续的高效沟通，您可加入雅特力QQ技术交流群

只看该作者 · 2023-12-27 10:38

本帖最后由 TopV 于 2023-12-27 10:56 编辑

sheltonyu 发表于 2023-12-26 17:36
您好，我有将以太网加上后，一边ping包一边往U盘存放文件，测试也是ok的
附上我的测试工程，可在您的环境 ...

十分感谢测试，在test程序的基础上，已经可以重现故障了
只要修改链接文件link.lds,将ROM起始地址设置为0x08040000,确保程序从flash256k以后开始运行，此时故障就出现了。和加不加lwip没关系。
我的项目中使用了qboot所以前面的128k空间留给boot了，导致app程序有部分运行在慢速的flash上，此时加入lwip后，导致USB部分代码位置变动，运行变慢，所以此状态下，去除lwip就正常，增加后就出故障了
再次感谢帮助，猜测原因应该在于咱at32内部flash运行速度有快慢之分，而usb部分对时序有要求，不清楚这么理解正确不
针对app处于flash256k后这种条件下,虚拟U盘的使用，不知道有更好的解决办法不

另外咱的QQ技术群很早就加入了，特别喜欢咱雅特力务实的特点，帮助用户解决各种问题。不过技术问题更喜欢论坛发帖的形式，这种更有连续性，更能留给后人一些经验教训。再次感谢了。

只看该作者 · 2023-12-29 13:24

本帖最后由 sheltonyu 于 2023-12-29 13:36 编辑

TopV 发表于 2023-12-27 10:38
十分感谢测试，在test程序的基础上，已经可以重现故障了
只要修改链接文件link.lds,将ROM起始地址 ...

您好，如您所说，AT32 MCU部分型号的flash中有零等待区和非零等待区的区分，在非零等待区间上运行代码相较于零等待区间效能要差一点。
我将ROM起始地址设置为0x08040000，也就是将代码全移到非零等待区后复现到问题。经调试后定位到是由于系统中usb device处理线程（rt_usbd_thread_entry）对邮箱队列的接收处理相对于零等待区时变慢了，而usb通信中的中断还是快速的上来（相对应的邮箱信号持续的往上发），遇到大数据量时累积一段时间后就可能将邮箱队列撑爆，而导致部分usb中断的实际处理信号被漏掉而影响了整个usb正常通信。
有以下两个处理方法请参考：
1.加大usb邮箱队列深度，原内核层usb驱动中usbdevice_core.c定的深度为16个，我测试改为32个ok（视应用情况而定），usbdevice_core.c + 2236行#define USBD_MQ_MAX_MSG 32
2.如若确认应用中未使用到SOF相关的内容，将SOF中断关闭也可解决。usbd_core.c + 932行USB_OTG_SOF_INT中断宏定义删除。

只看该作者 · 2024-1-8 11:25

大佬太给力，直接定位到问题并给出解决办法，感谢，怒赞!

只看该作者 · 2024-1-8 11:26

sheltonyu 发表于 2023-12-29 13:24
您好，如您所说，AT32 MCU部分型号的flash中有零等待区和非零等待区的区分，在非零等待区间上运行代码相较 ...

大佬太给力，直接定位到问题并给出解决办法，感谢，怒赞!

只看该作者 · 2024-1-19 09:13

sheltonyu 发表于 2023-12-22 09:25
您好，收到您寄来的u盘后进行了问题复现且调试，看起来是原驱动对个别u盘的适配上不是很完美。
附上一份调 ...

今天新驱动发现一个问题，有个U盘，新驱动不行，老的反而可以，看来U盘的兼容性确实挺不好搞的，期待更完善的驱动吧

只看该作者 · 2024-1-23 13:50

TopV 发表于 2024-1-19 09:13
今天新驱动发现一个问题，有个U盘，新驱动不行，老的反而可以，看来U盘的兼容性确实挺不好搞的，期待更完 ...

您好，收到新寄来的问题u盘后进行了分析。
抓包看到该u盘对其中有些命令的响应时间相比于其他正常u盘更慢，而新修改的驱动中做了retry次数限定10000，将retry次数加大就可以。
修改方式在之前更新后的驱动上进行完善：drv_usbotgh.c + 222行 "retry = 10000" 改为 "retry = 0xFFFFFFFF"