5.2 Framing

This section outlines the general frame format used by all sub-protocols.

The protocol handler ID field identifies which sub-protocol to decode the packet by, and then which command handler to forward the packet to.

In general, ID == 0x00 is used as a “query” function in order for the host to “discover” the feature set of the tool.

Table 5-1. Command Frame Format
FieldSizeValue
SOF1 byte0x0E
Protocol version1 byte0x00 in this version (all packets)
Sequence ID2 bytesIncrementing from 0x00 (least significant byte sent first)
Protocol handler ID1 byteDestination sub-protocol handler ID
PayloadN bytesData
Table 5-2. Response Frame Format
FieldSizeValue
SOF1 byte0x0E
Sequence ID2 bytesEcho of incoming ID (least significant byte sent first)
Protocol handler ID1 byteSource sub-protocol handler ID
PayloadN bytesData
Table 5-3. Event Frame Format
FieldSizeValue
SOF1 byte0x0E
Protocol version1 byte0x00 in this version (all packets)
Sequence ID2 bytesIncrementing from 0x00 (least significant byte sent first)
Protocol handler ID1 byteSource sub-protocol handler ID
PayloadN bytesData

The protocol handler ID field identifies which sub-protocol to decode the packet by, and then which command handler to forward the packet to.

In general, ID == 0x00 is used as a “query” function in order for the host to “discover” the feature set of the tool.

If there is a condition where the EDBG AVR command handler expects more data for a command than is available, then the next incoming command will be rejected and an error response (RSP_FAILED with failure code FAILURE_USB_PREVIOUS_UNDERRUN) will be returned . Note that such an underrun situation will result in unknown values for the parameters of the failing command and the host will have to do the necessary cleanup to undo any undesired behavior. The underrun error reporting is done by transport layer and is independent of the sub-protocol being used.

Note: Unless otherwise stated, all multi-byte fields in this section are sent with least significant byte first.