I have an application with an MCF52255 is tied to a USB Flash drive and an MP3 CODEC. It opens an MP3 file on the drive, reads a small chunk of data, streams it to the CODEC via SPI, and repeats. This continues until the file read command returns 0 bytes read, at which time it stops playback. This all works fine under the majority of cases, but for some unknown reason it occasionally fails. This has happened when reading different files of varying length, and the time at which it happens in the file also varies (a few MB to over 50 MB). I can tell when it's happening because I get back a 0 byte read even though the file pointer has not reached the end of file (I check the file size before starting to play).
If I determine this condition exists (which has been reliable) I then try to recover. I would certainly prefer to know why it fails in the first place (and prevent it), but at a minimum to start with I need to be able to recover from this condition. I have first tried to simply close the file and reopen which didn't help. For some reason when it gets in this state I can do the fopen and fclose, and also fseek (to find the the file size), but a read always returns 0 bytes.
I then tried to reset the USB task, but I'm evidently doing something wrong because I end up with new tasks each time I try this. The code I'm using is based closely on an example project (I don't remember exactly which now, but probably 'hvac' for the Tower 52259 board). The 'USB_Task' has the highest priority in the application, and it spawns another 'KHCI task'. When I try to do a _task_restart on the USB task, the KHCI task doesn't get aborted so a new one starts when the USB task restarts. (I'm going to try having it abort that task as well.) Regardless, after this happens when I try to reopen the file and start reading from it again, I start seeing "USBMSF retrying read sector" messages which I don't normally get. It does still seek, but when I try to read I still get 0 bytes.
I've seen some rare random anomalies in the USB MSF behavior on other projects, but I suppose now that the volume of USB activity on this project is so much higher I'm seeing it much more often, and it's potentially a showstopper. Is this a bug in the stack, or something I'm doing wrong? I see there are a number of bugs fixed for MQX 4.0 - can I expect this problem to go away if I attempt to port the code to 4.0?
Thanks for any insight or suggestions.