[solved] USB MSD hangs on ping

[Klakap]

Good afternoon,
I am trying to get my MSD driver on EHCI controller to work.
1. MSD send descriptor so I can recognise that it is MSD and read endpoints
2. MSD send device qualifier
3. MSD send number of LUNs
Now I want to send Inquiry command. But, unfortunately, device still set PING bit in Transfer Descriptor when I do OUT bulk transfer. It happens on every three devices I tested. No matter how long I wait. Please what is causing this?

[BenLunt]

Good afternoon,
I am trying to get my MSD driver on EHCI controller to work.
1. MSD send descriptor so I can recognise that it is MSD and read endpoints
2. MSD send device qualifier
3. MSD send number of LUNs
Now I want to send Inquiry command. But, unfortunately, device still set PING bit in Transfer Descriptor when I do OUT bulk transfer. It happens on every three devices I tested. No matter how long I wait. Please what is causing this?

Hi,

How about a little more information?

1. Is it a full-, high-, or super-speed device? On an EHCI, it will enumerate as one of the first two, not the third.
2. Are you sure the "Get LUNs" request returned successfully. Most MSDs don't return success on this request. They may and usually STALL. Therefore, have you cleared the STALL by sending a SETUP transaction to the control pipe? Usually if it stalls, you need to "request the sense" as well.
3. If all is successful to this point, how many bytes are you requesting from the INQUIRY command? It is normal to request 36 bytes, and only 36 bytes as the first request. Once you successfully receive the first 36 bytes, you can then request any remaining (including the initial 36) bytes again, using the "Additional Length" field.

I am guessing that the "Request LUNs" request failed, and it is now expecting a "Request SENSE" request before you can do anything else.

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

[Klakap]

It is high speed device. LUN request did not fail, but even if I removed it, bulk transfer is still pinged.

How my bulk transfer look in memory:
QUEUE HEAD
0x00900002 ;pointer to itself
0x8040E201 ;address of device is 1, bulk out endpoint is 2
0x40000000 ;no split
0x00000000 ;current TD
0x00900100 ;pointer to TD

TRANSFER DESCRIPTOR
0x000000001
0x000000001
0x001F0C80 ;TD status, transfer 31 bytes - Command Block Wrapper
0x00900500 ;pointer to buffer
...

After transfer, TD status change to 0x80000C01. On other device this is 0x001F0049.

[Klakap]

I found error. I had wrongly set CBW. Somehow I missed three bytes so I was sending nonsense.

[Klakap]

My MSD driver now works perfectly in QEMU, but I can not get it to work on real hardware. My source code is available on https://github.com/Klaykap/BleskOS/blob ... b_ehci.asm and https://github.com/Klaykap/BleskOS/blob ... torage.asm . On real hardware every transfer with endpoint 0 is good, so I can set address of device, read device descriptor and device qualifier. Problem comes when I want to send first OUT packet - Command Block Wrapper for Inquiry command. On real hardware is this command PINGed(status of transfer descriptor is 0x01) and every other transfer, no matter if IN or OUT, stuck on active status(0x80). Please where can be the problem?

How my driver work:
1. EHCI controller is initalized by method init_ehci
2. Method ehci_detect_devices is scanning all EHCI ports
3. Method ehci_detect_device is dealing with one port. If is device founded, this method call ehci_set_address and ehci_device_read_descriptor.
4. ehci_device_read_descriptor found type of device. If it is MSD, it save controller base, port, out and in endpoint. After it is called ehci_msd_descriptor. To this point all work on both QEMU and real computer. Here is called method msd_init
5. msd_init tries to send Inquiry command, but it never happend on real computer because TD status is 0x01.

[Klakap]

So I clear one problem, I was not setting configuration number. But transfers are still PINGed.

[Klakap]

Everything work now. I found that PING byte should be send in every OUT tranfer . My problem was that I was not waiting enough time to read response from IN endpoint. Hope this can help someone in future with similar problem.