topic Re: MQX 3.6 MCF52255 - Problems with USB MFS file read in MQX Software Solutions

MQX 3.6 MCF52255 - Problems with USB MFS file read

ARQuattr — Tue, 26 Mar 2013 02:01:03 GMT

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.

Angelo

Re: MQX 3.6 MCF52255 - Problems with USB MFS file read

DavidS — Tue, 26 Mar 2013 13:24:20 GMT

Hi Angelo,

i would strongly recommend moving to MQX4.0. There has been much change, inprovements, enhancements with the RTOS components (especially MFS and USB) since MQX3.6.

Regards,

David

Re: MQX 3.6 MCF52255 - Problems with USB MFS file read

foo86 — Tue, 11 Nov 2014 09:38:54 GMT

Hello Angelo

Did the moving to MQX 4.0 really solved your problem? I have got a similar problem.

Best Regards,

Martin

Re: MQX 3.6 MCF52255 - Problems with USB MFS file read

ARQuattr — Tue, 11 Nov 2014 12:21:56 GMT

Hi Martin, as it turns out, I finally just got to upgrading the project to MQX 4.0 recently. I haven't done enough testing to say there is an improvement, although I did see some of the same behavior. I'll have to do some better testing to say for sure, but I have a new problem in that I'm not able to reach the same maximum data rates that I did with 3.6, so I need to determine the reason for that first. If I can't resolve the speed issue, I'll have to roll back to 3.6 anyway. In 3.6 I was able to simultaneously read and stream files to the CODEC that are encoded at over 320kbps. The same code running in 4.0 can't handle that speed and the audio is distorted.

I thought it might have something to do with what I believe is a bug in MQX (which I reported here: How to adjust a timer interval?), but I'm not sure if that problem is strictly on the Kinetis device or the Coldfire also. I changed various short 5ms delays to 1 tick to be sure, but it didn't help. Maybe this issue isn't causing my problem, but I'll need to put a scope on the signals next to see what's happening.