sys64738
/
DragonProbe
1
0
Fork 0
Code Issues 1 Pull Requests 1 Releases Wiki Activity

Add 'MehFET USB protocol'

Triss 2021-10-08 10:00:01 +00:00
parent 529d30dab3
commit cd4e828b99
1 changed files with 36 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

36
MehFET-USB-protocol.md Normal file

@ -0,0 +1,36 @@
MehFET is a USB-based protocol meant for debugging MSP430 MCUs. It has been created because all existing ones either operated at a high level (eg. commands to insert breakpoints, which would require a lot of reimplementing existing code), or at a low level (bit-banging GPIO lines, which would be very slow over USB). Instead, the basic commands MehFET operates with, are reads and writes to the IR and DR registers. This is mostly the same abstraction level as used in CMSIS-DAP.
### USB descriptors
A USB device should be treated as a MehFET-capable device if one of its vendor interfaces has a "MehFET" substring in its iInterface string, and has '4' and '3' as subclass and protocol, respectively. It should have one bulk in endpoint, and one bulk out endpoint. No requirements on e.g. USB device VID and PID exist.
### Command and response format
The main protocol consists of command-response transfers initiated by the USB host. A command consists of a command byte, up to four length bytes, and an optional payload (with a number of bytes specified in the length) used as argument data. A response starts with a status byte, followed by up to four length bytes, and optional response data.
More specifically, the lowest seven bits of a command byte indicate the command number, while the highest bit indicates the presence of length bytes and a payload. The length bytes are encoded using a "variable-length quantity" (VLQ) manner: of the first length byte, the lowest seven bits are data bits. If the highest bit is one, another lenght byte follows, with the same format. Seven-bit length data units are sent from lowest-significance to highest-significance. The length has a maximum length of four bytes, so the most-significant bit of the fourth length byte is treated as a data bit, and the next byte is a payload byte.
#### Examples
```
> 04
< 00
```
The host sends a single command, `4`. As the highest bit of the command byte is low, no length and payload follow.
```
> 83 01 01
< FF 02 6E 6F
```
The host sends command `3`, and as the highest bit is now high, the next byte indicates the length: `1`. As the highest bit of the second byte is low, the third byte is the start of the payload, and not an extra length byte. The payload data consists of one byte (as indicated by the length), and has the value `0x01`.
Similarly, the response status is `0x7F`, and has two response bytes: `0x6E 0x6F`.
```
> 88 80 04 FB 01 00 00 FF AA AA AA AA AA ...
< FE 00
```
Here the host sends command `8`, with length `0x200`, and data bytes `0xFB 0x01 0x00 0x00 0xFF 0xAA 0xAA ...`. Note that the device sends a response with a length byte, but the length is zero so no response data follows.