Blue Yeti Corrupt EEPROM Fix

tl;dr: The configuration of the Blue Yeti microphone can become corrupted by mysterious means, destroying the descriptor used by USB for identification (amongst other settings) and preventing enumeration. Fortunately, these settings can be restored using a specific programming tool provided usually only accessible by OEMs.

Additional note: Its taken me a long time to write this up (nearly two years) since picking up the microphone in March 2021. Since applying the fix I’ve had no issues at all so I’m calling that done.

A replacement microphone had been on my nice to have list for a while. The one built into my Logitech webcam is serviceable… but that’s about it. After an accelerated period of online meetings I regularly on the hunt for anything better. It seems like the rest of the world had a similar idea at the time, and any decent hardware - or at least interesting hardware - was going for more than I could justify for shits and giggles. My needs weren’t urgent, so every couple of weeks I’d search for used and/or broken units on eBay just in case something came up. The funny thing with eBay’s search is it sometimes seems to miss the obvious items. Presumably this is “the algorithm” doing something mere humans cannot comprehend, but a few times I’ve stumbled upon interesting items in the “related items” section of another listing despite matching terms in a more direct search. That was the case here.

A Blue Yeti. Reviews well and retails for 3 to 4 times the asking price. Listed as “for parts or not working” but the item description looked promising (emphasis mine):

Blue Yeti (working but firmware scrambled, 3-USB Advanced Audio Device ). Condition is “For parts or not working”

Mic and usb cable only - No stand

This mic suffer similar problem as this : https://www.programmersought.com/article/35904002559/

It will work fine for discord/skype/TS etc but it will sound bad ( like you inside a tunnel ) if you set gain level above 50-60, all 4 patterns seem to work as well, friends told me there are remedies for this but it required you reconfigured the firmware which take quite a bit of effort.

This mic cannot be RMA.

So, the unit did work… sort of. The missing stand was a minor detail as I wanted a boom mount anyway. A casual search revealed a few people reporting similar issues with no concrete fixes. Seems the usual approach was to RMA the unit if still in warranty and otherwise… not sure, probably add it to the e-waste heap and buy a new one or just learn to live with it. The page linked in the item description stepped through manually turning up the microphone gain and setting the sample rate in the Windows sound control panel, working around whatever the underlying issue was. Seemed like a good enough deal either way; try to restore the microphone and get a repaired unit or at least maybe learn something and end up with some microphone parts.

After doing a little more research the “firmware” bug seemed responsible for a number of different issues. Some units behaved like this one, defaulting to some built-in USB descriptor and messing up gain settings but otherwise working, while other units were unable to un-mute and wouldn’t produce any audio out of the headphone monitor output at all. Lots of dead ends and posts with no conclusion. One post¹ provided a good nice teardown and some work on a solution, but ended with:

Rest assured, I will post an update once I get the mic working again. One way or another, I am pretty sure this can be fixed.

…and that was in early 2018. I did not rest assured…

However, the author had taken a few photos of the internals that enabled a bit more digging. A C-Media CM6400 CODEC runs the show, integrating everything you’d need to develop a range of USB audio products. The datasheet for the CM6400X1² provides a bare minimum of detail. In one package you get:

• A USB transceiver
• Analogue to digital converters (ADCs)
• Digital to analogue converters (DACs)
• A little glue logic and analogue black magic

Some basic configuration is provided externally via an I²C EEPROM. This was as much as the blog post’s author had deduced, that it was likely that this configuration had become corrupted, causing a fallback to default behaviour or perhaps bricking a unit in the worst cases. Without hands on hardware (yet) this was about as far as I could go. Searching for a full CM6400 datasheet or specification of EEPROM layout didn’t lead anywhere, I suspect they are only provided to OEMs after signing non-disclosures.

[ Enter stage left: the Samson Meteor ]

More specifically, a support page titled “Meteor Mic Fix for Windows”³. The issue sounds familiar, a microphone shows up as a generic USB audio device rather than a custom name. And guess what, it can be fixed by uploading a new configuration. What are the odds two competing products just happen to share a CODEC IC…

The real boon of this discovery is in the supplied zip file⁴, containing a binary image and executable. The binary contained Samson’s “firmware” for their microphone, a 256 byte EEPROM image with a couple of clear string fields. The rest of the file is indecipherable, consisting mostly of configuration values that we could correlate back to the datasheet… if we had it. Nevertheless, good to have a reference.

The executable is much more useful as it looks like Samson are distributing C-Media’s configuration tool for the CM64XX line of CODECs. Without hardware connected the tool doesn’t do anything, limiting its utility for generating or decoding the included EEPROM image, so I had to wait for the mail to arrive.

With microphone in hand, I did some initial testing. Per the description it enumerated as “3-USB Advanced Audio Device” and while it worked, it needed some tweaking to get the gain right. Actually, it worked quite well out of the box and certainly a lot better than the description had led me to believe. But… I’d already started digging so better finish. First thing was first, see if the configurator spoke Blue Yeti. Plugging in the VID (0D8C) and PID (016C) and hitting connect actually worked first try.

