Flashing with avrdude

avrdude 7.3 can update lights using a USBASP programmer or a CH340 UPDI programmer. Support for UPDI is new in version 7.0, so be certain to get that version or later. This guide uses avrdude 7.3.

Installing avrdude

Windows

Navigate to the avrdude 7.3 page and download the ZIP file most appropriate for the version of Windows. For example, the x64 file is the correct choice for most current installations of Windows on common PC hardware (64-bit).

There is no installation program, the archive file can be extracted to a safe location, such as under the Download folder for a user, or to a more permanent location.

Some users prefer to keep it isolated in a separate location and run it from there, others prefer to give it a permanent home and add it to their PATH. Either way is fine, it’s up to the user to decide.

Linux

While avrdude can be installed using utilities such as apt, they may not have version 7. For updating using USBASP, older versions are sufficient. But for updating UPDI lights, it may need to be compiled from source if there is no package for version 7.

macOS

Though there are no pre-compiled packages for macOS from the author of the software, it can be installed via Homebrew, MacPorts, and by other means.

avrdude Syntax

Running avrdude depends on how it was installed. If it’s in the PATH it may be as simple as typing avrdude at a terminal shell or command prompt. If it’s in the current directory then it would be run as .\avrdude.exe (Windows PowerShell) or ./avrdude (Linux or macOS).

The avrdude command takes numerous parameters but only a handful are important for the purposes of working with flashlights:

-P <port>

The port through which avrdude can communicate with the programmer.

For USBASP devices this can be omitted as it assumes USB.

For CH340 and similar UPDI programmers this will be the serial port, such as com7 or /dev/ttyUSB0

See also

To locate the correct port for CH340 devices, see CH340 Drivers and Serial Port.

-p <chip part name>

The part number of controller chip (MCU) on the light. This can be the full name or abbreviated in some cases. For example: t85 (ATtiny85), t1634 (ATtiny1634), avr32dd20, or attiny1616. In most cases the MCU for a given light is listed in the Anduril MODELS file.

-c <programmer id>

The type of programmer being used, such as usbasp or serialupdi.

-n

Do not write anything – useful for testing communication between the programmer and controller chip.

-U <memtype>:<operation>:<filename>[:<format>]

Perform the specified memory operation. This is the parameter doing most of the heavy lifting. Each component of this argument is separated by a colon (:).

<memtype>

The type of memory to operate on. Only two areas are relevant for most controller chips found on flashlights, flash and eeprom (Controller Chip Storage Areas).

<operation>

r

Read the chosen area from the chip and write it to a local file. This is used when making a backup of the current firmware on a controller chip.

w

Write the chosen area on the chip using content from a local file. This is used when updating the firmware on the controller chip to a new version using a local file.

v

Read the chosen area from the chip and verify its contents.

<filename>

The firmware filename to read or write. If the file is not in the current directory, include the full path.

When reading, the file will be created or overwritten with the content of the selected area from the controller chip. When writing, the file will be read and used to reprogram the selected area of the controller chip.

<format>

This optional field specifies to the format of the file. When writing new firmware to a controller chip, avrdude can determine the format of a local file automatically.

When reading the firmware from a controller chip to make a backup, use the i format for Intel Hex which is similar to the format of .hex files from compiling Anduril.

See also

For a full list of command line options including lists of parameters for controllers and programmers supported by avrdude, see the avrdude documentation.

Ping the Device

The best first test of connectivity to the light is to perform a “ping” of sorts using the -n parameter which makes sure that avrdude can communicate with both the programmer and the controller chip.

For this to work the programmer must be connected to the computer and the probe must be connected to both the programmer and the light. For example, by touching the probe to the flashing pads or clipping to the chip.

This example runs avrdude as if it’s on the path, communicating with an ATtiny1636 controller through a USBASP programmer, and attempts communication with the chip without making any changes:

$ avrdude -p t1634 -c usbasp -n

This example runs avrdude from the current directory on Windows, communicating with an ATtiny1616 controller through a serial UPDI programmer on COM7, and attempts communication with the chip without making any changes:

PS> .\avrdude.exe -p attiny1616 -c serialupdi -P com7 -n

Later examples will use a mix of different syntax styles, use whichever is correct for a given platform, programmer, and controller chip.

Backing Up

An important part of the process is making a backup of the firmware in case the new firmware does not work as expected. The old firmware can be written back so the light can be returned to its prior state.

When performing a read operation, avrdude reads the contents of the chosen area on the controller chip and then stores the contents in a local file.

For this to work the programmer must be connected to the computer and the probe must be connected to both the programmer and the light. For example, by touching the probe to the flashing pads or clipping to the chip.

Firmware

This example reads the firmware from a light (ATtiny1616 controller, serial UPDI programmer on COM7) and stores the old firmware in a file named old-firmware.hex in the current directory using Intel hex format.

PS> avrdude -p attiny1616 -c serialupdi -P com7 -U flash:r:old-firmware.hex:i

This example reads the firmware from a light (ATtiny85 controller, USBASP programmer) and stores the old firmware in a file named old-firmware.hex in the current directory using Intel hex format.

$ avrdude -p t85 -c usbasp -U flash:r:old-firmware.hex:i

EEPROM

It’s also possible to backup the EEPROM area of the controller chip which contains the current settings.

Warning

The EEPROM data is unlikely to be consistent between firmware versions. Restoring EEPROM data is typically only useful for copying settings to identical lights or when experimenting with different settings.

This example is similar the the previous example, but it copies the EEPROM area of the light to a file named eeprom-backup.hex.

$ avrdude -p t85 -c usbasp -U eeprom:r:eeprom-backup.hex:i

Updating

Now it’s time to write new firmware to the controller chip on the light. This is similar to the read operation above, but in the opposite direction.

When performing a write operation, avrdude reads the contents of a given local file, erases the chosen area of the controller chip, writes the contents of the local file to the chosen area of the controller chip, and then performs a verify operation to confirm the operation succeeded properly.

For this to work the programmer must be connected to the computer and the probe must be connected to both the programmer and the light. For example, by touching the probe to the flashing pads or clipping to the chip.

Firmware

This example reads the firmware from a local file named new-firmware.hex in the current directory and writes it to the flash area on the light light (ATtiny1616 controller, serial UPDI programmer on COM7).

$ avrdude -p attiny1616 -c serialupdi -P com7 -U flash:w:new-firmware.hex

This example reads the firmware from a local file named new-firmware.hex in the current directory and writes it to the flash area on the light (ATtiny85 controller, USBASP programmer).

$ avrdude -p t85 -c usbasp -U flash:w:new-firmware.hex

EEPROM

As with reading, it’s also possible to write to the EEPROM area of the controller chip to restore settings data.

Warning

The EEPROM data is unlikely to be consistent between firmware versions. Restoring EEPROM data is typically only useful for copying settings to identical lights or when experimenting with different settings.

This example reads the EEPROM data from a local file named eeprom-backup.hex in the current directory and writes it to the EEPROM area on the light (ATtiny85 controller, USBASP programmer).

$ avrdude -p t85 -c usbasp -U eeprom:w:eeprom-backup.hex