OSDev.org

Hi, Benjamin!
Sorry, i was busy at work, and had not time for OS development.
Yes, i can. Firstly, i want to say some interesting things to you: (that i've sent in e-mail a few minutes ago)

So, detailed debug info from VBox debugger(worst debugger in the world! It can be used just for printing some info about memory and devices):
Firstly, regs:

Ok, i think all are ok. Now, print out a async queue head:

How you can see, HEAD_OF_RECLAMATION bit is set, pointer has a Typ is 1 - pointer to queue, just move to next queue in list.

Here we can see, that queue horizontal link points to first queue. Also, we can see characteristics. (I made them equals to your, by rewriting a small part of my code).
Ok, also we can see, that there is qTD in 0x207000.

Now i've fixed code, and Typ, like in a specification doesn't points to queue(Typ is zero, see 3.5.1 of spec, because there aren't any Typs )
So, as you can see: there is Setup packet, and buffers are pointing to 0xfd18:

That request just gets first eight bytes of descriptor. So, let's move to next TD in chain, to 0x207100

That qTD contains pointer to next qTD, packet type is DATA_IN, and buffers are pointing to device descriptor.
Let's see last qTD in chain at 0x207200

So, QH token isn't updating, TD chain isn't processing, data never comes.

So, i have no idea to do with that.

Specially thanks,
Aleksandr

Hi. Me too.
I haven't yet received that email. Please try again.


Remember, the Status packet is not expected until after a successful transfer of the SETUP and DATA packets. i.e.: The Status packet tells the device that you successfully received the data. In my book, I show how to send the SETUP, DATA, and STATUS packet all at once, but indicated that it is assumed that no error was found. This is so you can get the idea of what takes place. It is up to you, the reader, to parse the data packets, as well as check for errors within any of them, all before you send the STATUS packet. If there was an error in any packet before the STATUS packet is to be sent, you probably should send a CLEAR STALL or reset the device. Only after all DATA packets are completely successful do you send the STATUS packet.

Also, just a quick thought. Make sure you are handling the Short Packet Detect procedure correctly. If there is a short packet detected and the controller still executes a DATA packet, this will cause a error (possible a stall). For example, if you expect 256 bytes of data, therefore having 32 8-byte DATA packets, yet you receive a short packet detect on the second packet, the controller and device will expect the STATUS packet next. If your schedule tries to execute the third DATA packet (let alone the remaining 253 packets), this will cause an error. Note that if you don't mark those remaining packets as inactive, on the next "roll around" to that frame, it could try to execute those again. It all depends on how you create your schedule. My book explains this in some detail.

Anyway, I too have been very busy and haven't been able to frequent this forum like a want to, let alone work on my own stuff. I hope to be able to soon, though.

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