Protocol decoder:avr_pdi

From sigrok
Revision as of 20:59, 20 November 2016 by Gsi (talk | contribs) (create the AVR PDI protocol decoder page)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search
avr_pdi
File:Pdi-6pin-header.png
Name AVR PDI
Description Atmel Program and Debug Interface
Status supported (patch available)
License GPLv2+
Source code decoders/avr_pdi
Input logic
Output avr_pdi
Probes reset, data
Optional probes
Options

The avr_pdi protocol decoder can decode Atmel's proprietary Program and Debug Interface protocol which is used to program (write and read internal flash and other types of memory) and debug (control execution of software) Atmel ATxmega MCUs.

The protocol decoder implementation is not yet part of the sigrok project, but instead is available as an externally provided patch.

Hardware

The PDI protocol involves two mandatory signals: The RESET pin is used as PDI_CLK, another dedicated pin is named PDI_DATA. Typical clock rate is in the range of few hundred kHz to several MHz.

Protocol

The physical layer is UART like but clocked. The clock is provided by the programmer. Data gets sampled at the rising clock edge (both TX and RX). Communication is bidirectional and half-duplex, the device only sends response data upon the programmer's request.

A frame consists of a start bit, eight data bits (LSB first), an even parity bit, and a number of stop bits.

The UART layer communicates byte values. The first byte contains an instruction opcode, and optionally size/length specs for its operands. The set of operands depends on the respective opcode. Subsequent bytes carry the instruction's operands, and/or memory content which gets written or retrieved by running a sequence of intrinsic PDI operations.

By accessing the device's internal memory space, and the register set of internal peripherals (especially the NVM controller), the programmer can identify the target, and read and write several kinds of memory in the device (flash, eeprom, fuses, signatures).

Access to memory is publicly documented, the protocol for debugging might not be (I'd be glad to be wrong on this).

Resources