This is a small ATtiny84 based device to program I2C and SPI EEPROM chips over a serial port. As usual all code and schematics are available in GitHub.


The TGL-6502 project uses an SPI EEPROM (the Microchip 25AA1024) to simulate the ROM exposed to the 6502 processor. To get the content into the ROM I added a simple serial protocol to the TGL-6502 firmware but as the firmware grew this functionality had to be dropped to free up some of the limited flash memory so I had to find an alternative method.

Bus Pirate

I considered using a generic tool such as the Bus Pirate to program the EEPROMS or even investing in a generic programmer (there are a wide range available on eBay that support various MCU chips as well as EEPROMs). In the end I decided to build my own - the EEPROM programming protocol is very straight forward and I would be needing it for future projects as well.

As well as supporting SPI devices I wanted to be able to program I2C EEPROMs as well (the Raspberry Pi HAT specification uses an I2C EEPROM to provide information about the expansion board) - at this stage the hardware for I2C support is in place but there is no firmware support for that protocol yet, I will add it as I need it.

Hardware Design

I am using an ATtiny84 in 14 pin DIP format as the main CPU for the project. This chip has enough IO lines to do everything needed, more than enough flash to allow for more complex firmware and is small enough to keep the board fairly compact. The circuit could easily be modified to use an ATmega though if that is what you have available.


The circuit is very simple, apart from the CPU the only other electrical components are three resistors and a diode. The first two resistors pull the I2C lines (SDA and SCL) high and the third pulls the ATtiny84 RESET line high. Rather than use a serial bootloader I added a 10 pin AVR ISP header on the board for programming the firmware, the diode is used to isolate the VCC lines from the ISP header and the FTDI connector.

The rest of the components are connectors, the 10 pin ISP header I mentioned, a 6 pin FTDI connector and an 18 pin ZIF (Zero Insertion Force) socket for mounting the target EEPROM in. Using the ZIF socket reduces the risk of damaging the pins on the EEPROM - I had an 18 pin socket in my parts collection already, you can swap it out for two 8 pin DIP sockets if you want.

FTDI Friend

The serial connection and power come from a 6 pin FTDI Friend connector. The ones I use are switchable between 3.3V and 5.0V so when programming 3.3V EEPROM chips I just ensure that I have the FTDI adapter switched to the correct voltage level.

Firmware Design

To make development a bit easier I am using an Arduino core for the ATtiny84 and the firmware is implemented as an Arduino sketch. There were a few hardware limitations of the ATtiny that needed to be worked around in software though.

The ATtiny doesn't have a UART so there is no hardware serial port support - the serial port needs to be implemented in software by driving the IO pins directly at the right time. I didn't have a lot of luck with the Arduino SoftwareSerial library, I could not get reliable serial communications working at any speed. I wound up migrating the serial implementation from my tinytemplate library for the ATtiny85 and using that instead which gives me reliable communications at 57600 baud.

The USI (Universal Serial Interface) module on the ATtiny is used to implement both I2C and SPI but you can only use one protocol at a time. This in itself is not a problem (you will only be programming an I2C or an SPI EEPROM, not both simultaneously) but some of the pins overlap (SCL and SCK for example) which would complicate the circuit and routing. Because SPI is a lot easier to simulate in software (using the shiftIn() and shiftOut() functions in the Arduino library) I reserve the USI module for I2C and selected the SPI interface pins based on how easy they were to route.

One problem I did have in this project is the timer interrupts - the Arduino library uses an interrupt triggered by TIMER0 for timing functions (delay(), millis() and the like). This interrupt seemed to be causing issues with the SPI communications so I disabled it in the init() function:

  // Disable Timer0 interrupts
  TIMSK0 = 0;

In this case I'm not using any of the timer functions so it doesn't effect the rest of the code.

The remainder of the firmware deals with memory buffer management and protocol handling. The current implementation takes up a little over 4K, around half of the available space, which leaves a lot of room for enhancements.

Control Protocol

The programmer is controled over a serial port (57600 8/N/1) using an ASCII ping/pong protocol. You send a command terminated by a line feed character and wait for a response terminated by a line feed character. The response must be received before the next command can be sent. There are 5 available commands, outlined below:

