usb host fails to read/write data on usb drive due to error FR_DISK_ERR

89maninder · ‎2015-11-05

Posted on November 05, 2015 at 12:34

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_ERR

on 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_fs

Tesla DeLorean · ‎2015-11-05

Posted on November 05, 2015 at 19:32

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.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

89maninder · ‎2015-11-05

Posted on November 06, 2015 at 07:40

thanks clive1...

i went little further on debugging and found that:-

whenever read/write fails while reading/writing, program always comes to case BOT_DATA_IN_WAIT / BOT_DATA_OUT_WAIT / BOT_SEND_CBW_WAIT / BOT_RECEIVE_CSW_WAIT. all of these are cases where host is expecting some response(basically URB status) from USB drive like ACK NAK STALL. but URB status here is always USBH_URB_IDLE.
URB status is updated in host channel interrupts. then i found that whenever read/write fails, interrupt is not coming up at all... is it because data wasn't sent properly from host side?

Now, is it because i am not handling interrupts properly?
As you said,
''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?
is there any way for soft reset?? because once i take pendrive out and connect again, usb starts working again. but i dont want to do this manually, i can execute disconnect program for this. it can reset USB host and maybe then host start working again until error comes up again.
''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

sid

Tesla DeLorean · ‎2015-11-06

Posted on November 06, 2015 at 18:00

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.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

bruno239955 · ‎2016-09-18

Posted on September 18, 2016 at 16:58

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?

andrea6388 · ‎2016-09-21

Posted on September 21, 2016 at 14:30

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 ;)

guifernandes123 · ‎2016-09-21

Posted on September 22, 2016 at 03:15

http://l.facebook.com/l.php?u=http://pastebin.com/8UYFXDdC&h=zAQGvP8my

andrea6388 · ‎2016-09-22

Posted on September 23, 2016 at 08:45

Hello to everyone,

I finally managed to make the project work. The code I used is taken form stm32f4 example, pasted on a stmCube configuration for a L4 discovery board.

To have more details, read this link:

https://my.st.com/public/STe2ecommunities/mcu/Lists/STM32Discovery/Flat.aspx?RootFolder=https%3a%2f%2fmy%2est%2ecom%2fpublic%2fSTe2ecommunities%2fmcu%2fLists%2fSTM32Discovery%2fHost%20USB%20application%20on%20discovery%20L4&FolderCTID=0x01200200770978C69A1141439FE559EB459D75800084C20D8867EAD444A5987...