USB HOST for MSD on MCF51JM128 - Problems while reading sectors with some pendrives

[SAEL]

Hi, my target is a a simple USB HOST application: plug in a MSD and manage it by a set of commands received from SCI or SPI bus. 

My project is MCF51JM128 based, I'm using CW MCU 10.1 Compiler, and developing it on a DEMOJM board.

I started from "Freescale USB Stack with PHDC v3.0" and "Freescale USB FATFS v1.0", specifically from the demo project "msd_mfs_generic": this simple demo project execute a complete test (drive info, read/write directory, read/write files, ecc.) of the pendrive plugged in, and print all results on SCI bus.

I have the following problem:almost 50% of the pendrive doesn't work fine, the test always fail with the message "NO FILE SYSTEM". This is caused from a failed reading of the sectors.After plug in, demo test execute check_fs(...) to read information from MBR (sector 0) and initialize fat table structures. But with some pendrives there was problems while low level reading sector (function disk_read(), the buffer out it's never written and the software scan a wrong buffer).

Anyone experienced with this problem? or any hint to debug? I try almost all but it doesn't work yet...

[TomE]

Many pen drives are "broken" in that they don't obey the printed USB specifications. But they interoperate with Windows and since that's 95+% of the market. Meaning the keys seem to have been developed based on what Windows DOES rather than the specification. For instance there's meant to be a specific time for USB devices to "wake up" after being plugged in. For a Windows machine it doesn't matter - it'll wait as long as necessary for the stick. In our case we have a time we wait for the key to come up before giving up. From the comments in the file:

 * USB Timing Specifications.
 * The USB Power Up Spec (dt2) is the maximum time from USB power up until
 * a device must drive one of the pins to signal its presence. This is a maximum
 * of 100ms. Our small black-and-red xxxxxxxx takes over 150ms.
 * A 4G "xxxxxxxxxxxxxxx" we have that HSV had trouble with takes 330ms
 * and an 8G xxxx xxxxx xxxxxx" takes 360ms! NOTE this is a requirement
 * of the DEVICE and is not something that the hub has to handle. It can look
 * for a connection immediately (or even before) power on.

So following the spec we only need to wait 100ms. To work with the above common sticks we have to wait for over 360ms, and there may be ones out there that take even longer.

This won't be your problem - just a pointer to how these things don't obey the most basic requirements - so they'll get other things wrong too.

I'll find some more references on Monday to other problems with initialising USB keys and post it.

Tom

[SAEL]

Thanks for reply.

I'dont guess that wake up time is my problem, cause I've already tried to increase it up to 1000 mS but it doesn't work.

However I will do some other testing in this way, waiting for your next post.

[TomE]

I said the wakeup time wouldn't be your problem, but is an example of one of the things that lots of sticks get wrong.

it only matters in our code as we power the USB port on, wait for *a short time* for any stick to show up, and then power off. Code written to the specification wouldn't find lots of slow-to-start sticks. Of course this spec isn't tested in a Windows box so...

Here's what I said I had in email at work. Follow the link:

http://forums.freescale.com/t5/68K-ColdFire-reg-Microprocessors/USB-connection-stuck-in-usb-host-sta...

Extract from the above:

====================

My experience has been that when you get "stuck" waiting for TOK_DNE, you're not actually stuck at all, but in an infinite (hardware) retry loop where the device is returning infinite NAKs.  If you turn of hardware retries (RETRY_DIS = 1) then you might be able to see the NAKs (you'll get a TOK_DNE for each) to confirm it...  Or if you put on a USB analyzer, that's even easier yet!

What I found was that many keys depend on a very specific (certainly against the spirit of the SBC standard) order of commands during initialization, including magic sequences of Inquiry, Test Unit Ready, Request Sense, and Read Capacity.  Apparently they all expect the order that Windows happens to send, and if you do a different order, things get confused.

