2.2 Programmers accepting extended parameters

JTAG ICE mkII/3

Atmel-ICE

PICkit 4

MPLAB SNAP

Power Debugger

AVR Dragon

When using the JTAG ICE mkII, JTAGICE3, Atmel-ICE, PICkit 4, MPLAB SNAP, Power Debugger or AVR Dragon in JTAG mode, the following extended parameter is accepted:

‘jtagchain=UB,UA,BB,BA’

Setup the JTAG scan chain for UB units before, UA units after, BB bits before, and BA bits after the target AVR, respectively. Each AVR unit within the chain shifts by 4 bits. Other JTAG units might require a different bit shift count.

The PICkit 4 and the Power Debugger also supports high-voltage UPDI programming. This is used to enable a UPDI pin that has previously been set to RESET or GPIO mode. High-voltage UPDI can be utilized by using an extended parameter:

‘hvupdi’

Enable high-voltage UPDI initialization for targets that supports this.

AVR910

The AVR910 programmer type accepts the following extended parameter:

‘devcode=VALUE’

Override the device code selection by using VALUE as the device code. The programmer is not queried for the list of supported device codes, and the specified VALUE is not verified but used directly within the T command sent to the programmer. VALUE can be specified using the conventional number notation of the C programming language.

‘no_blockmode’

Disables the default checking for block transfer capability. Use ‘no_blockmode’ only if your ‘AVR910’ programmer creates errors during initial sequence.

Arduino

The Arduino programmer type accepts the following extended parameter:

‘attemps=VALUE’

Overide the default number of connection retry attempt by using VALUE.

Urclock

The urclock programmer type accepts the following extended parameters:

‘showall’

Show all info for the connected part, then exit. The -xshow... options below can be used to assemble a bespoke response consisting of a subset (or only one item) of all available relevant information about the connected part and bootloader.

‘showid’

Show a unique Urclock ID stored in either flash or EEPROM of the MCU, then exit.

‘id=<E|F>.<addr>.<len>’

Historically, the Urclock ID was a six-byte unique little-endian number stored in Urclock boards at EEPROM address 257. The location of this number can be set by the -xid=<E|F>.<addr>.<len> extended parameter. E stands for EEPROM and F stands for flash. A negative address addr counts from the end of EEPROM and flash, respectively. The length len of the Urclock ID can be between 1 and 8 bytes.

‘showdate’

Show the last-modified date of the input file for the flash application, then exit. If the input file was stdin, the date will be that of the programming. Date and filename are part of the metadata that the urclock programmer stores by default in high flash just under the bootloader; see also -xnometadata.

‘showfilename’

Show the input filename (or title) of the last flash writing session, then exit.

‘title=<string>’

When set, <string> will be used in lieu of the input filename. The maximum string length for the title/filename field is 254 bytes including terminating nul.

‘showapp’

Show the size of the programmed application, then exit.

‘showstore’

Show the size of the unused flash between the application and metadata, then exit.

‘showmeta’

Show the size of the metadata just below the bootloader, then exit.

‘showboot’

Show the size of the bootloader, then exit.

‘showversion’

Show bootloader version and capabilities, then exit.

‘showvector’

Show the vector number and name of the interrupt table vector used by the bootloader for starting the application, then exit. For hardware-supported bootloaders this will be vector 0 (Reset), and for vector bootloaders this will be any other vector number of the interrupt vector table or the slot just behind the vector table with the name VBL_ADDITIONAL_VECTOR.

‘showpart’

Show the part for which the bootloader was compiled, then exit.

‘bootsize=<size>’

Manual override for bootloader size. Urboot bootloaders put the number of used bootloader pages into a table at the top of the bootloader section, ie, typically top of flash, so the urclock programmer can look up the bootloader size itself. In backward-compatibility mode, when programming via other bootloaders, this option can be used to tell the programmer the size, and therefore the location, of the bootloader.

‘vectornum=<arg>’