/** Supported commands
 * Each line received by the programmer starts
 * with a single letter command, these are what
 * we support.
typedef enum {  
  CMD_RESET = '!', //!< Reset the device, clear all settings
  CMD_INIT  = 'i', //!< Initialise and set the target device.
  CMD_READ  = 'r', //!< Read data from EEPROM
  CMD_WRITE = 'w', //!< Write data to EEPROM
  CMD_DONE  = 'd', //!< Done. Flush any pending data

With the exception of RESET the first character of the response will indicate success ('+') or failure ('-') and there may be additional information between the result character and the end of the line. For the read command this is hex data, for other commands any additional characters can be treated as an informational message.

The details of each command are described below, you can use a serial terminal to talk directly to the programmer but don't include the '<' and '>' characters shown in the examples - they are used to indicate the direction of the data.


This should be the first command sent to the device - it will set the device into an idle state and ensure the power to the EEPROM slots is turned off. Unlike the other commands this one does not respond with a +/- success or failure indication - instead it reports the programmer identification string and the firmware version.

> !
< EEPROG V0.1  

After receiving the reset command (and responding with the identity string) the programmer will go into IDLE mode.


This command is used to tell the programmer the type and specifications of the EEPROM it is dealing with. For each EEPROM we need to know a number of parameters:

  1. The EEPROM protocol - SPI or I2C.
  2. The size of the EEPROM. I use the number of bits in the address to determine this.
  3. The size of the EEPROM write page. This is the smallest amount of memory that can be written at once, once again I use the number of bits to determine the size (eg: a 32 byte page is 6 bits, 256 bytes is 8).
  4. The number of bytes of address to send on the SPI bus.

This information is encoded in a 16 bit integer as shown below.

ID Word Encoding

The 16 bit value is sent as hex with the INIT command and the programmer will respond with success if the configuration is acceptable.

> i7830
< +SPI 128Kb, 256 byte page, 3 byte address.  

The following table shows the ID codes for some of the Microchip EEPROMs I have been using:

Part Size Page Size Address Bytes ID Code
25AA1024 1Mbit (128K x 8) 256 bytes 24 bit 0x7830
25LC1024 1Mbit (128K x 8) 256 bytes 24 bit 0x7830
25AA640 64Kbit (8K x 8) 32 bytes 16 bit 0x4620


Use this command to read data from the EEPROM. The command character is followed by a 3 byte address in hexadecimal and a successful response is the 3 byte address, a sequence of data bytes and a 2 byte checksum.

> r000000
< +000000d8a2ff9aa900a20c85008601202cc020a3ce2020c020f2cc48202ece684c1dc00de6  

The checksum is simply a sum of all bytes in the response (excluding the checksum itself) and the lowest 16 bits of the value is used as the checksum. The code to do this looks like the following:

/** Calculate a 16 bit checksum of a sequence of bytes
 * @param pBuffer the buffer containing the data
 * @param length the number of bytes to process
 * @return the 16 bit checksum
static uint16_t checksum(const uint8_t *pBuffer, uint8_t length) {  
  uint16_t result = 0;
  for(uint8_t index=0; index<length; index++)
    result += (uint16_t)pBuffer[index];
  return result;


This command is used to begin or continue a write sequence. Once the first write command has been accepted you can continue writing to sequential addresses or send a DONE command (described below) to finish the sequence and return to READY mode.

The format of the WRITE command is similar to the response from the READ command - a 3 byte address, a sequence of data bytes and a 2 byte checksum. The checksum is calculated in the same way as for READ - simply sum the byte values in the line into a 16 bit integer ignoring overflow.

> w000000d8a2ff9aa900a20c85008601202cc020a3ce2020c020f2cc48202ece684c1dc00de6
< +  
> w000000d8a2ff9aa900a20c85008601202cc020a3ce2020c020f2cc48202ece684c1dc00de6
< -Data is not sequential.  

Note that the write command will buffer data into RAM until it has a full page to write to the EEPROM - you must use the DONE command to terminate a write sequence to ensure all data has actually been written. If the buffer only contains a partial page the rest of the contents will be filled with whatever is already in the EEPROM allowing you to do partial page writes to patch the data in the EEPROM rather than doing a complete rewrite.


All write sequences must be terminated with this command. If there is a partial page still in the RAM buffer it will be filled with the current contents of the EEPROM and written. The command then returns to READY mode allowing you to issue READ commands or start another WRITE sequence.

> d
< +  

The EEPROG Utility

The repository includes a simple Windows GUI utility to control the programmer in the software/eeprog directory.

EEPROG Utility Screenshot

You can compile this utility with the Visual Studio Community Edition - it's a simple Windows Forms application written in C#. The utility doesn't make use of all the functionality of the programmer - it simply allows you to burn an arbitrary binary file to the target EEPROM or read the contents of the EEPROM to a binary file. In most cases this will be all that you need.

Next Steps

The tool currently provides all the functionality I need to work on the TGL-6502 but there are obviously a few enhancements that can be made. So far I have only tested the device with Microchip SPI EEPROM devices which all have the same command set - supporting other manufacturers devices may require providing additional information in the EEPROM identity word to select alternative command sets.

Support for I2C devices is built in to the hardware but not yet implemented in the firmware. I intend to use the Arduino Wire library to communicate with these chips.

The programming utility for Windows could be extended to support Intel HEX format files as well as raw binary which would be useful for dealing with output from linkers. The ability to set the start address for programming would also come in handy rather than having to prepare a complete EEPROM image for every burn. More importantly a command line utility that could be incorporated into make files is a must.

All of these enhancements are relatively simple to implement and I will modify the code to support them as the need arises. If you make the changes yourself (or add interesting new functionality) please send me a pull request and I'll add them to the main repository.