We eventually got every key we had (about 20-30, including card readers and multi-LUN devices, not to mention a half dozen MST-capable cameras) working with our initialization sequence, which is below if it helps. The API is for our custom USB host/device driver (source available in skeleton.zip at http://www.cpustick.com/downloads.htm), but I believe the command sequence should be obvious from it if you want to try and mimic it.  (I definitely found keys CMX could not talk to for this reason, when attempting to isolate the bugs and going back and forth between drivers.)

====================

Tom

[SAEL]

Ok, I will investigate on command order during initialization, trying to found critical differences with my initialization procedure.

Howewer, I would underline this point: 
all of posts you linked talk about projects based on CMX libraries. 

I already have my application based on CMX LITE libraries: it work fine, and the problem mentioned in this post doesn't appear. But cause of limits of CMX LITE, now I'm triyng to migrate this application to a project based on new libraries mentioned above.

I agree with you that most of pendrives on market doesn't fit USB specification at all, but why CMX LITE Stack works fine, and "Freescale USB Stack with PHDC v3.0" does not?

Main difference between Stacks seems to be that CMX LITE doesn't use USB interrupt, while the other one does. But it may be significant?

[TomE]

> why CMX LITE Stack works fine, and "Freescale USB Stack with PHDC v3.0" does not?

Because the CMX stack is better?

These are "demo stacks" after all. If you want one that works you buy one like we did.

Tom

[JimDon]

Tom,

Freescale certain does not call it a demo stack.

USB Stack with PHDC Support

It sure sounds like it supposed to be production ready.

If you really have a problem with it PLEASE submit a tech support issue and see if it can be resolved.

Quite often tech support has fixes that are not yet released, or will find a fix.

They will be quite responsive.

[TomE]

---

JimDon wrote:

Tom,

Freescale certain does not call it a demo stack.

USB Stack with PHDC Support

It sure sounds like it supposed to be production ready.

If you really have a problem with it PLEASE submit a tech support issue and see if it can be resolved.

Quite often tech support has fixes that are not yet released, or will find a fix.

They will be quite responsive.

---

Yes, from the above link:

Freescale’s USB stack (No OS) supports personal healthcare device class (PHDC),

human interface device (HID), mass storage device (MSD), ... etc. etc.

... speeds up general purpose and medical product development.

But from SAEL's latest post:

> However I would point out that Freescale Support reply to my request saying

> this is a known issue that will be fixed in future.

Could you respond on that Request asking that they publish an Errata Document for this stack with the know issues? Had that been available it could have saved you a lot of time. It might help others too. You could also ask if there are any OTHER known issues on their list.

Tom

[TomE]

> It sure sounds like it supposed to be production ready.

I stand corrected. I assumed it was a simple demo and in this case it isn't.

> If you really have a problem with it PLEASE submit a tech support issue and see if it can be resolved.

Submit a report and offer to post them a collection of your sticks that don't work with the stack.

Here's another thing to try. REFORMAT the sticks. Importantly, reformat them on WINDOWS and not on anything else (meaning Linux). Linux has had a bug in the FAT format utility for just about forever that writes an "unexpected" value into the FAT header, and some FAT stacks don't handle this variation.

Tom

[SAEL]

@ Rich T

Could I follow your tips on "magic order" also if my project manage interrupt transfers?

@ JimDon

I really have a problem with PHDC USB Stack. Where can I submit a tech support issue? "Create service request" on support page, is this the right link?

@ TomE

I tried several times to reformat my sticks on Windows, but nothing.

[RichTestardi]

---

SAEL wrote:

@ Rich T

Could I follow your tips on "magic order" also if my project manage interrupt transfers?

---

Sure, I run the stack both ways -- by default it runs with interrupts.

The important thing  is that the USB drive see the requests in the order shown in block.c -- if you send requests in a different order, some USB drives will go out to lunch and not come back.

-- Rich

[SAEL]

@ Rich T

Thank you I will try to reply the order you advised.

However I would point out that Freescale Support reply to my request saying this is a known issue that will be fixed in future.

So if someone will need a USB HOST Stack for MSD to start develope his own application, please don't use "PHDC USB stack v3.0" because it doesn't work.

[JimDon]

Yes, that is how you submit a service request. It might take a bit of your time, but the will get back to you and discuss the problem. You may have to further explain the problem, but once you have submitted the service request, you can just send emails.

[SAEL]

---

TomE wrote:

If you want one that works you buy one like we did.

---

That sounds good!

So demo projects are made to lose time, and forums are made to get this useful tips?

good to know.

[RichTestardi]

Sorry, so as to not mislead you with the previous like, the magic initialization order required by many USB flash drives is no longer in that skeleton project -- I keep meaning to put it back. :smileysad:

I've (hopefully) attached the file with the magic order -- see PhysReadWriteSector().

-- Rich

[DesignFeats]

FYI, Attached post has a working CMX MSD Host stack https://community.freescale.com/message/78726#78726