USB Raw SendSetupTransfer help


I posted this to the end of my first question thread but no one answered, so I thought I’d start it in a new thread. I need to use the USB Raw Device class in .NETMF but I’m unsure of what the procedure would be and what some of the data needs to be.

Some background on my project:
I have a LabView GUI that sends 4 commands to my board (which has the FT2232H chip) via USB. I’m trying to replicate that using the FEZ Cobra. I installed USBlyzer and watched the USB stream when I used the LabView GUI to send the commands. It saw 4 commands, 8 bytes each, separated by 8-byte buffers. I have no intention of reading from the FT2232H chip (that’s not my short-term goal, at least).

What I don’t understand:
I came across some example codes which I tried to decipher. In each of them, after using OpenPipe to open up a communication channel to the USB client, SendSetupTransfer was called before anything else was done. I read the USB setup packet but I still don’t know how to set it up (and I don’t know if I have to set it up). Would any of the bytes in the 4 commands I want to send to the FT2232H chip be sent through the SendSetupTransfer command or would it be through TransferData?

Can anyone tell me what I should write in the SendSetupTransfer arguments if I need to call it? For “bmRequestType”, bit 7 is probably 0 (host to device). Bits 6 and 5 are probably Class or Vendor, and bits 4-0 are most likely Endpoint. But I’m not certain. I also don’t know what the “bRequest” would be! Help?


FTDI uses EP0? Unlikely I think.

Not EP0 (if you mean Endpoint 0). The numbers I listed are the bits in byte 0 (bmRequestType) of the Setup Packet. The configuration of the bits in byte 0 is shown as follows:

D7 Data Phase Transfer Direction
0 = Host to Device
1 = Device to Host

D6…5 Type
0 = Standard
1 = Class
2 = Vendor
3 = Reserved

D4…0 Recipient
0 = Device
1 = Interface
2 = Endpoint
3 = Other

4…31 = Reserved

So when I said bits 4-0 are most likely Endpoint, I meant I had to set it up to show 0010, which equals “Endpoint”.

FYI, I know I have to talk to Endpoint x02.

Exactly my point :slight_smile: EP0 = control transfer. Which is not what you need.

To be more clear, you do not need send setup transfer as this uses EP0

Ok, after a bit more internet digging, I think I’m beginning to understand it better now.

Control transfers are always sent to endpoint 0. Setup Packets part of the control transfer and thus are sent to endpoint 0 as well. So there’s no way that I can send data that is meant to go on the bulk pipe if I use SendSetupTransfer.

The FT2232H chip I’m using only shows 2 pipes: in bulk and out bulk. Bulk is another type of transfer mechanism for USB (the four mechanisms are control, interrupt, isochronous, and bulk). So I really just want to talk to the bulk endpoint (which I’ve discovered to have bEndpointAddress of x02 and bmAttribute of x02). Apparently, when a host wants to send a bulk transfer, it has to issue and OUT token followed by the data packet. And that’s it. Seems simple enough. I just have to figure out which function in .NETMF USB Raw Device lets me do all of that.

However, back to the control transfer thing, I know that each device has to have a default pipe (endpoint 0) that can receive and send control packets. Obviously FTDI has it too, otherwise how was I able to get the configuration information of the device? The question now is do I need to use control transfer to set up the bulk endpoint that I want to later send data to (aka use SendSetupTransfer to configure bulk endpoint, then use some other transfer function to send the data packet to bulk endpoint)? My guess is no. Am I right?

While the Internet is full of info, I suggest USB complete by jan axelson.

By the way, you can hire GHI to build any driver if this helps.

Is there anyone else who’s willing to help and won’t treat me as if I’m incompetent or haven’t done enough research?

I think I’m asking straight-forward questions about how to use .NETMF, which runs on a GHI product. Am I doing something wrong here?

I was only trying to help, even beyond the scope of our free support. I am sorry if you feel differently.

The Xbox controller driver is a good example on raw USB.

After working on this for a while, I figured out the answer to my question.

Question: Do I need to use control transfer to set up the bulk endpoint that I want to later send data to?
Answer: For all USB devices, SendSetupTransfer needs to be called to set up the device. That line of code usually looks like this:

DeviceX.SendSetupTransfer(0x00, 0x09, config_descriptor.bConfigurationValue, 0x00);

First byte in the arguments specifies Host to Device(bit 7), Standard Request (bits 6-5), and Device recipient (bits 4-0).
Second byte in the arguments specifies the request which is Set Configuration.
Third byte specifies the value that corresponds with the request.
Last byte specifies the index/offset.

If your USB device is straight-forward, that’s all the setup you’ll probably ever need to do. But if you’re using the FT2232H in Synchronous FIFO mode like I am, then you need to do an extra setup.

A bit of background on the FT2232H FIFO mode:
FT2232H is a dual-port USB device which can be used in Serial or FIFO modes. In the FIFO mode, you can use it in Asynchronous or Synchronous settings. In Asynchronous setting, you get to use the two ports separately. In Synchronous setting, the chip effectively becomes a single port since it uses the resources in the second port to run in Synchronous mode. FT2232H is set to Async FIFO mode via the EEPROM. To get it into Synchronous FIFO mode, the USB Host has to give it a specific command.

The FT2232H’s supporting documents specify what that command is if you use their software or LabView, but not in raw USB. I sniffed the USB packets to find out what that command is in raw USB. The second setup packet you’ll need to send if you want to use the FT2232H in Synchronous FIFO mode is:

DeviceX.SendSetupTransfer(0x40, 0x0B, 0x4000, 0x0001);

First byte in the arguments specifies Host to Device(bit 7), Vendor Request (bits 6-5), and Device recipient (bits 4-0).
The second, third, and fourth bytes specify the vendor-specific request, value, and index/offset respectively.

You can double-check that it works by probing the CLKOUT pin on the FT2232H. If your setup was successful, you should see a 60MHz clock on it.

Sending data to the device once the setup is done is easy; just use the DeviceX_OutPipe.TransferData() function.

1 Like

Glad you have it figured out and thanks for sharing info. This maybe good to add to wiki if you like as well.