I have a USB protocol analyzer and am examining some data transferred between a host and a HID device. In the case below, a "Get Device Descriptor" request. I understand the setup packet configuration as spec'd by the USB standard. However, I am having trouble understanding how the data I see when I "expand" the setup packet relates to the standard setup packet. Can anyone clarify what is meant by this "additional" setup packet? The manual for the analyzer doesn't mention it, nor the significance of the DATA0 packet (since the actual data from the device is the IN txn packet). Googling just keeps showing me the standard setup packet config, as seen here, which I understand:
A control transfer like Get Device Descriptor consists of three stages (or transactions).
The first stage is the setup stage or setup transaction, consisting of three packets:
setup packet
data packet
acknowledge packet
Each of the packets contains a header and trailer with PID, CRC etc. The relevant transaction payload is contained within the data packet.
Your protocol analyzer software (Data Center from TotalPhase) uses a hierarchical display. If you expand all the nodes, some data is displayed multiple times.
In particular, the payload of the transaction is displayed twice, once at the parent node SETUP txn and once embedded in the data packet DATA0 packet.
Data packet: C3 80 06 00 01 00 00 12 00 E0 F4
Payload: 80 06 00 01 00 00 12 00
So there isn't really any additional data.
Unless you want to debug some low-level packet decoding, it probably does not make sense to dive into the nodes below the txn nodes. It will just repeat some data and additionally show the header and trailer bytes.
Related
when transmit data from esp32 to an esp32,does the BLE's libary contain errorchecking? AKA resending packets? uses Ack-Naks? error correction also?
Thanks
There is error checking.
You can check if a write was successful.
A Ble packet consist of:
Preamble: RF synchronization sequence.
Access address: 32 bits, advertising or data access addresses (it is
used to identify the communication).
Header: its content depends on the packet type (advertising or data
packet).
Length: Length of the data payload(When encryption is used, the
message integrity code (MIC) at the end of the packet is 4 bytes, so
this leads to 251 bytes as actual maximum available payload size.
Checksum: CRC.
There is no error correction or resending of packets, unless you implement it yourself.
So,if a write was not successful you can resend a packet.
I'm currently studying how USB works. I read, that there are transactions, which are build from smaller pieces - packets. I read about all kinds of packets.
I can't understand one thing. As the book says - every transaction consists of 3 packets: token, data and hanshake.
The way I understand my book is depicted in the schema below.
In my opinion:
I think the first transaction should contain only token IN and data packet, but no hanshake packet (handshake for what?).
I think, that response should only contain ACK hanshake packet (that the data is written properly to the device).
Please, help me understand it in a proper way.
Best regards,
Tom.
A transaction is a series of one or more packets.
A typical IN transaction with no data looks like this:
The host sends an IN token.
The device sends a NAK handshake packet, which means it doesn't have any data to send.
A typical IN transaction with data looks like this:
The host sends an IN token.
The device sends a DATA0 or DATA1 packet with data.
The host sends an ACK handshake.
A typical OUT transaction looks like this:
The host sends an OUT token.
The host sends a DATA0 or DATA1 packet with data.
The device sends a NAK or ACK handshake depending on whether it accepted the data.
Note that I am just talking about full-speed (12 Mbps) USB 2.0 devices, and things can get a bit more complicated for the higher-speed devices.
Note that any of these packets could be lost due to noise issues. The USB specification specifically accounts for this, ensuring that packet loss doesn't result in incorrect operation of the device or host.
I am using a SAM4E-EK board, and the processor is SAM4E. The board is equiped with a ADS7843 touch controller, contected from the processor through a SPI channel.
The chapter of SPI in datasheet of SAM4E said that
While the data in the Shift Register is shifted on the MOSI line, the MISO line is sampled and shifted in the Shift Register. Receiving data cannot occur without transmitting data.
But in an example for ADS7843 from ASF, it just sends data(8 bits) three times at first, and then it can receives data(8 bits) three times! I have test it, and it work fine.
So I think there is a hardware FIFO buffer in SPI receiver. But I can not find any related information in the datasheet and internet.
Am I right? or is there others mechanism making the example runs correctly?
The SAM4E manual says that SPI Receive Data Register has the size of 2 bytes
The ADS7843 manual says:
One complete conversion can be accomplished with three serial
communications, for a total of 24 clock cycles on the DCLK input
The figure 5 shows that byte0 is a request to ADS7843 and bytes1-2 are response.
You should send 1 byte of command and 2 dump bytes to provide SPI clocking while the ADS7843 is responsing (the manual says
Receiving data cannot occur without transmitting data
And when you reading 3 bytes, you get the 2 bytes of answer, stored in the SPI Receiver register
I have been trying for 4 days now to send the hex code 10 80 00 00 00 00 00 00 to a USB device connected to my raspberry pi running debian.
I've tried libusb with c but I have no idea what I am doing. I thought PyUSB would be a better solution but ive found zero documentation for what I need and the tutorial did'nt help.
I can find the device using
import usb.core
dev = usb.core.find(idVendor=0x12BF, idProduct=0xFF03)
But I cant find any information on how to send the above hex code. My device is a usb based relay. It works fine on windows in a vb HID application but I am struggling here. seem to be going round in circles.
Could you please tell us, how is the USB communication with the device? Is it a bulk transfer?
(see this link for more details:
http://www.beyondlogic.org/usbnutshell/usb1.shtml )
For instance, if you are using a bulk communication via an Endpoint you could try something like this (as seen here http://pyusb.sourceforge.net/docs/1.0/tutorial.html):
endpoint.write(endpointnumber, data, interfacenumber)
If you want to send a hex value, let's say 0xFF via the endpoint 2, interface 0, try something like:
endpoint.write(2, '\xFF', 0)
I hope this helps...
I am writing code for a USB device. Suppose the USB host starts a control read transfer to read some data from the device, and the amount of data requested (wLength in the Setup Packet) is a multiple of the Endpoint 0 max packet size. Then after the host has received all the data (in the form of several IN transactions with maximum-sized data packets), will it initiate another IN transaction to see if there is more data even though there can't be more?
Here's an example sequence of events that I am wondering about:
USB enumeration process: max packet size on endpoint 0 is reported to be 64.
SETUP-DATA-ACK transaction starts a control read transfer, wLength = 128.
IN-DATA-ACK transaction delivers first 64 bytes of data to host.
IN-DATA-ACK transaction delivers last 64 bytes of data to host.
IN-DATA-ACK with zero-length DATA packet? Does this transaction ever happen?
OUT-DATA-ACK transaction completes Status Phase of the transfer; transfer is over.
I tested this on my computer (Windows Vista, if it matters) and the answer was no: the host was smart enough to know that no more data can be received from the device, even though all the packets sent by the device were full (maximum size allowed on Endpoint 0). I'm wondering if there are any hosts that are not smart enough, and will try to perform another IN transaction and expect to receive a zero-length data packet.
I think I read the relevant parts of the USB 2.0 and USB 3.0 specifications from usb.org but I did not find this issue addressed. I would appreciate it if someone can point me to the right section in either of those documents.
I know that a zero-length packet can be necessary if the device chooses to send less data than the host requested in wLength.
I know that I could make my code flexible enough to handle either case, but I'm hoping I don't have to.
Thanks to anyone who can answer this question!
Read carefully USB specification:
The Data stage of a control transfer from an endpoint to the host is complete when the endpoint does one of
the following:
Has transferred exactly the amount of data specified during the Setup stage
Transfers a packet with a payload size less than wMaxPacketSize or transfers a zero-length packet
So, in your case, when wLength == transfer size, answer is NO, you don't need ZLP.
In case wLength > transfer size, and (transfer size % ep0 size) == 0 answer is YES, you need ZLP.
In general, USB uses a less-than-max-length packet to demarcate an end-of-transfer. So in the case of a transfer which is an integer multiple of max-packet-length, a ZLP is used for demarcation.
You see this in bulk pipes a lot. For example, if you have a 4096 byte transfer, that will be broken down into an integer number of max-length packets plus one zero-length-packet. If the SW driver has a big enough receive buffer set up, higher-level SW receives the entire transfer at once, when the ZLP occurs.
Control transfers are a special case because they have the wLength field, so ZLP isn't strictly necessary.
But I'd strongly suggest SW be flexible to both, as you may see variations with different USB host silicon or low-level HCD drivers.
I would like to expand on MBR's answer. The USB specification 2.0, in section 5.5.3, says:
The Data stage of a control transfer from an endpoint to the host is
complete when the endpoint does one of the following:
Has transferred exactly the amount of data specified during the Setup stage
Transfers a packet with a payload size less than wMaxPacketSize or transfers a zero-length packet
When a Data stage is complete, the Host Controller advances to the
Status stage instead of continuing on with another data transaction.
If the Host Controller does not advance to the Status stage when the
Data stage is complete, the endpoint halts the pipe as was outlined in
Section 5.3.2. If a larger-than-expected data payload is received from
the endpoint, the IRP for the control transfer will be
aborted/retired.
I added emphasis to one of the sentences in that quote because it seems to specifically say what the device should do: it should "halt" the pipe if the host tries to continue the data phase after it was done, and it is done if all the requested data has been transmitted (i.e. the number of bytes transferred is greater than or equal to wLength). I think halting refers to sending a STALL packet.
In other words, the device does not need a zero-length packet in this situation and in fact the USB specification says it should not provide one.
You don't have to. (*)
The whole point of wLength is to tell the host the maximum number of bytes it should attempt to read (but it might read less !)
(*) I have seen devices that crash when IN/OUT requests were made at incorrect time during control transfers (when debugging our host solution). So any host doing what you are worried about, would of killed those devices and is hopefully not in the market.