More dramatic re-enactments. Spoiler alert: this is the end result. From memory, when connected all fields were blank and it complained about invaid values… or something. I did save the dumps below before fixing everything, but that was after tweaking some values.

This allowed me to dump the initial content of the EEPROM (redacted serial number):

00000000  a0 00 04 2a 00 8e 01 b5  02 84 03 9e 08 38 0b 17  |...*.........8..|
00000010  0c 5c 13 00 ff ff 14 0e  15 00 16 f8 17 00 18 07  |.\..............|
00000020  19 00 1a e2 5b 4e 5c 5f  5d 76 72 40 73 40 5b 4e  |....[N\_]vr@s@[N|
00000030  5c 5f 5d 76 72 40 73 40  ff ff ff ff ff ff ff ff  |\_]vr@s@........|
00000040  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff 22 42  |.............."B|
00000050  6c 75 65 20 4d 69 63 72  6f 70 68 6f 6e 65 73 2e  |lue Microphones.|
00000060  59 65 74 69 20 53 74 65  72 65 6f 20 4d 69 63 72  |Yeti Stereo Micr|
00000070  6f 70 68 6f 6e 65 2a XX  XX XX XX XX XX XX XX XX  |ophone*XXXXXXXXX|
00000080  XX XX XX XX XX XX XX XX  XX XX XX ff ff ff ff ff  |XXXXXXXXXXX.....|
00000090  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|

Well that looks like some data… Again, some strings that make sense, some dead space, and a lot of garbage and everything beyond 0x90 contains 0xff out to address 0xff. Saving that file to a safe locations and writing a test configuration to the microphone provided what I assume is a default/blank configuration to which I added the strings from the initial read:

00000000  43 4d 04 18 00 8c 01 0d  02 6c 03 01 04 80 0b 17  |CM.......l......|
00000010  0c 5c 13 00 ff ff 14 0e  15 00 16 f8 17 00 18 07  |.\..............|
00000020  19 00 1a e2 5b 4e 5c 5f  5d 76 72 40 73 40 5b 4e  |....[N\_]vr@s@[N|
00000030  5c 5f 5d 76 72 40 73 40  ff ff ff ff ff ff ff ff  |\_]vr@s@........|
00000040  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff 22 42  |.............."B|
00000050  6c 75 65 20 4d 69 63 72  6f 70 68 6f 6e 65 73 2e  |lue Microphones.|
00000060  59 65 74 69 20 53 74 65  72 65 6f 20 4d 69 63 72  |Yeti Stereo Micr|
00000070  6f 70 68 6f 6e 65 2a XX  XX XX XX XX XX XX XX XX  |ophone*XXXXXXXXX|
00000080  XX XX XX XX XX XX XX XX  XX XX XX ff ff ff ff ff  |XXXXXXXXXXX.....|
00000090  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|

Spot the difference? A handful of bytes at the start of the dump have changed. Interestingly, we can see an interesting series of interwoven bytes starting from 0x04. These look like address-value pairs in the following sequence:

Looks like our missing USB header! In fact, everything that’s scrambled exists in those first 16 bytes. Writing that configuration back to the microphone we now get…

OK, so putting it all together here’s what I think happened. For whatever reason the EEPROM enables writes perhaps at the request of some internal function of the CM6400, perhaps the Windows driver asked nicely for some values to be written or does firmware updates to the CM6400 in the background, there’s no way to tell. After playing with the configuration for a bit I can’t think of any values that might be saved on the fly (it’s mostly fixed gain offsets and hardware configurations) but who knows. That write is interrupted by a power failure (getting unplugged) or reset and a region around whatever address was being accessed gets scrambled. I don’t think this is too much of a stretch, I read somewhere that because EEPROM is such an old technology and fabs have moved onto to mostly flash storage technologies that some vendors will put a sort of emulation layer over the flash to make it look like EEPROM. Hypothetically that could mean that writing a single EEPROM address would require re-writing adjacent cells, but it’s just speculation.

Net result is that a segment of EEPROM which just happens to land in the initial configuration for the USB transceiver gets corrupted, either causing enumeration to fail or maybe (optimistically) falling back to a generic media VID/PID combo. I think this is pretty likely as it would explain how some users end up with bricked microphones (something critical gets corrupted) whilst others can still use theirs with some configuration changes (a gain setting or something non-critical gets corrupted). This case is middle of the road, enumeration still fortunately worked but was reporting incorrectly.

So anyway, I got a fully working microphone for pretty cheap and thought this might help others either repair their units or perhaps rescue some others from landfill. This isn’t really a guide since I have no idea what happens if you’re unable to connect in the app at all, and I suspect that repairing in most instances will require a bit of messing around with binary files, but hopefully this fills the information void I found when I started this repair 🙃. Finally, a little more tweaking of other settings in the configuration seems necessary, but I figure that’s mostly up to personal taste as optimal settings vary with use-case.