Dumping EEPROM via Two-Wire Interface using Windows IoT Core and Windows Runtime APIs

Posted on December 10, 2017 by Rafael Rivera in Windows, Windows 10 with 22 Comments

I revisited Windows IoT Core a few weekends ago and found it to be useful in a quick project that involved dumping my wireless headset’s electrically erasable programmable read-only memory (EEPROM). In other words, just another weekend at Rafael’s place.

But first, a little background.

I own a reasonably old wireless headset–Turtle Beach Ear Force PX3–that I’ve been keeping on life support because of its premium recording capabilities. Thus far, I’ve found no other headset that can record audio as well as the PX3. (Well, there was the Plantronics Audio 995 but I’ve gone through all the reserves left on this planet.) So I’ve invested in reverse engineering my headset to ensure I can restore function to pieces that need replacement. For example, I’ve rebuilt its poorly designed plastic buttons in CAD software for 3D printing on-demand.

The headset has a nugget of memory (EEPROM) that stores configuration information for the programmable audio equalization features of the headset. And while I don’t use these features, the headset fails to boot up if that data is corrupted or missing. And with EEPROM having a finite amount of reads before going kaput, it’s a ticking time-bomb. I need to back up its contents.

So let me walk you through what I did.

Hardware Setup

First, I pulled down the Windows IoT Core Dashboard and set up a new device. I flashed a MicroSD card with the latest build of Windows IoT Core and popped it straight into the Raspberry Pi 2 (Amazon, ~$40). After a bit of configuration, the device was online and ready to receive instructions from Visual Studio.

I then skimmed through the datasheet and attached some test clips to the EEPROM chip (ACE24C256) for Ground, Serial Clock and Serial Data access. I routed those to the Raspberry Pi’s GPIO2, GPIO3 and Ground pins where Two-Wire Serial (TWI)/Inter-integrated Circuit (I2C) communication is expected to occur.

That was the extent of the hardware configuration I performed.

(Two-Wire Interface is mostly identical to I2C, cleverly created to sidestep trademark issues with I2C. I say mostly because it’s missing a few niceties like 10-bit addressing.)

Software Setup

Windows IoT Core runs apps targeting the Universal Windows Platform (UWP), but the templates that ship with Visual Studio are way overkill for what I needed. So, I instead installed the Background Application Template from the Visual Studio Marketplace. This template creates a simpler project with a bare-bones implementation of a Background Task.

Using that starter code, I followed the usual deferral pattern (to prevent the app from killing my asynchronous tasks) and started laying down the code I needed:

  • Retrieved an instance of the I2cController class, corresponding to the default I2C controller (and set of pins) on the Raspberry Pi.
  • Retrieved an instance of the I2cDevice class, representing the chip I wanted to dump. This requires an I2cConnectionSettings object that points to the chip via a 7-bit numerical address. In this chip’s case, the address is crafted by setting its first 4 significant bits to [1010] and the next 3 to [000]. That becomes [1010000] or 50 in hexadecimal. (The I2C classes manage the 8th bit on the fly.)
  • Took advantage of the faster clock speeds supported by the chip by setting the device Bus Speed to FastMode (400kHz).
  • Prepared a file for holding the EEPROM contents

I paused at calling the I2cDevice.Read method for a moment, because it only took one parameter – a buffer to store data clocked out of the chip. It doesn’t support addressing. But I remembered I2C/TWI isn’t limited to just storage applications – it’s higher level than that. So I needed to review the datasheet again to understand the protocol implemented on top of I2C/TWI to read data correctly from the chip.

Here’s what I picked up from the datasheet:

  • A Current Address Read is performed by clocking in a read bit (0). The chip responds by clocking out the byte of data at the current address.
  • A Sequential Read is performed by looping a Current Address Read, paired with an acknowledgement, to effectively move the address pointer forward by 1 byte each iteration.
  • A Random Read is performed by first preparing the chip for a dummy write operation, to set its internal address pointer, then switching mid-way to a Current Address Read operation. Sneaky!

