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

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.

Windows Intelligence In Your Inbox

Sign up for our new free newsletter to get three time-saving tips each Friday — and get free copies of Paul Thurrott's Windows 11 and Windows 10 Field Guides (normally $9.99) as a special welcome gift!

"*" indicates required fields

This field is for validation purposes and should be left unchanged.

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.


This post contains one or more affiliate links. We only recommend products and services that we believe are of high quality and helpful to readers. Making a purchase through an affliate link is one small way you can support Thurrott.com, and doing so does not result in any additional cost to you.

Tagged with

Share post

Please check our Community Guidelines before commenting

Conversation 24 comments

  • MikeGalos

    10 December, 2017 - 6:40 pm

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

    • Rafael Rivera

      Premium Member
      10 December, 2017 - 6:46 pm

      <blockquote><a href="#226183"><em>In reply to MikeGalos:</em></a></blockquote><p>Yeah, we're definitely in uncharted territory here.</p>

      • MikeGalos

        10 December, 2017 - 6:53 pm

        <blockquote><a href="#226185"><em>In reply to WithinRafael:</em></a></blockquote><p>It'll be interesting to see the site statistics for this article.</p><p><br></p><p>On an unrelated note, it's surprising that an ancient proprietary standard like I2C hasn't been made public after decades of use and multiple corporate mergers and sales. </p>

      • Chris_Kez

        Premium Member
        11 December, 2017 - 11:40 am

        <blockquote><a href="#226185"><em>In reply to WithinRafael:</em></a></blockquote><p>I think this kind of article would benefit from a quick sentence or two explaining in simple terms why you're doing this. What is EEPROM (briefly) and why would you want to "dump" it?</p>

        • Rafael Rivera

          Premium Member
          11 December, 2017 - 4:08 pm

          <blockquote><a href="#226429"><em>In reply to Chris_Kez:</em></a></blockquote><p>Thanks Chris, added a background blurb at the start.</p>

          • Chris_Kez

            Premium Member
            11 December, 2017 - 9:11 pm

            <blockquote><a href="#226538"><em>In reply to WithinRafael:</em></a></blockquote><p>Freaking awesome; love it! ?</p>

    • Brad Sams

      Premium Member
      10 December, 2017 - 8:47 pm

      <blockquote><a href="#226183"><em>In reply to MikeGalos:</em></a></blockquote><p>There is a decent sized dev audience on Thurrott…Paul did <a href="https://www.thurrott.com/dev/106017/20-years-visual-studio-visual-interdev-1-0&quot; target="_blank">a deep dive into its history earlier this year</a> that did quite well.</p><p><br></p><p><br></p>

      • IanYates82

        Premium Member
        11 December, 2017 - 4:46 pm

        <blockquote><a href="#226200"><em>In reply to brad-sams:</em></a></blockquote><p>Yes, this kind of article is great to see.</p><p>Even if you don't understand it at first, just still give it a read. What I consider myself to be very proficient or even expert in now, I had to start somewhere. Often that's just being aware of what's out there and what's possible. From that you build knowledge and have a bunch of tools in your back pocket to call upon when required. That's much better than being completely ignorant of the existence of such tools in the first place.</p><p><br></p><p>Now I don't think I'll be dumping EEPROM anytime soon, but at least if I need to do something with I2C (you never know!) then Windows 10 IoT will at least become an option in my mind, whereas I'd never have even thought to go down that path previously.</p>

    • graememeyer

      11 December, 2017 - 4:44 am

      <blockquote><a href="#226183"><em>In reply to MikeGalos:</em></a></blockquote><p>I love this kind of stuff, so I'm glad to see it on thurrott.com. I'm not quite at the skill-level to make use of it yet, but still love to read, so definitely want to see more!</p>

      • jclarytx3

        11 December, 2017 - 7:05 am

        <blockquote><a href="#226254"><em>In reply to graememeyer </em></a>Same here. Love it!</blockquote><p><br></p>

    • Skipper

      11 December, 2017 - 4:10 pm

      <blockquote><a href="#226183"><em>In reply to MikeGalos:</em></a></blockquote><p>I'm a daily reader of Thurrott.com, and would definitely like to see more of this how to tech</p>

  • skane2600

    10 December, 2017 - 7:22 pm

    <p>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. </p><p><br></p><p>Then again I was writing the code for a microcontroller in C without an OS, which is a quite different scenario.</p>

  • Pargon

    Premium Member
    11 December, 2017 - 9:48 am

    <p>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. </p>

    • skane2600

      11 December, 2017 - 12:26 pm

      <blockquote><a href="#226331"><em>In reply to Pargon:</em></a></blockquote><p>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 http://www.i2c-bus.org/</p><p><br></p><p>Only Rafael can explain why he wanted to dump the EEPROM, but he may have just wanted to experiment with I2C.</p>

      • skane2600

        12 December, 2017 - 7:08 pm

        <blockquote><a href="#226460"><em>In reply to skane2600:</em></a></blockquote><p>Wow, some people will down-vote anything. I didn't attack anything, just provided the background information on I2C Paragon asked for.</p>

    • Rafael Rivera

      Premium Member
      11 December, 2017 - 1:04 pm

      <blockquote><a href="#226331"><em>In reply to Pargon:</em></a></blockquote><p>Thanks for the feedback!</p><p><br></p><p>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.</p><p><br></p><p>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."</p><p><br></p><p>But some background:</p><p><br></p><p>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!</p><p><br></p><p>[I've added a version of this to the article since comment.]</p>

  • mahoekst

    11 December, 2017 - 4:55 pm

    <p>Nice article, keep it up!</p>

  • DaveHelps

    Premium Member
    11 December, 2017 - 5:31 pm

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

  • Matt Goldman

    12 December, 2017 - 4:14 pm

    <p>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!</p>

  • mrdrwest

    15 December, 2017 - 6:34 pm

    <p>I flap jacking loved this!!!</p><p><br></p><p>Ok, it wasn't in assembly language ( I find high level frameworks for these kind of projects overkill, but…)</p><p><br></p><p>Thanks for sharing Rafael!</p><p><br></p><p>FYI, I wouldn't mind seeing more stuff like this.</p>

Windows Intelligence In Your Inbox

Sign up for our new free newsletter to get three time-saving tips each Friday

"*" indicates required fields

This field is for validation purposes and should be left unchanged.

Thurrott © 2024 Thurrott LLC