Manual override for vector number. Urboot bootloaders put the vector number used by a vector bootloader into a table at the top of flash, so this option is normally not needed for urboot bootloaders. However, it is useful in backward-compatibility mode (or when the urboot bootloader does not offer flash read). Specifying a vector number in these circumstances implies a vector bootloader whilst the default assumption would be a hardware-supported bootloader.

‘eepromrw’

Manual override for asserting EEPROM read/write capability. Not normally needed for urboot bootloaders, but useful for in backward-compatibility mode if the bootloader offers EEPROM read/write.

‘emulate_ce’

If an urboot bootloader does not offer a chip erase command it will tell the urclock programmer so during handshake. In this case the urclock programmer emulates a chip erase, if warranted by user command line options, by filling the remainder of unused flash below the bootloader with 0xff. If this option is specified, the urclock programmer will assume that the bootloader cannot erase the chip itself. The option is useful for backwards-compatible bootloaders that do not implement chip erase.

‘restore’

Upload unchanged flash input files and trim below the bootloader if needed. This is most useful when one has a backup of the full flash and wants to play that back onto the device. No metadata are written in this case and no vector patching happens either if it is a vector bootloader. However, for vector bootloaders, even under the option -xrestore an input file will not be uploaded for which the reset vector does not point to the vector bootloader. This is to avoid writing an input file to the device that would render the vector bootloader not functional as it would not be reached after reset.

‘initstore’

On writing to flash fill the store space between the flash application and the metadata section with 0xff.

‘nofilename’

On writing to flash do not store the application input filename (nor a title).

‘nodate’

On writing to flash do not store the application input filename (nor a title) and no date either.

‘nometadata’

On writing to flash do not store any metadata. The full flash below the bootloader is available for the application. In particular, no data store frame is programmed.

‘delay=<n>’

Add a <n> ms delay after reset. This can be useful if a board takes a particularly long time to exit from external reset. <n> can be negative, in which case the default 120 ms delay after issuing reset will be shortened accordingly.

‘strict’

Urclock has a faster, but slightly different strategy than -c arduino to synchronise with the bootloader; some stk500v1 bootloaders cannot cope with this, and they need the -xstrict option.

‘help’

Show this help menu and exit

BusPirate

The BusPirate programmer type accepts the following extended parameters:

‘reset=cs,aux,aux2’

The default setup assumes the BusPirate’s CS output pin connected to the RESET pin on AVR side. It is however possible to have multiple AVRs connected to the same BP with SDI, SDO and SCK lines common for all of them. In such a case one AVR should have its RESET connected to BusPirate’s CS pin, second AVR’s RESET connected to BusPirate’s AUX pin and if your BusPirate has an AUX2 pin (only available on BusPirate version v1a with firmware 3.0 or newer) use that to activate RESET on the third AVR.

It may be a good idea to decouple the BusPirate and the AVR’s SPI buses from each other using a 3-state bus buffer. For example 74HC125 or 74HC244 are some good candidates with the latches driven by the appropriate reset pin (cs, aux or aux2). Otherwise the SPI traffic in one active circuit may interfere with programming the AVR in the other design.

‘spifreq=0..7’

0	30 kHz (default)
1	125 kHz
2	250 kHz
3	1 MHz
4	2 MHz
5	2.6 MHz
6	4 MHz
7	8 MHz

‘rawfreq=0..3’

Sets the SPI speed and uses the Bus Pirate’s binary “raw-wire” mode instead of the default binary SPI mode:

0	5 kHz
1	50 kHz
2	100 kHz (Firmware v4.2+ only)
3	400 kHz (v4.2+)

The only advantage of the “raw-wire” mode is that different SPI frequencies are available. Paged writing is not implemented in this mode.

‘ascii’

Attempt to use ASCII mode even when the firmware supports BinMode (binary mode). BinMode is supported in firmware 2.7 and newer, older FW’s either don’t have BinMode or their BinMode is buggy. ASCII mode is slower and makes the above ‘reset=’, ‘spifreq=’ and ‘rawfreq=’ parameters unavailable. Be aware that ASCII mode is not guaranteed to work with newer firmware versions, and is retained only to maintain compatibility with older firmware versions.

