I am implementing USB as a host to read the contents of a FAT32 file system. The Endpoint descriptor returns me 0x81 as IN endpoint address and 0x02 for OUT EP.
I am implementing this using the OHCI. The Endpoint Descriptor in OHCI has a 4bit field for the Endpoint as shown by the 'EN' field-
So does this mean my endpoint address are 0x02 for OUT and 0x01 for IN? these are there endpoint numbers for sure.
I ask this because my Transfer Descriptor for accepeting data from the IN endpoint is failing and I am not able to figure out the reason yet.
As mentioned by Chris, it depends on the context and using 0x01 works !
Related
Looking for software that's like hidusbf changes bInterval value for endpoint descriptor of HID device any alternatives or how to do this yourself?
We are developing an example where device continuously stream data through an isochronous IN endpoint. Now my question was as interrupt and isochronous have lot of similarities :
Max 1024 packets in USB HS
both are for bandwidth guarantee.
Host polls device every micro frame.
can I use my host interrupt endpoint to configure is to read from device's isochronous endpoints ?
device isochronous endpoints is following :
===>Endpoint Descriptor<===
bLength: 0x07
bDescriptorType: 0x05
bEndpointAddress: 0x81 -> Direction: IN - EndpointID: 1
bmAttributes: 0x05 -> Isochronous Transfer Type, Synchronization Type = Asynchronous, Usage Type = Data Endpoint
wMaxPacketSize: 0x0180 = 1 transactions per microframe, 0x180 max bytes
bInterval: 0x01
I understand there is NACK/ACK token in the interrupt endpoints , but let say if device ignores this NACK/ACK token can I still communicate with device using my interrupt endpoints ?
On reading about usb protocol in
http://www.beyondlogic.org/usbnutshell/usb4.shtml
It is said that interrupt endpoint is unidirectional and periodic.
Yet, I see in the description for IN interrupt endpoint, that host initiate the IN token and then data packet is send from device to host.
"If an interrupt has been queued by the device, the function will send
a data packet containing data relevant to the interrupt when it
receives the IN Token."
So, If the data packet is sent on this IN endpoint from device to host, doesn't it mean that the same endpoint is used both the transmit and receive ?
I believe the terminology "unidirectional" is meant for only data and not for token and handshake packets. So "IN" endpoint is for reading data and "OUT" endpoint is for writing data. That's why its called unidirectional.
But control endpoint is bidirectional because you can read or write data using the control endpoint. Check the standard USB commands like "Get Descriptor" and "Set Descriptor".
I'm trying to reverse-engineer a BLE device that uses USB HID over GATT to communicate with the host. I can capture the traffic using usbpcap, but when loading the results into wireshark, the packets seem to contain the bytes representing the data that is going over the air (i.e. device descriptor), but the packets are not decoded according to USBHID protocol. Everything is decoded as USB, and only contain URB_INTERRUPT_IN, URB_BULK in/out and URB_CONTROL_OUT, while I'm looking for things like GET DESCRIPTOR Request/Response DEVICE. Is there an extra step I can take to get the packets formatted and parsed correctly?
There are a few characteristics in use. You have one characteristic which contains the Report Map. This is usually only read once when the device is paired. This map contains the layout/specification of the data which is later sent through the Report notifications. This is mostly "copy-paste" the specification from the USB spec into BLE.
Now, when you run HID-over-GATT and your Bluetooth controller talks to the Host over USB, what you will see in usbpcap is the ACL data which contains L2CAP data, which contains GATT data, which in turn contains the Report data for HID. Then the Bluetooth stack on the host will decode this and feed it into the kernel's HID parser.
I would suggest you to instead connect your HID-over-GATT device to an Android phone and then take a look at the HCI snoop log what happens, which is decodable in Wireshark (but it won't parse your HID data).
I'm implementing USB on a PIC 18F2550 using a generic HID interface. I've set up the HID profile configuation to have a single 64 byte message for both inputs and outputs.
Now it's basically working. The device registers OK with windows. I can find it in my program on the PC and can send and receive data to it. The problem is this though - messages from the PC to the PIC are truncated to the size of the EP0 endpoint buffer.
Before I go debugging too much further I want to try to clarify my understanding of the USB protocols here and check I got it right.
Assume that the EP0 input buffer is 8 bytes. It's my understanding that the PC end will send a control packet which is 8 bytes. In there is the length in bytes of the data to follow. And then it will send a sequence of 8 byte data packets and the PIC end has to acknowledge each one.
It's my understanding that the PC end knows how big each packet may be by looking in the maximum packet size field in the device descriptor and will divide up the message accordingly into multiple data packets.
Before I go looking for more hours at the code, can anyone confirm that this is basically correct? That if the EP0 buffer size is 8 bytes then the PC should know this because of the configuration field I mentioned above and send multiple data packets?
If I make my receive buffer on the PIC 64 bytes then I get 64 bytes of the message which is sufficient for my needs, but I don't like not understanding why it doesn't work with small buffers, and one day I'll probably need them anyway.
Any advice or information would be welcome.
There is something called Endpoint Descriptor, which, among other things, defines the wMaxPacketSize - which is what the Host Controller Interface drivers use to subdivide a large USB transfer into smaller packets.
This is entirely different from the EP0 buffer size - which however, is always required to be larger than the wMaxPacketSize. My guess is (try posting your usb_config.h and usb_descriptors.c, if you use Microchip USB stack), that you're either trying to use 8-byte long EP0 with 64-byte long wMaxPacketSize, which is truncating the transfer.
Also, be aware that in USB 1.1 Low Speed, the wMaxPacketSize cannot exceed 8, and in USB 1.1 Full Speed it cannot exceed 64.
0x07,/*sizeof(USB_EP_DSC)*/
USB_DESCRIPTOR_ENDPOINT, //Endpoint Descriptor
HID_EP | _EP_IN, //EndpointAddress
_INTERRUPT, //Attributes
DESC_CONFIG_WORD(9), //size
0x01, //Interval
/* Endpoint Descriptor */
0x07,/*sizeof(USB_EP_DSC)*/
USB_DESCRIPTOR_ENDPOINT, //Endpoint Descriptor
HID_EP | _EP_OUT, //EndpointAddress
_INTERRUPT, //Attributes
DESC_CONFIG_WORD(9), //size
0x01 //Interval