OSDev.org

Hi,

Currently I am testing my EHCI driver.
I can read with the EHCI-driver from USB 2.0 pendrives (4GB and 16GB) and an external USB 2.0 500 GB winchester a 45MB-wav file and succesfully play it.
However I also have a USB 2.1 32GB pendrive and the EHCI-driver timeouts during the BULK transfer and copies to RAM only a few seconds of the wav-file.

I have checked the whole code and everything looks good.
I am also developing the XHCI-driver and I read about the Binary Device Object Store Descriptor (BOS-descriptor) in Lunt's USB book (chapter 22).
Perhaps the BOS-descriptor should also be retrieved from USB 2.1 drives and not only from USB 3.x?
But I don't see why that would help.
It seems that there is no USB2.1 specification.
The Device, Configuration, Interface and EndPoint descriptors are below.
EDIT: I use SCSI Read10 if the pendrive is smaller than 8GB, otherwise I use Read12.

Any help is appreciated.
Regards,
rob

Data of the 32GB USB2.1 pendrive (data in HEX):
Device Descriptor
12 01 10 02 00 00 00 40 4C 05 C2 09 10 01 01 02 03 01
So the version is 0x0210

Configuration Descriptor
09 02 20 00 01 01 00 80 96

Interface Descriptor:
09 04 00 00 02 08 06 50 00

EndPt1:
07 05 81 02 00 02 00

EndPt2:
07 05 02 02 00 02 00

The difference between these data and the data of my 4GB USB 2.0 pendrive is:
- USB version (0x0210 vs 0x0200)
- Release Version (0x0110 vs 0x0100)
- Product ID (this is not important)

- Max Power Consumption (0x96 vs 0x64)
- Interval (0x00 vs 0xFF)

Hi,

bigbob wrote:Currently I am testing my EHCI driver.
I can read with the EHCI-driver from USB 2.0 pendrives (4GB and 16GB) and an external USB 2.0 500 GB winchester a 45MB-wav file and succesfully play it.
However I also have a USB 2.1 32GB pendrive and the EHCI-driver timeouts during the BULK transfer and copies to RAM only a few seconds of the wav-file.

I have checked the whole code and everything looks good.
I am also developing the XHCI-driver and I read about the Binary Device Object Store Descriptor (BOS-descriptor) in Lunt's USB book (chapter 22).
Perhaps the BOS-descriptor should also be retrieved from USB 2.1 drives and not only from USB 3.x?
But I don't see why that would help.
It seems that there is no USB2.1 specification.
The Device, Configuration, Interface and EndPoint descriptors are below.
EDIT: I use SCSI Read10 if the pendrive is smaller than 8GB, otherwise I use Read12.

Devices showing 2.1 can now support the BOS descriptor. In the book you mentioned, also see Chapter 21. Also note that if the device supports the BOS descriptor is might not (USB 2.1+) or must not (USB 3.0+) support the Device Qualifier and Other Speed Config descriptors. However, as a USB 2.1 device, you can ignore the BOS descriptor, because most likely it only contains the CONTAINER_ID capability.

As for the 2.1 specification, see Randy Aull's description from http://online.osr.com/showthread.cfm?link=249588.

Being that your device has a 0x0210 (or possibly/rarely 0x0201), this just means that it supports the BOS descriptor and an extension to the USB 2.0 specs.

After the timeout, do you do a Request Sense command to see what the device returns? This may be helpful.

When you read the capacity of the thumb-drive, what is returned? Does Last LBA == 0xFFFFFFFF?

In all the research I have done, I understand that a 0x0210 device will function exactly as a 0x0200 device. Therefore, I believe the error might be in your code, not the device. However, I have been wrong before.

Ben
http://www.fysnet.net/the_universal_serial_bus.htm

BenLunt wrote: Devices showing 2.1 can now support the BOS descriptor. In the book you mentioned, also see Chapter 21. Also note that if the device supports the BOS descriptor is might not (USB 2.1+) or must not (USB 3.0+) support the Device Qualifier and Other Speed Config descriptors. However, as a USB 2.1 device, you can ignore the BOS descriptor, because most likely it only contains the CONTAINER_ID capability.
As for the 2.1 specification, see Randy Aull's description from http://online.osr.com/showthread.cfm?link=249588.
Being that your device has a 0x0210 (or possibly/rarely 0x0201), this just means that it supports the BOS descriptor and an extension to the USB 2.0 specs.

Thank you for the answer, Ben.

BenLunt wrote: After the timeout, do you do a Request Sense command to see what the device returns? This may be helpful.

No, I don't, but I will try it.

BenLunt wrote:When you read the capacity of the thumb-drive, what is returned? Does Last LBA == 0xFFFFFFFF?

Last LBA is 0x39EFFFF
Sectorsize is 0x200

BenLunt wrote:In all the research I have done, I understand that a 0x0210 device will function exactly as a 0x0200 device. Therefore, I believe the error might be in your code, not the device. However, I have been wrong before.

This is what I wanted to know. So I don't have to do anything special in case of USB2.1 devices.
I will keep looking at my code (even the FAT32-related one).

Regards,
rob

It is a bug in my Fat32-code.
Sorry for wasting your time.

bigbob wrote:It is a bug in my Fat32-code.
Sorry for wasting your time.

No waste.

Just out of curiosity, I and probably others here, like a small description of the bug fix you made.
Maybe someone is having a little trouble with their FAT32 code and your explanation will trigger a clue to theirs.

"I was not clearing the high order byte of the FAT entry variable I was using"

Or something like that.

Anyway, glad to help.
Ben

BenLunt wrote: Just out of curiosity, I and probably others here, like a small description of the bug fix you made.
Maybe someone is having a little trouble with their FAT32 code and your explanation will trigger a clue to theirs.

I haven't managed to fix it yet, but the problem has been found.
When I get the number of consecutive sectors from FAT (max. 65535, so that it can be read from the USB-drive in one step), I get greater LBA than the capacity of the disk in case of the USB2.1 32GB one.
My FAT32-code works well in case of the other three USB-drives of mine, so that's why I thought that the USB 2.1 drive was the guilty one.
It is high time to test the FAT32-code