‘nopagedwrite’

Firmware versions 5.10 and newer support a binary mode SPI command that enables whole pages to be written to AVR flash memory at once, resulting in a significant write speed increase. If use of this mode is not desirable for some reason, this option disables it.

‘nopagedread’

Newer firmware versions support in binary mode SPI command some AVR Extended Commands. Using the “Bulk Memory Read from Flash” results in a significant read speed increase. If use of this mode is not desirable for some reason, this option disables it.

‘cpufreq=125..4000’

This sets the AUX pin to output a frequency of n kHz. Connecting the AUX pin to the XTAL1 pin of your MCU, you can provide it a clock, for example when it needs an external clock because of wrong fuses settings. Make sure the CPU frequency is at least four times the SPI frequency.

‘serial_recv_timeout=1...’

This sets the serial receive timeout to the given value. The timeout happens every time avrdude waits for the BusPirate prompt. Especially in ascii mode this happens very often, so setting a smaller value can speed up programming a lot. The default value is 100ms. Using 10ms might work in most cases.

Micronucleus bootloader

When using the Micronucleus programmer type, the following optional extended parameter is accepted:

‘wait=timeout’

If the device is not connected, wait for the device to be plugged in. The optional timeout specifies the connection time-out in seconds. If no time-out is specified, AVRDUDE will wait indefinitely until the device is plugged in.

Teensy bootloader

When using the Teensy programmer type, the following optional extended parameter is accepted:

‘wait=timeout’

If the device is not connected, wait for the device to be plugged in. The optional timeout specifies the connection time-out in seconds. If no time-out is specified, AVRDUDE will wait indefinitely until the device is plugged in.

Wiring

When using the Wiring programmer type, the following optional extended parameter is accepted:

‘snooze=0..32767’

After performing the port open phase, AVRDUDE will wait/snooze for snooze milliseconds before continuing to the protocol sync phase. No toggling of DTR/RTS is performed if snooze > 0.

PICkit2

Connection to the PICkit2 programmer:

(AVR)	(PICkit2)
RST	VPP/MCLR (1)
VDD	VDD Target (2) -- possibly optional if AVR self powered
GND	GND (3)
SDI	PGD (4)
SCLK	PDC (5)
OSI	AUX (6)

Extended command line parameters:

‘clockrate=rate’

Sets the SPI clocking rate in Hz (default is 100kHz). Alternately the -B or -i options can be used to set the period.

‘timeout=usb-transaction-timeout’

Sets the timeout for USB reads and writes in milliseconds (default is 1500 ms).

USBasp

Extended parameters:

‘section_config’

Programmer will erase configuration section with option ’-e’ (chip erase), rather than entire chip. Only applicable to TPI devices (ATtiny 4/5/9/10/20/40).

xbee

Extended parameters:

‘xbeeresetpin=1..7’

Select the XBee pin DIO<1..7> that is connected to the MCU’s ‘/RESET’ line. The programmer needs to know which DIO pin to use to reset into the bootloader. The default (3) is the DIO3 pin (XBee pin 17), but some commercial products use a different XBee pin.

The remaining two necessary XBee-to-MCU connections are not selectable - the XBee DOUT pin (pin 2) must be connected to the MCU’s ‘RXD’ line, and the XBee DIN pin (pin 3) must be connected to the MCU’s ‘TXD’ line.

serialupdi

Extended parameters:

‘rtsdtr=low|high’

Forces RTS/DTR lines to assume low or high state during the whole programming session. Some programmers might use this signal to indicate UPDI programming state, but this is strictly hardware specific.

When not provided, driver/OS default value will be used.

linuxspi

Extended parameter:

‘disable_no_cs’

Ensures the programmer does not use the SPI_NO_CS bit for the SPI driver. This parameter is useful for kernels that do not support the CS line being managed outside the application.

This document was generated on January 8, 2023 using texi2html 5.0.