I’ve sold three EEPROM programmer kits in my first fortnight of trading on Tindie – hardly setting the world alight, but still a big deal for me! Also in that time I’ve received my first report of the kit not working; my first feeling of dread …

The customer reported that he could read EEPROMs fine, but couldn’t write them. The customer (my very first customer, in fact!) was none other than Dave Curran of Tynemouth Software – someone who is hardly new at this sort of thing! I couldn’t help feeling like he should be selling kits to me rather than the other way around, but there we are.

His EEPROMs were legitimate Atmel components – exactly the same type that I use, so his problem seemed perplexing at first. After a bit of discussion we hit upon SDP (“Software Data Protection”). This is, in effect, a write-protect switch for EEPROMs – have a read of page four of this PDF.

This isn’t something that I’ve ever needed to use, and my initial blogposts about EEPROMs were only concerned with the mechanics of reading and writing them … so my project didn’t support it.

But Dave had used a different programmer on that EEPROM in the past, which had chosen to set the protection bit after writing. So the ability to set or unset this protection from my own project would be very useful.

Within half a day, Dave had added two simple extra commands for setting or unsetting this protection, and kindly provided me with his code changes … so I’ve merged them in to my firmware source, and uploaded a new version (0.02) to the main EEPROM programmer page.

I’ve updated the eeprommer command-line utility so that you can now optionally unset the protection bit before writing, and set it back afterwards. I’ll add the same functionality to the Windows app this weekend.

All in all, it’s been a positive experience. I’ve learned something new. It was good to discuss the problem with another geek and come up with a good solution, making the product a tiny bit better. It has also reminded me of the other things I could do with adding: page write, configurable timings and delays (for faster, more modern EEPROMs), and so on.

Update: Dave Curran has blogged about it here.

Update (10th Dec): Bugfix of new protect/unprotect code has led to an update of the firmware. If you grabbed the firmware between the 7th and today (10th) then get latest again.

Another update (10th Dec): I’ve had a proper look at the timings described in the Atmel data sheet. It seems my delays were a little generous – about 10,000 times too large! I’ve slimmed them down to 1 microsecond, and updated the firmware for your reflashing pleasure. Writing is now a much quicker process!

Last update of the day, promise (10th Dec): Windows app eewriter has now been updated to support write-protect/write-enable of compatible EEPROMs.

[Back to EEPROM Programmer project page.]