Needed: Assistance With USB

[xSMD]

Hello. For the past several days, I have been trying to figure out how to configure USB devices. I have glanced over the USB 1.1 Specification, as well as the UHCI 1.1 document that can be downloaded from Intel's website. Still, I do not feel like I fully understand what I need to do and how I need to do it. My lack of success further demonstrates this.

My basic question is: How do you send a SET_ADDRESS request? How should the packets be sent? What packets should be sent?

I have tried multitudes of ways. I think I have the host controller properly reset and initialized. I have also reset and enabled both of the ports. (I provided timing delays between each of these steps.)

Yet, it seems that my attempts are timing-out. That is what the status field in the first TD is telling me.

Here are the three TDs that I have generally used. Also included is the SET_ADDRESS request that I am trying to send.

07 00 00 00 00 00 80 00 2D 00 00 00 00 00 00 00
07 00 00 00 00 00 80 00 E1 00 00 01 ?? ?? 00 00
00 00 00 00 01 00 05 00
07 00 00 00 00 00 80 00 69 00 08 00 ?? ?? 00 00

The second TD's question marks point to the 8-byte request. The third TD's question marks point to an unused part in memory.

I have tried with QHs. I have tried linking the TDs together in various ways. Yet the status field of the first TD continually gets set to 85h.

In other attempts, I have tried having the setup token's buffer (last doubleword) pointing to the 8-byte SET_ADDRESS request. Still, no luck.

Not fully understanding how to send a SET_ADDRESS request, I have no way of even knowing if I have everything else set up correctly.

So, could someone give me a basic walkthrough of how to sent this request? Once I understand this, I think I can figure everything else out on my own.

[madeofstaples]

My first guess is that you need to enable ONE device, send the SET_ADDRESS packet, and then enable the second device. When you enable a device it gets a default address of 0, enabling two devices at the same time could cause a conflict...

[xSMD]

Okay, I am now only enabling one of the ports. The other, I am explicitly disabling.

Still, no change. Are my TDs correct? Could someone show me what needs to be sent? As in, exactly?

For SET_ADDRESS, is it setup (2D), out (E1), then in (69)? Do they need to be queued or otherwise somehow linked?

[madeofstaples]

Sorry I'm not immediately familiar with the UHCI documentation, but the TDs should be linked to each other, yes, I'll have to review some material to make sure your TDs are indeed correct, though. If they are not, it's likely due to some confusion about big-endian/little-endian (IIRC, I had to pay attention to that when working on EHCI).

Let me know if you solve this so I don't spend time looking into it if I don't need to.

[xSMD]

Well, unless certain things need to be big endian, there should not be a problem with the byte order.

Also, the host controller is only supposed to modify the second doubleword, which I can see that it does. It seems to set all of the reserved bits, as well as the status bit indicating a CRC or time out error.

I have confirmed that my linking works. Both through QHs and through TDs.

I have also tried various spacings of the out and in tokens, as well as having them repeat in various ways until the end of the frame. That does not seem to have any effect.

Just in case I have erred when it comes to the registers, let me just review what I have generally been doing.

After enabling access to the host controller's I/O addresses through its PCI registers, I first load the Command Register (1820h) with 0006h to disable everything. I then cause a delay.

Next, I clear the Command Register. At least to be safe, I currently have my code causing another delay following that.

To reset and disable the two ports, I write 020Fh to one register (1832h) and 120Bh to the other (1830h). I then cause another delay.

Next, I enable the port with the register at 1832h by writing 000Fh to it. Again, I cause a delay.

Lastly, I allow the host controller to run by writing 0001h to the Command Register. I then wait a little over second before reading the values of the second doubleword of the TDs.

Of course, following my reset of the host controller, I write to the three registers relating to the frame. Though, since I am seeing changes to my TDs by the host controller, it seems that the problem must be elsewhere.

Maybe my TDs, maybe my resetting of the ports or my re-enabling of one of them, maybe how I am issuing the TDs? I do not know.

Can anyone who has had success with configuring USB devices help clarify where I am erring?

Oh, and this desktop computer has two ports. I have a device plugged into each to ensure that I get a desirable result should my code work.

So, though it appears to me like there are not any devices, there are. One for each port. The problem is not something as stupid as that.

And Windows XP detects both devices. Heck, when I reboot so that my code can run off the floppy, I see the mouse's LEDs come on just before BIOS transfers control to my code.

[Dex]

I will be shot for this, but here goes, get the code http://code.google.com/p/tatos/
Its well commented, with the stages you need to go though.

[TomT]

Who will shoot you Dex ?
Not me.
I was just going to suggest the same and go to the folder /usb and look at the calling sequence in the file "initusbmass.s"
Even if you dont understand assembly the comments may be helpful.

