UHCI IN Transfert Descriptor fail

[nlg]

I'm trying to program a UHCI, I managed for the moment to send the change of address command and it works
I try to send a request to read the main descriptor, the function is sent without problems but impossible to send a function IN the transfer descriptor is marked STALL as soon as I activate it

when I make an IN of 8 byte on the endpoint 0 I have 18800000h on the "TD control and status dword" and 00E00069h on the "TD token" and the controller immediately passes the "TD control and status dword" has the value 184007FFh

and I do not understand what's wrong, I fill the td pretty much in the same way the td for a SETUP (except the PID course) and it works

edit: the setup data i send just before is 80h,06h,01h,00h,00h,00h,14h,00h

[BenLunt]

Hi,

There are many reasons why it might not work. At first glance, it looks like you are requesting 20 bytes (14h) via this descriptor. Is it a low-speed device? If so, you must request that in three data descriptors, 8 bytes each for the first two, and 4 for the last.

A lot of devices follow a set sequence after reset. Unfortunately, when a popular OS started supporting USB, device manufacturers started testing with this OS, and if it works on that OS, it works just fine, rather than following the USB specs 100%. For example, this popular OS does a reset, gets the first 8 bytes of an 18 byte descriptor, then does another reset. Some devices will stall if they don't see this sequence, 1 in 250 maybe, but still, especially older devices.

Anyway, start requesting 8 bytes at a time, instead of more and see what happens.

1) reset device
2) get first 8 bytes of device descriptor
3) reset device
4) send address command
5) get all bytes of device descriptor

That is the most common procedure after startup/hot plug.

Hope this helps,
Ben
- http://www.fysnet.net/osdesign_book_series.htm

[nlg]

it's an error, i try to read 18 by but i make an error when i copy it in this post
and i read the 18 byte in 3 phase 2 of 8 bytes and 1 of 2 bytes

I realized that the transfer setup type did not work on some device, maybe my initialization sequence of contoller or reset the device is not good and some device agree to receive a setup sequence by mistake

[BenLunt]

Just out of curiosity, you are sending the STATUS packet as well, correct?

SETUP (8 bytes)
IN (8 bytes)
IN (8 bytes)
IN (2 bytes)
STATUS (0/8 bytes)

Ben

[nlg]

no, in the uhci datasheet the only PID i can use is SETUP, IN or OUT. i dont see any information and example about STATUS packet

and in fact it's:
SETUP 8 (data toggle =0)
wait for TD inactive
IN 8 (data toggle =1)
wait for TD inactive
IN 8 (data toggle =0)
wait for TD inactive
IN 2 (data toggle =1)
wait for TD inactive

every time i use the same TD and buffer, I proceeded like that because I thought that the different packages did not need to be in the same frame but if I can (or if I have to) use the STATUS packet, I should use several descriptors chained but for now I am working on the initialization procedure because I have doubts about my way of proceeding

[quirck]

UHCI specifies how to talk to the controller. The protocol is given in USB spec. See https://wiki.osdev.org/Universal_Serial ... ransfers_2 for reference.

[nlg]

thanks for the link

this sentence help me to understand that the fact that i cant separate the different td in diferent frame

If a packet is an atom, then a transaction would be a molecule. That is, a transaction is made up of several packets in a specific order, and the packets which make up a transaction cannot be reordered or separated and still yield the same transaction

because English isnt my native langage i sometime misunderstood thing (especially when im tired)

[BenLunt]

no, in the uhci datasheet the only PID i can use is SETUP, IN or OUT. i dont see any information and example about STATUS packet

and in fact it's:
SETUP 8 (data toggle =0)
wait for TD inactive
IN 8 (data toggle =1)
wait for TD inactive
IN 8 (data toggle =0)
wait for TD inactive
IN 2 (data toggle =1)
wait for TD inactive

every time i use the same TD and buffer, I proceeded like that because I thought that the different packages did not need to be in the same frame but if I can (or if I have to) use the STATUS packet, I should use several descriptors chained but for now I am working on the initialization procedure because I have doubts about my way of proceeding

You have to send a status packet after each transfer. For example, an IN transfer as above requires a single OUT packet with zero bytes transferred as a status packet. An OUT transfer requires a single IN packet with zero bytes transferred as a status packet.

SETUP 8 (data toggle =0)
wait for TD inactive
IN 8 (data toggle =1)
wait for TD inactive
IN 8 (data toggle =0)
wait for TD inactive
IN 2 (data toggle =1)
wait for TD inactive
OUT 0 (data toggle =1) (toggle is always 1 on the status packet)
wait for TD inactive

The OUT, in this case, tells the device that you received all 18 bytes and it is okay for the device to move to the ready status for the next command.

In the case of an OUT transfer, the IN status packet is used to let the device tell you that it received all bytes and you can now send another command.

SETUP 8 (data toggle =0)
wait for TD inactive
OUT 8 (data toggle =1)
wait for TD inactive
OUT 8 (data toggle =0)
wait for TD inactive
OUT 8 (data toggle =1)
wait for TD inactive
IN 0 (data toggle =1) (toggle is always 1 on the status packet)
wait for TD inactive

Without the OUT 0 packet above, the device is still waiting for the status. This is why you are receiving a STALL.

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

[nlg]

I prepare a function to put all the necessary packages in the scheduler, if i have to do a SETUP without data, do i have to do an IN or OUT after to get the result?

[BenLunt]

I prepare a function to put all the necessary packages in the scheduler, if i have to do a SETUP without data, do i have to do an IN or OUT after to get the result?

Most successful Control transfers, even zero byte transfers, need a STATUS packet. Mind you, that is Control IN and Control OUT transfers. These transfers have a SETUP packet, zero or more data packets, and the STATUS packet. Even if no data is transferred, the SETUP packet indicates whether it is an IN or and OUT, which tells you what STATUS packet direction is used. If the Setup packet, or any of the data packets are not successful, the STATUS packet is not sent/received.

The Clear Stall packet is different, but it is sent to Bulk pipes. On Control pipes, any SETUP packet is a Clear Stall indicator. Bulk transfers do not have STATUS packets. They don't have SETUP packets either, for that matter.

A few other notes/things to remember: Remember the Short Packet Detect bit on IN transfers. Remember that a Clear Stall will clear the toggle bit on Bulk transfers.

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