Kakapo External Programming

Prerequisites

The Kakapo is shipped with the RESET_EN jumper closed by a blob of solder. Before the external programming header on the board can be used, this blob needs to be removed, so the RESET_EN jumper is open.

Program Debug Interface overview

External programming of XMEGA chips is based on a serial protocol called PDI (Program Debug Interface), propriety to the XMEGA platform. PDI replaced the ICSP interface on previous AVR8 chips such as the MEGA line.

PDI has a dedicated pin for bi-direction data (“PDI_DATA”), and uses the !RESET line as a clock (“PDI_CLK”). These are presented on the same 6-pin (3×2) header as an ICSP connection, and maintain the same position for VCC and GND as ICSP.

pdi_header

PDI is not compatible with the ICSP interface – your external programmer needs to have explicit support for PDI programming. However, most AVR programmers are capable of supporting PDI.

Supported programmers include:

  • AVR ISP mkII (no adapter required)
  • AVR JTAGICE mkII (in PDI mode, 6-pin adapter)
  • AVR JTAGICE3 (in PDI mode, 6-pin adapter)
  • AVR Dragon (using ICSP header, firmware >= 3.08)

Other programmers (eg, clones) may be supported.

Software for program/debug

PDI is support for programming by AVRdude works at least version 5.11, but running the latest version is recommended as many XMEGA parts have improved support in later versions.

Note: some versions of avrdude do not understand XMEGA memory space names (ie, “application” vs “flash”). 6.01 is the minimum version to correctly recognise those names.

PDI support for debugging in avarice is less complete, a small number of parts are supported from version 2.12. The status of debugging with avarice is unclear, and appears to require a JTAGICE mkII or JTAGICE3 at a minimum.

Flash layout for XMEGA devices

XMEGA devices have dedicated areas of flash for different purposes. Unlike AVR MEGA chips, which use “flash” to refer to all flash space (except eeprom and signature rows), XMEGA chips have a number of partitions within “flash” to facilitate flashing only required areas.

XMEGA chips also do not require a full chip erase to apply new code, but can be erased on a page-by-page basis. avrdude takes care of this automatically, so you do not need to specify any special options to take advantage of this.

The following table explains the flash partitions avrdude should know about for the ATXMEGA64D4 chip the Kakapo uses:

flash application (64k)
apptable (4k)
boot (4k)
eeprom (2k)
signature (1 page)
prodsig (1 page)

“flash” covers the same range as it does on a MEGA chip – everything including the eeprom and bootloader space. “application” is where your application lives, unlike MEGA chips this does not include bootloader or eeprom space. The last 4kB of the application space is called the “apptable”, which could be used for reference tables and such like.

Separate to “application” are the “boot” and “eeprom” sections. “boot” is where the bootloader lives, and is fixed size. On a MEGA, “boot” is part of application flash, and is variable size. “eeprom” has the same use as other AVR8 chips.

Lastly, there are two special pages of flash: “signature” (user signature row) and “prodsig” (production signature row). These are protected portions of flash for data which is either written by the factory (production signature) or free for user usage (user signature). Unlike other parts of flash, they are not included in a chip erase, nor touched by the “flash” space.

Note that the capacity of the chip (64kB in the case of the Kakapo) is just the application section. The total flash capacity is actually 64kB (app) + 4kB (boot) + 2kB (eeprom) + sig rows. This means that unlike MEGA chips, you can completely fill the application with 64kB of code and still have a bootloader present.

Flashing a new application

A new application can be flashed to the Kakapo without disturbing the bootloader using the “application” space passed to avrdude:

# avrdude -p x64d4 -c avrisp2 -U application:w:yourapp.hex

The maximum size of an application that can be flashed this way without disturbing the bootloader is 64kB.

Replacing the bootloader

In a similar fashion, you can replace or upgrade the bootloader on the chip with the following commands. Note that the bootloader must have been compiled for the ATXMEGA64D4 and using this method requires the .hex to be located at zero, not the address of the boot section:

# avrdude -p x64d4 -c avrisp2 -U boot:w:bootloader-zero.hex

Alternatively, if you are flashing a new bootloader and are happy to erase the application already present, then compile bootloader located at the bootloader address (0×10000) and use the flash partition:

# avrdude -p x64d4 -c avrisp2 -U flash:w:bootloader-main.hex

In both cases, if the bootloader fuse bits have not been set, they will need to be. Check the bootloader documentation for what fuse bits need to be set.

Clock configuration

The AVR MEGA chip on an Arduino requires an external programmer to change clock configurations. XMEGA chips do not, so there is no requirement to use an external programmer to change clocking behaviour.

libkakapo includes functions to set up the clock according to the F_CPU definition at run-time. Clocking can be changed at any point during run-time as well.

Leave a Reply

Tech and Electronics