2015-11-05 03:34 AM
hi,
i am working on usbh+fatfs code generated from STM32CcubeMX. sometimes USBh fails to read/write data on usb drive. f_read/f_write/f_open returns FR_DISK_ERRon going in little depth i found that data is written/read in while loop in msc layer. program will come out of this while loop only on completion of write/read process or if timeout(10sec) occurs. i found that sometimes timeout occurs and this causes FR_DISK_ERR.i have two questions:1). this write fail happens sometimes(not always). so what can be the reason that it happens sometimes. in what direction i should debug.2) how to recover from this FR_DISK_ERR, as after this no USB operation works.any ideas?? #fr_disk_err #fat #usb_otg_fs2015-11-05 10:32 AM
You're going to have to manage the recovery/retry is the DISKIO.C layers and below, once the error gets back up into FatFs it's just going to be a fatal error on the read/write, and people rarely deal with these kind of errors if they get up to the STDIO file access level, where if they pay attention to the failure will give up on the file, and provide user feedback in the nature of a being unable to open/use a file.
You'll need to get significantly more familiar with the USB stack implementation to be able to resolve this.2015-11-05 10:40 PM
thanks clive1...
i went little further on debugging and found that:-
''once the error gets back up into FatFs it's just going to be a fatal error on the read/write''
what if i take back up of fatfs structure before going to read/write and if error occur, reload value from my back in fatfs structure and try once or twice? is it right way in ur opinion?''You'll need to get significantly more familiar with the USB stack implementation to be able to resolve this.''
well yes.. sometimes i find USB stack pretty complex. :) but anyhow, i m working on this FR_DISK_ERR issue. In your view what can be the resolve for this, i'll work on that.
Regards
sid2015-11-06 09:00 AM
I'm not looking to wade into this, but #2 doesn't strike me as a viable path, you need to deal with the error in the DISKIO abstraction. Most demonstrations here try once and then immediately give up. In a more robust implementation you attempt the retry/recovery in the sector read/write code, so if it's a soft error it recovers, and if it's a hard error you've done your best.
User space apps shouldn't need to be responsible for dealing with hardware/driver level issues, they can detect and react to errors, but at that point you need to tear-down the stuff that's not working and rebuild it. It's like an onion, the stuff that's failing needs to deal with the issues it can resolve, but it gets exponentially more invasive to fix things as you go up each layer.2016-09-18 07:58 AM
Hello,
I'm using the latest HAL version for the stm32f4 processor (v1.13) and I'm having the same problem,BOT_DATA_IN_WAIT and URB status always returning USBH_URB_IDLE.
Is there a known fix to this problem?2016-09-21 05:30 AM
Hi to everyone, I'm trying to do the same as you described but I get many issues mounting the file on the device....
Have you experienced these kind of problem?Could you share your code?Good luck for your work ;-)2016-09-21 06:15 PM
http://l.facebook.com/l.php?u=http://pastebin.com/8UYFXDdC&h=zAQGvP8my
2016-09-22 11:45 PM