I implemented this logic using the I2CDevice.Read and I2CDevice.Write methods on the Device object I created earlier. Because the I2cDevice class handles I2C/TWI addressing and other minutia (in green) for me, I only had to worry about the data portion of the protocol (in purple). In this case, to set the internal address pointer to 0, I had to write two zeros (8 bits each). Got it.

With the dummy write out of the way, I switched to using the I2CDevice.Read method to complete the Random Read operation. The I2C classes did the heavy lifting while I dumped my buffer to disk. I then come behind the app to scoop up the file with the IoT Dashboard.

With a fresh EEPROM dump in hand, I was done.


Tagged with , , ,

Join the discussion!


Don't have a login but want to join the conversation? Become a Thurrott Premium or Basic User to participate

Comments (22)

22 responses to “Dumping EEPROM via Two-Wire Interface using Windows IoT Core and Windows Runtime APIs”

  1. MikeGalos

    Interesting article. I do wonder, though, whether thurrott.com is a place where it will find an audience.

  2. skane2600

    Interesting. I'll have to look at your code in more detail and MS's classes. Trying to write a general purpose I2C handler is difficult because of the different ways that different devices have to be addressed. Not much of a problem when addressing a single I2C device, but a pain when multiple devices need to be handled within a single program. Particularly difficult when the I2C is interrupt driven.

    Then again I was writing the code for a microcontroller in C without an OS, which is a quite different scenario.

  3. Matt Goldman

    Great article Rafael! I must admit I come to thurrott.com with decreasing frequency these days. This is reminiscent of the kind of things I would read in tech (mostly Amiga) magazines 20 years ago, and is just the kind of thing that would keep me coming back here. Great work, keep it up!

  4. DaveHelps

    Sometimes you only need the first few words of the headline to know that it’s a Raf article ?

  5. mahoekst

    Nice article, keep it up!

  6. Pargon

    As a nuclear engineering student and former navy electronics technician and reactor operator, who made a radiation detector with a raspberry pi 3 and some logic gates just 2 weeks ago I'd understand this much more if *any* explanation was given of what I2C is, or why you wanted to dump an EEPROM. I'm familiar with basically every part of this article except the glue between all the pieces, ie your lack of what, how, why. Was the headset broken, wanted to upgrade it with a faster chipset, did you connect it via USB, why would a raspberry pi be the method of choice? It really just was not written well for probably the majority of your audience. It's as if I would have turned in my lab report with no introduction or theory section and jumped straight into the results of pulsing the reactor.

    • Rafael Rivera

      In reply to Pargon:

      Thanks for the feedback!

      I deliberately avoided trying to explain I2C/TWI -- I'm not an expert and I don't think it's particularly important for a results oriented "lab activity". I could be off here. Normally I'd throw this on my personal blog as a technical nugget and move on.

      I shot for a Technical How To, instead of trying to invent a story around what really amounted to me just tinkering around. How boring would that set up be? "I was sitting around and wondering if I could preserve a copy of my old headset's eeprom."

      But some background:

      My headset (Turtle Beach PX3) is way past end of life and I've been 3D printing parts to keep it alive. It's one of the only truly great wireless headsets w/ premium *microphone* quality. That's rarer than you think. I figured it's important to preserve a copy of its EEPROM in the rare event it gets corrupted or needs replacement down the line... Oh. That's the backstory I should have provided. Point taken!

      [I've added a version of this to the article since comment.]

    • skane2600

      In reply to Pargon:

      In simplest terms I2C is a two-wire serial communications bus that is typically used in embedded systems to connect microcontrollers to other devices. Its advantage is that it allows a processor access to devices without having to add additional hardware for decoding addresses as would be the case if the devices were connected to a parallel bus. For more information see www.i2c-bus.org/

      Only Rafael can explain why he wanted to dump the EEPROM, but he may have just wanted to experiment with I2C.

  7. mrdrwest

    I flap jacking loved this!!!

    Ok, it wasn't in assembly language ( I find high level frameworks for these kind of projects overkill, but...)

    Thanks for sharing Rafael!

    FYI, I wouldn't mind seeing more stuff like this.