OSDev.org

The Place to Start for Operating System Developers
It is currently Sun Oct 20, 2019 2:10 pm

All times are UTC - 6 hours




Post new topic Reply to topic  [ 10 posts ] 
Author Message
 Post subject: UHCI IN Transfert Descriptor fail
PostPosted: Sun Oct 06, 2019 12:46 pm 
Offline

Joined: Mon Mar 14, 2016 5:34 am
Posts: 7
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


Top
 Profile  
 
 Post subject: Re: UHCI IN Transfert Descriptor fail
PostPosted: Mon Oct 07, 2019 7:48 pm 
Offline
Member
Member
User avatar

Joined: Sat Nov 22, 2014 6:33 pm
Posts: 565
Location: USA
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


Top
 Profile  
 
 Post subject: Re: UHCI IN Transfert Descriptor fail
PostPosted: Tue Oct 08, 2019 11:37 am 
Offline

Joined: Mon Mar 14, 2016 5:34 am
Posts: 7
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


Top
 Profile  
 
 Post subject: Re: UHCI IN Transfert Descriptor fail
PostPosted: Wed Oct 09, 2019 7:43 am 
Offline
Member
Member
User avatar

Joined: Sat Nov 22, 2014 6:33 pm
Posts: 565
Location: USA
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


Top
 Profile  
 
 Post subject: Re: UHCI IN Transfert Descriptor fail
PostPosted: Wed Oct 09, 2019 10:12 am 
Offline

Joined: Mon Mar 14, 2016 5:34 am
Posts: 7
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


Top
 Profile  
 
 Post subject: Re: UHCI IN Transfert Descriptor fail
PostPosted: Wed Oct 09, 2019 12:15 pm 
Offline
Member
Member

Joined: Sun Nov 23, 2008 5:56 am
Posts: 25
Location: Russia, Saint-Petersburg
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.


Top
 Profile  
 
 Post subject: Re: UHCI IN Transfert Descriptor fail
PostPosted: Wed Oct 09, 2019 2:23 pm 
Offline

Joined: Mon Mar 14, 2016 5:34 am
Posts: 7
thanks for the link

this sentence help me to understand that the fact that i cant separate the different td in diferent frame
Quote:
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)


Top
 Profile  
 
 Post subject: Re: UHCI IN Transfert Descriptor fail
PostPosted: Wed Oct 09, 2019 7:47 pm 
Offline
Member
Member
User avatar

Joined: Sat Nov 22, 2014 6:33 pm
Posts: 565
Location: USA
nlg wrote:
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


Top
 Profile  
 
 Post subject: Re: UHCI IN Transfert Descriptor fail
PostPosted: Sun Oct 13, 2019 1:05 pm 
Offline

Joined: Mon Mar 14, 2016 5:34 am
Posts: 7
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?


Top
 Profile  
 
 Post subject: Re: UHCI IN Transfert Descriptor fail
PostPosted: Sun Oct 13, 2019 5:30 pm 
Offline
Member
Member
User avatar

Joined: Sat Nov 22, 2014 6:33 pm
Posts: 565
Location: USA
nlg wrote:
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


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 10 posts ] 

All times are UTC - 6 hours


Who is online

Users browsing this forum: Google [Bot] and 8 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group