STM32H750读U盘一直在USBH_MSC_RdWrProcess死循环

l4568527193

STM32H750 读U盘一直在USBH_MSC_RdWrProcess死循环，然后就超时返回错误了

eric2013

枚举U盘成功没。

miaoguoqiang

我的程序今天也突然出现了。能挂载并且能读取目录下的文件，但是过一会儿就自动进入那个循环了。

eric2013

miaoguoqiang 发表于 2024-6-29 14:37
我的程序今天也突然出现了。能挂载并且能读取目录下的文件，但是过一会儿就自动进入那个循环了。

不排除，对你这个U盘的兼容不太好。

miaoguoqiang

eric2013 发表于 2024-6-30 08:25
不排除，对你这个U盘的兼容不太好。

不是兼容性问题。在H750温度升高后，就会出现这个异常。USBH_CtlReq函数，一直在CMD_WAIT，USBH_HandleEnum() returns USBH_BUSY (in the ENUM_IDLE state);

eric2013

miaoguoqiang 发表于 2024-7-1 14:12
不是兼容性问题。在H750温度升高后，就会出现这个异常。USBH_CtlReq函数，一直在CMD_WAIT，USBH_HandleEn ...

温度身高后，立即冷启动，也就是重新上电是否正常。如果正常，应该和温度关系不大。

miaoguoqiang

eric2013  2024-7-2 09:04
ú

480M200M

eric2013

miaoguoqiang 发表于 2024-7-2 15:52
480M200M

温度身高后，立即冷启动，也就是重新上电是否正常。如果正常，应该和温度关系不大。

miaoguoqiang

eric2013 发表于 2024-7-3 10:24
温度身高后，立即冷启动，也就是重新上电是否正常。如果正常，应该和温度关系不大。

上次的回复居然乱码了。用电吹风加热后启动也是相同的问题。只有冷却后上电才是正常的。200M主频就没出问题，确实奇怪。还有ST的USB库异常的时候总是会卡死其他任，有没有其他好一点的USB方案

eric2013

miaoguoqiang 发表于 2024-7-3 21:29
上次的回复居然乱码了。用电吹风加热后启动也是相同的问题。只有冷却后上电才是正常的。200M主频就没出问 ...

1、有没有摸过以太网PHY芯片，是否也非常热。
2、ST的这个USB库，接口函数里面接入OS的管理机制没，加入的话会好很多。

miaoguoqiang

eric2013 发表于 2024-7-4 09:15
1、有没有摸过以太网PHY芯片，是否也非常热。
2、ST的这个USB库，接口函数里面接入OS的管理机制没，加入 ...

1.没有加以太网PHY，而且板子温度不是很高，60度左右就不行。
2.DEVICE的库usbd_conf.h中没有USE_OS相关宏定义，HOST倒是有OS定义

eric2013

miaoguoqiang 发表于 2024-7-5 09:27
1.没有加以太网PHY，而且板子温度不是很高，60度左右就不行。
2.DEVICE的库usbd_conf.h中没有USE_OS相关 ...

那确实有点奇怪。

另外你的主控芯片平时运行有60℃。确实有点高

木鱼水心111

我也遇到了类似的问题，读取一段时间正常，然后一直卡在 while (USBH_MSC_RdWrProcess(phost, lun) == USBH_BUSY)，仿真看了phost->Timer时间也不会累加，不会报超时

人生之际

我今天也发现了，和楼上不同，我的会在10秒超时后返回FR_DISK_ERR（1）错误，本来我的IWDG只有2秒,老自动复位，把IWDG改超长了,才发现是f_read（）的错误。
我的现象：
刚挂载U盘读写都正常，如果f_open后，直接一块块往缓冲区读取，也能从头到尾读完正常。但是如果一边读一遍发往串口（因为串口比较慢），发了几分钟就会不定位置f_read死等在上面那个 while (USBH_MSC_RdWrProcess(phost, lun) == USBH_BUSY)里面，返回的时候已经是10秒（默认）超时了，并且再f_read也直接报错返回（因为FIL结构体里已经置位了1号错误。）
此时f_read再读，f_close，再f_open，f_mount(NULL,再f_mount(&USBHFatFS,..都没有用，永远是错误1返回。只有拔掉U盘，再次插入，再f_mount才能再正常读写一段时间（几分钟）。
每次f_read出错的文件位置不同，时间不定。。。。

搞得我现在临时绕过方法：U盘插上，立刻将U盘文件复制到内部SPI Flash上（也挂载有FatFS），然后打开SPI Flash上的文件，向串口发送，能够从头到尾发完。
如果是U盘上的文件直接发，基本没法发完（4MB的文件，正常要6-7分钟，一般在2-5分钟就出错）。

我上面的说法可能会被误认为只能在U盘插上后几分钟内正常使用，实际不是这样的，实际是插上后不读写没问题，以后任意时间集中短暂读也没问题，慢悠悠长时间读读停停就可能出错，表现为突然在上述超时循环里打转10秒后错误返回，这时候底层为啥不能完成，USB_SCSI类的驱动和接口太复杂，作为一般用户，st的其他驱动还能分析分析，USB,NET之类的实在跟不进去

eric2013

人生之际 发表于 2024-10-29 20:15
我今天也发现了，和楼上不同，我的会在10秒超时后返回FR_DISK_ERR（1）错误，本来我的IWDG只有2秒,老自动复 ...

是不是你的串口中断优先级高于USB中断优先级

人生之际

eric2013 发表于 2024-10-30 09:59
是不是你的串口中断优先级高于USB中断优先级

我的USB文件读着读着就读取错误的问题可能解决了：
最终发现我关了空闲回调里进入SLEEP的语句就正常了
void vApplicationIdleHook( void )
{
;//        HAL_PWR_EnterSLEEPMode(0, PWR_SLEEPENTRY_WFI);//WFI指令进入睡眠模式
}
（目前正常循环操作了10次以上了，4MB左右的文件每次读取发送流程大概7分钟），
以前持续复制文件时，包括SFlash芯片全目录复制到U盘或者反过来，循环中没有释放系统，所以没有发现有问题。
而读取一个扇区，串口发一个扇区内容（还有协议包头包尾，等待应答），会在串口交互中挂起线程（串口DMA事件交互)，从而引发FREERTOS不断的调用vApplicationIdleHook。内核进入SLEEP模式

我猜想，SLEEP模式中有可能某一次USBH的中断没有唤醒或者丢掉，导致USBHcore的寄存器状态位错误，从而再也无法恢复正常读写。但不是每次SLEEP都会对USB内核产生错误影响，不然不会在成千上万次的SLEEP中随机才错误一次。以前Idle有Sleep的时候，如上贴所属，7分钟的发送中随机某一个分钟开始读取U盘失败不可再恢复。
"FR_DISK_ERR：底层硬件错误",                                             /* (1) A hard error occurred in the low level disk I/O layer */
返回后，无论关闭文件再开，反挂载再挂载等文件系统操作，都是无法消除的