Behold this ATtiny85 based EEPROM programmer. It seems like a roundabout way of doing things, but [Quinn Dunki] wanted to build to her specifications using tools she had on hand. What she came up with is an ATtinyISP USB programmer, pushing data to an ATtiny85, which then programs an EEPROM chip with said data.

The hardware is the next module for her Veronica 6502 computer build. When we last saw that project [Quinn] was planning to add persistent storage for the operating firmware. This will be in the form of an EEPROM programmed with this device. Using ISP and an ATtiny as a go-between means that she should have no problems reflashing the OS without removing the chip. But it all depends on how she designs the interface.

For example, she blew a whole bunch of time troubleshooting the device because garbage data was being written to the chip. In the end, having her manual bus programmer hooked up during the flashing operation was the culprit. Lesson learned, it’s onward and upward with the build.

We’ve been featuring [Quinn's] projects a lot lately. That’s in part because they’re really interesting, but also because she does such a great job of documenting her experience.

[Zach's] company is all about the safety and to reinforce those ideals they handed out POV display fans to each employee. “Being Safe is Cool”, get it? Gimmicky… yes, but now [Zach's] got a tiny little POV fan to hack. Although he may not have known it, this isn’t the first time we’ve seen this hardware. These fans were handed out as a promotion at Black Hat a couple of years ago and prompted some reverse engineering action. The message is stored on an EEPROM and there’s even a female programming header that makes it easy to write reflash it with your own messages if you know how to craft the data.

This is where the two products diverge. The older project uses a serial connection and PonyProg to dump and data. [Zach] first tried using his Bus Pirate to dump the data but after having no success he grabbed his Arduino and managed to get the job done. Once the message encoding protocol was worked out, he wrote a sketch to flash the EEPROM. So if you can get your hands on one of these the work has already been done. See [Zach's] custom messages in the video after the break.

But we’d like to see this taken to the next level. How about a wall-mounted device that waits for something, like an incoming email or tweet, then spins up the fan to display it?

[Andrew] recently ordered some lockets to bejewel them with some LEDs but got a bonus small locket for free with the order. Not really having a plan for the small locket it kind of sat around until finally some inspiration hit. Meet the ee-locket which contains a tiny circular pcb with a 64k eeprom, a few passive support components and a male pin header on the back so you can quickly plug it into the micro of your choice.

While the uses of such a thing may not be obvious at first, just sitting down writing this I thought of a few applications, such as some form of key and lock system, mission impossible dreams, or just going full out geek at your next job interview. Its a pretty spiffy idea no matter what its used for, and we just love it when people shove electronics where no one expect them.

We’ve seen projects test the lifespan of an EEPROM before, but these projects have only tested discrete EEPROM chips. [John] at tronixstuff had a different idea and set out to test the internal EEPROM of an ATmega328.

[John]‘s build is just an Arduino and LCD shield that writes the number 170 to memory on one pass, and the number 85 on the next pass. Because these numbers are 10101010 and 01010101 in binary, each bit is flipped flipped once each run. We think this might be better than writing 0xFF for every run – hackaday readers are welcomed to comment on this implementation. The Arduino was plugged into a wall wart and sat, “behind a couch for a couple of months.” The EEPROM saw it’s first write error after 47 days and 1,230,163 cycles. This is an order of magnitude better than the spec on the atmel datasheet, but similar to the results of similar experiments.

We covered a similar project, the Flash Destroyer, last year, but that tested an external EEPROM, and not the internal memory of a microcontroller.

Check out the hugely abridged video of the EEPROM Killer after the break.

Last summer, [Rajendra Bhatt] built himself a simple PIC-based temperature monitor with data logging abilities and recently got around to sharing it on his site. The sensor is based on a PIC12F683 micro controller and measures the ambient temperature on a set interval, storing the values on the MCU’s internal EEPROM.

He used a Maxim DS18B20 temperature sensor, which communicates with the PIC over a 1-wire bus. The sensor is read based upon the interval chosen by the user, and can be configured to measure the temperature every second, every minute, or every 10 minutes. The data is stored on the aforementioned EEPROM and can be uploaded to a computer via a serial connection. The PIC has the ability to store 254 readings before the data must be cleared from the device.

It’s a great beginner project, and has plenty of room for improvement. As [Rajendra] points out, an external EEPROM could be added to expand the recording capacity, and it would be nice to have a real-time clock on hand for accurate time stamping. If we were to build one ourselves, a means of wireless data transfer would be first on our list of potential enhancements.

[Nick] over at Gadget Gangster has a new version of his prototyping hardware for Propeller microcontrollers, called the Propeller Platform USB. A little more than a year ago we looked at the last version which was larger, used a DIP processor, and came unassembled. The new version does come assembled because of the migration to surface mount components (which may take some of the fun out of it if you just love soldering kits). This not only reduces the board footprint, but makes room for more goodies. As the name implies, there’s now a mini-USB socket with a USB to UART bridge, a microSD card slot as been added, and the onboard EEPROM has been doubled. This is a nice hardware upgrade but the price has been upgraded by $25 as well. No worries, it’s open source so you can roll your own if you have the parts on hand.

I took a little time to look into porting code written for AVR in order to run it on the MSP430 architecture. It’s easier than you think, being mostly small differences like an extra step to enable pull-up resistors. But there is a lot to be learned in order to transition away from using EEPROM.

Since the TI chips don’t have EEPROM you need to use the Info Flash, a topic which I detail in the article linked at the top. This flash memory must be erased before writing because a write operation can only change high bits to low, not the other way around. And an erase operation clears an entire 64 kB segment, not just the bytes you want to write to. It’s different but manageable.

Oh, and if you were wondering, I ported the code I wrote for the garage door coded entry project.

This bricked Eee PC came to [Janzo] for about $50. Everything was fine with it, except for the failed bios update that rendered it useless to the last owner. [Janzo] set to work with an Arduino on a quest to repair the bios. He looked up the datasheet for the EEPROM that stores the bios and did some delicate soldering to gain access to the power and data pins on the device. A bit of trial and error and he was able to read the registers. Some comparisons between the output file and the official Eee PC bios file in a HEX editor confirmed that the first 80 bytes were fine but after that something went wrong. After coding a quick Python script [Janzo] reflashed the chip and had the computer up and running again.

We’ve seen Eee PC bios recovery before. This is a very simple method because it makes use of the simplicity we find in the Arduino. Nice job.

The Flash_Destroyer finally succeeded in rewriting that EEPROM until its demise. When we originally looked at the device it had already recorded 2.5 million successful rewrites. The first appearance of corrupt data occurred at 11,494,069 but that doesn’t tell the whole story. The chip kept working for another 200,000 rewrites before finally showing repeated data corruption.

We do find the writeup pretty interesting. There’s one thing that we can’t stop coming back to though. In the discussion of our original article [Tiago] pointed out that long-term data retention isn’t being tested here. If the abuse of that EEPROM had ended after say five million rewrites, would it have been able to hold the data long-term without corruption? Let us know what you think in the comments.

[Thanks Drone377]

There’s a loaded gun but its got only one bullet. Spin the cylinder, point at head, and pull the trigger. The game’s not over until the bullet is used and a player is done. This game’s got a twist though, the cylinder has at least one million chambers.

The Flash_Destroyer is testing the limits of EEPROM rewrites. It fills that little eight-pin chip with data, then verifies what has written. When it finds and error the game is over. The chip is rated for one million rewrites but while we were writing this it was already well over two and quarter million. We usually prefer to be creators and not destroyers with our hacks but there’s something delightful about running this chip into the ground. See the startup of this device after the break and click through the link above to see a streaming feed of the progress.

[Thanks Drone]

[Yuppicide] sent us a link to a photo album of an Atari 2600 modified to play ROMs stored inside. We did some digging around and have an idea of what’s going on. It seems that the creator, [Victor] has taken his Atari 2600 cartridge emulator one step further.

Previously, he had replaced the chip in an Atari cartridge with an EEPROM that he could reprogram via a ribbon cable. This new iteration places that EEPROM inside the case of the gaming console along with a PIC development board. The PIC board interfaces an SD card with somewhere around 1200 ROMs on it. Three switches added to the front of the Atari allow the user to cycle through available games and flash the desired title to the EEPROM. As you can see, a 2×16 LCD display now resides in the cartridge opening.

This seems a little more eloquent (and less legal) than the Super Genintari.

Hacking with Gum got their hands on one of the persistence of vision display fans that Cenzic was giving away at Blackhat this year. It’s not the biggest fan-based POV display we’ve seen but it’s still a fun device to tinker with. They hacked into the EEPROM on the device in order to change the message the fan displayed.

This is very similar to the other EEPROM reading/writing we’ve seen recently. Hacking with Gum read the data off of the EEPROM and then disassembled it to discover how the message data is stored on the chip. This was made easier by noting the messages displayed when the fan is running. The first byte of data shows the number of words in the message, then each chunk of word data is preceded by one byte that represents the number of letters in that work. Data length was calculated based on the number of pixels in each display character. Once he knew the data-storage scheme, it was just a matter of formatting his own messages in the same way and overwriting the chip.

This is a great write-up if you’re looking for a primer on reverse engineering an unknown hardware system. If you had fun trying out our barcode challenges perhaps deciphering EEPROM data from a simple device should be your next quest.

[Thanks James]

Did you forget your hardware-based password and now you’re locked out? If it’s an IBM ThinkPad you may be in luck but it involves a bit more than just removing the backup battery. SoDoItYourself has an article detailing the retrieval of password data from an EEPROM.

The process is a fun one. Disassemble your laptop. Build a serial interface and solder it to the EEPROM chip where the password is stored. Connect this interface to a second computer and use it to dump the data into a file. Download a special program to decipher the dump file and dig through the hex code looking for something that resembles the password. Reassemble your laptop and hope that it worked.

We know that most people won’t be in a position to need a ThinkPad administrator password, but there must be other situations in which reading data off of an EEPROM comes in handy. What have you used this method for?

It started with a simple need: keep tabs on SparkFun Electronics’ in-house kegerator so the beer won’t run out at inopportune times. But of course SparkFun and “simple need” make strange bedfellows…throw beer in the mix, and you know this can’t end well. The result, as you might imagine, reads like a who’s-who of electronics hackery buzzwords.

Arduino? Check. Custom PCB? Check. Web interface? Check. Twitter feed? Check.

They’ve assembled a nice build tutorial on how this all went together, including code, example circuits, an explanation of some of the sensors used, and links to other tutorials for such things as Twittering and persistent storage in EEPROM using Arduino. Not to mention the eye candy: a custom Arduino shield (solder mask and all), custom acrylic tap handle, custom SparkFun pint glasses. They never do anything halfway, do they?

Microchip’s 25AA/25LC EEPROMs are data storage chips with a simple 3-wire interface. The 25AA/LC is an SPI version of the common 24AA/LC I2C EEPROM.  It comes in capacities of 128bytes to 128kilobytes. We looked at the smallest, the 128byte 25AA010A.

There are Bus Pirate demonstrations for most types of serial EEPROMs. Check out our previous 1-wire (DS2431) and I2C (24LC1025) EEPROM posts.

Continue below to see our test circuit and a demonstration of the 25AA010 EEPROM. We used the Bus Pirate to play with this chip from our PC.  For a limited time you can get your own Bus Pirate, fully assembled and shipped worldwide, for only $30.

25AA010A SPI EEPROM memory, 128bytes (Octopart search, $0.70). Datasheet (PDF).

The schematic above shows a simple test circuit that should work with any 25AA/25LC SPI EEPROM. It’s a good idea to use a 0.1uF decoupling capacitor (C1) on the power pin in a real circuit, but we didn’t use one for our demonstration. We also connected the write protect (WP) and hold (HOLD) pins to the supply voltage (V+) to disable these features.

We used our Bus Pirate universal serial interface to demonstrate this chip, but the command sequences will be the same for any setup. We connected the Bus Pirate to the 25AA010 as shown in the table above. We setup the Bus Pirate for SPI mode (M, 5) with normal outputs, and enabled the on-board power supply (capital ‘W’).

25AA parts work from 1.8volts to 5.5volts, 25LC parts have a 2.5volt minimum. We used a 3.3volt supply to power the chip, and interfaced it using the Bus Pirate’s normal 3.3volt pin outputs.

You could also power the chip from the Bus Pirate’s 5volt supply. Interface the chip at 5volts by choosing open drain pin type (HiZ) during the mode configuration, then hold the bus high with pull-up resistors connected to 5volts.

Interfacing

Page 7 of the datasheet has a complete list of interface commands. This demonstration shows the minimum operations needed to write and retrieve data.

SPI>[0b110] <–Bus Pirate command syntax
CS ENABLED <– Chip select enabled (0 volts)
WRITE: 0×06 <–Write enable command
CS DISABLED <– Chip select disabled (V+)
SPI>

A valid write enable command is required before data can be saved to the EEPROM. Enable the chip select signal to wake the chip ([), send the write enable command (0b110 binary, or 0x06 in hexadecimal), and then disable chip select (]).

SPI>[0b10 0 1 2 3 4 5] <– Bus Pirate command syntax
CS ENABLED <– Chip select enabled (0volts)
WRITE: 0×02 <– Write data command
WRITE: 0×00 <– Write address (*sometimes 2 bytes)
WRITE: 0×01 <– Data to write (5 bytes)
WRITE: 0×02
WRITE: 0×03
WRITE: 0×04
WRITE: 0×05
CS DISABLED <– Chip select disabled (V+)
SPI>

Store data in the EEPROM by sending the write command (0×02), the address to start writing (0×00), and the bytes to write (the values 1 to 5).

Up to 16 bytes can be written in a single operation. All writes must be on the same page of memory, see datasheet page 6 for details. EEPROMs larger than 256 bytes use 16 bit (2 byte) addresses.

SPI>[0b11 0 r:5] <– Bus Pirate command syntax
CS ENABLED <– Chip select enabled (0volts)
WRITE: 0×03 <–Read data command
WRITE: 0×00 <–Read address (*sometimes 2 bytes)
BULK READ 0×05 BYTES:
0×01 0×02 0×03 0×04 0×05 <– The data we wrote earlier
CS DISABLED <– Chip select disabled (V+)
SPI>

Read back the values to verify the write operation. Send the read command (0×03) and the address to start reading at (0×00), then read 5 bytes from the chip (r:5). The output should match the values we wrote earlier.

*EEPROMs larger than 256 bytes use 16 bit (2 byte) addresses. Enter a two byte address such as “0 0″ if you’re using one of these EEPROMs.

Like this post? Check out the parts posts you may have missed. Want to request a part post? Please leave your suggestions in the comments.