Scan the ports, reset the port, then GetDeviceDescriptor, GetConfigDescriptor...

TomT

[jal]

Who will shoot you Dex?

At various times in the past, Dex was scolded for posting source code and/or linking to source code by certain people that will remain unnamed, because they have the opinion that posting sourcode is a bad way of explaining things. In this case, I don't think anyone will resort to violence though, as the OP is clearly not some newbie with a general "how to start" question, but someone who already did all their homework and having a very specific problem.


JAL

[neato]

OP: What language are you writing in? How are you linking your TDs? Are you waiting for INT or Status? How have you configured the QH? Have you detected the drive connection yet? Are you testing on real hardware? Code?

[xSMD]

Okay, so I am still without USB success. However, I have been trying to narrow down the problem.

I have a request for someone who has USB working: Could you tell me what the value read from one of your enabled ports is when a device is attached to it?

For such a port, I receive a value of 0x0095. So the code does seem to be enabling the port. And a device is being shown as present. Still, the TDs are timing out as though a device is not present. Maybe my 8-byte request is ordered wrong?

(I am especially interested in the values of bits 5:4. The rest appear correct. Though I am not sure about them. Maybe they are indicating a potential problem?)

Neato, I have linked my TDs in numerous ways. Almost too many ways to mention. Probably just about every way possible...

With each TD being linked to directly from the frame list, with the first TD being linked from the frame list and the others linked by the previous TD (like a chain of TDs), with the frame list linking to a QH which links to the first TD (again creating a chain of TDs), with the frame list linking to a QH which links to the first TD and the next QH, et cetera, et cetera, et cetera...

Regardless of how I link the TDs, if they are linked, the host controller seems to attempt to access them. Though, it always marks them as having received a time-out error.

Yes, I am testing on real hardware. I have two functional devices plugged into my two USB ports. All of my code resides within a boot sector on a floppy disk.

[neato]

Are you certain that you aren't receiving false positives? Are you making sure that the code represents the correct device and port? Aren't you using linked lists, that's probably the only way you should link the TDs imo. Assuming you're writing in C. You just check b1 & b2, b1 first, then b2, that means connected, when b1 goes zero, that means disconnected.

[TomT]

xSMD,

I take it you are programming the UHCI.

This is your first TD:
07 00 00 00 00 00 80 00 2D 00 00 00 00 00 00 00

The first dword is a Link Pointer to the next TD. You have 0x00000007. I normally use 0x00000001 which indicates:
bit0 set = terminate
bit1 clear = TD

The 4th dword is the BufferPointer. This would be the address of say your DeviceDescriptor or SetAddress request. Do I see 0x00000000 as your buffer pointer ? Do you really have your request block stored at absolute address 0 ?

You can ask the controller to just process a single TD to keep it simple for starters. No need to chain a bunch together until you get one working.

Also the first transaction is usually the GetDeviceDescriptor request. This can be done using endpoint=0 and address=0 so you dont need SetAddress until later on.

TomT
http://code.google.com/p/tatos/

[neato]

TomT:

I'm having the same problem. I am trying to do what you suggested, make one TD and have it processed, and I am not getting anything from the return.

Here is how I set it up:

00. GRESET
01. Clear CMD reg
02. malloc 4096*2 for frame list and align to 4KB
03. write that address to frame_addr reg (this is the only time I do this)
04. enable IOC
05. start controller

Next: I detect the drive connection bit and do the following:

00. malloc space for TD and QH and align to 16B
01. Config TD and QH.

Code: Select all

char setup[8];
setup[0] = 0x80;
setup[1] = 0x06;
setup[2] = 0;
setup[3] = 1;
setup[4] = setup[5] = 0;
setup[6] = 0x8;		 
setup[7] = 0;

TD link pointer = 0x00000001, status = C_ERR | STATUS, info = LEN(8) | 0 | 2Dh, buffer = &setup
QH h = 0x00000001, v = &td

Once I set QH.V to the TD address, I was under the impression that it would trigger the device to begin the transaction, so I wait one second (not waiting for Interrupt) and the setup buffer is returned to me unchanged.

Does this look right? Am I setting the transaction up properly? Once I set the frame address during the configuration process (before I make any transactions), will that be the only time I need to do that, as long as the allocated space remains available? Should I be waiting for the Interrupt, or should I be waiting for the TD.stats to change? I think the OP and I are about in the same boat on this one. If you could answer my questions, I am sure it will serve us both. Thanks

[Dex]

Remember alignment is very important.

[neato]

Yeah, there we go. I got response. Thanks Dex!