STM32F107 OTG Mass Storage ultra slow

This forum is dedicated to feedback, discussions about ongoing or future developments, ideas and suggestions regarding the ChibiOS projects are welcome.
dsigma
Posts: 13
Joined: Sat Jan 26, 2013 12:18 am

Re: STM32F107 OTG Mass Storage ultra slow

Postby dsigma » Wed Oct 30, 2013 1:34 am

Hmmm, a few thoughts....

In regards to the USB errors, I suspect the same thing that Geovani suspects. There is likely something in either the MSD or CDC driver that is not responding at all to the host request type, or that is stalling instead of failing on the request. I would suspect the MSD driver over the CDC driver, specifically because I've seen the CDC driver work many times under windows as a CDC-only driver. (Unless the CDC driver when used in the context of a composite device is the issue). The next step would be to look at the MSD code and see what commands/requests are being sent, if or where they are being handled. I can take a look at this...unless your really board and want to dig into it... :)

In regards to the debug output logging. The output for those demo projects is going to one of the serial ports on the STM, so you'd want to hook up a serial to USB converter and open minicom (in linux) or putty (in windows) to view the output. There is probably a way to feed that serial data stream into eclipse, but I've never investigated it. But by default, I would not expect it to show up in eclipse.

In regards to FS vs HS, in this case, it really wouldn't make an observable difference in speed between the two. The speed differences really show up when doing large volumes of bulk data transfers.

In regards to booting off the device, I'm not sure if, or how well, you will be able to boot off a USB composite device. The whole "composite" thing seems to be challenging even for OS's, let alone BIOS's. The spec has been around for maybe a decade? but it's only the past 3-5 years that the mainstream OS's have really supported it.

It sounds like the USB device descriptor was setup wrong, or the way the callbacks were configured was not consistent with how the descriptor was defined. USB device descriptor packing is kind of a pain, and the various endpoint definitions in the descriptor have to match up with how the USB endpoints are configured in the code. If you just changed the descriptor, and nothing else, or changed it in an incorrect manor, I would be skeptical that it would work at all... There are various relationships between different structures and fields in the descriptor, and you have to get them all right in combination with each other. http://www.usb.org/developers/docs/ has all the details, of which there are a few thousand pages, because USB is way to complicated IMHO... :o

dsigma
Posts: 13
Joined: Sat Jan 26, 2013 12:18 am

Re: STM32F107 OTG Mass Storage ultra slow

Postby dsigma » Tue Nov 12, 2013 1:35 am

Hi, Just wanted to provide a quick update. I spent some time last week looking at this and found that the service thread was waiting for an interrupt right after the "Inquiry" step of the MSD init process. I'm not sure the exact cause of this. It may be timing related, or a combination of timing and an incorrect set of expectations regarding interrupts. I'm not sure yet. Anyways, I'm hoping to get back to it soon, but time has been limited. Hopefully in the next couple weeks... I'll keep the thread updated...

dsigma
Posts: 13
Joined: Sat Jan 26, 2013 12:18 am

Re: STM32F107 OTG Mass Storage ultra slow

Postby dsigma » Wed Nov 27, 2013 1:09 am

I finally got around to digging into the details of this. To summarize:

Fixed:
* There was an un-supported command (SCSI_CMD_READ_FORMAT_CAPACITY) that was being sent by Windows 7 (but not XP or Mac OS or Linux) that was putting the firmware into a state where it would indefinitely wait for an ISR.
* The return error code handling for the CSW was not behaving as it should. This code was re-factored to be more correct.
* Added handling for the SCSI_CMD_PREVENT_ALLOW_MEDIUM_REMOVAL command.

Remaining Issue(s):
* I'm not *entirely* sure that the error handling behavior is correct in all cases. I tested a variety of cases, purposefully inducing errors in certain cases, and it seems to recover just fine, and the usb protocol analyzer output seems reasonable for those cases.
* The read performance is still much slower then I'd like. It's between 2ms and 10ms per read operation by the host (SD card ops are faster), which causes it to take a long to read the FAT, and so with an 8gig SD card it can take 10 or so seconds to show up in windows. Comparing 2ms-1ms range, to a hardware SD card reader, this code (or possibly due to my hardware) is roughly an order of magnitude slower.


I've done testing on Linux, Win7 and WinXP and it now shows up and it appears to be doing what I'd expect.

Please let me know if you run into any further issues...

Thanks!
-d

dsigma
Posts: 13
Joined: Sat Jan 26, 2013 12:18 am

Re: STM32F107 OTG Mass Storage ultra slow

Postby dsigma » Mon Dec 02, 2013 11:16 pm

Quick update: I tracked down the read performance issue to something that was specific to one of the SD cards that I was testing. Swapping SD cards resolved the issue. I also did some re-factoring to the error handling behaviors. I'm now getting about 2.0 megs/second read and write performance to a Transcend 8gig SD card, and it appears to work quickly in windows and Linux. I did a little testing on mac, and it does enumerate and show up on the host quickly.

Please let me know how things go...

Best Regards,
-D

User avatar
kimmoli
Posts: 23
Joined: Sat Oct 01, 2016 8:02 pm
Has thanked: 9 times
Been thanked: 8 times
Contact:

Re: STM32F107 OTG Mass Storage ultra slow

Postby kimmoli » Wed Oct 11, 2017 10:27 pm

Gravedigging old thread, but the slow windows mounting seems to be caused by missing response in SCSI library.
See https://github.com/ChibiOS/ChibiOS-Contrib/pull/129


Return to “Development and Feedback”

Who is online

Users browsing this forum: No registered users and 1 guest