Opening up the Nintendo Wiimote (RVL-003)
Last Update: June 11th, 2017
What are we doing, exactly?
So, about eleven years ago Nintendo released the Wii console to the world.Despite the name phonetics being a slang phrase for "penis", "urine", and "to urinate", the console went on to great success and ushered in the era of motion controls. Part of the package was a controller with the look, feel, and function of a typical TV remote control and was quickly dubbed "the Wiimote".
The device had a three axis accelerometer (and a later revision had a built in gyro sensor), a unique and novel IR point source tracking camera, a speaker, a rumble motor, an external interface for accessories, four lights, and a bunch of buttons.
It operated over Bluetooth and people quickly figured out how to attach the device to the average computer. However, the controller doesn't really conform to the USB HID spec - it pretty much dumps raw data out - and thus requires special drivers or an extra software layer to work. Wouldn't it be nice if the device would just function as a gamepad and/or joystick?
One would need to rewrite the internal software to do that - which nobody has done, as far as I am aware. Come to think of it, I thought to myself, has anybody figured out how to run arbitrary code on this thing?
That could be a valuable capability - it's no Arduino-ecosystem controller or powerful ARM-cored SBC, but it's got a few neat sensors and inputs in a nice, handy little handheld package.
As a bonus, it's an interesting challenge and I could probably learn a few things from reverse engineering a professionally designed device. My original plan was to just makes some lights blink, but I quickly realized that there was more value in having a functional (and reasonably clean, easy to use) toolchain for the whole device.
Ultimately I'd like to see if I can get a reasonably complete header file included in SDCC - but we'll see.
A brief overview of the problem(s)
The two big problems are: we don't know how the Wiimote is constructed at a hardware level, and the microcontroller on the board is "closed". Figuring out how the Wiimote board works isn't as bad as it sounds - it's probably just going to be a lot of manual work.While I lack the resources to delayer the PCB, the pins and traces need to go somewhere and the board is 'simple' enough that a few hours with a multimeter is probably all one needs to get a general idea of how everything is wired together. In theory all I need to do is strip a board of all parts and get prob'in. The big stumbling block is the microcontroller on the board - a variant of the Broadcom BCM2042. Broadcom is one of the major thorns in the side of the open source community - the parts they make crop up everywhere and they are infamous for completely ignoring any and all requests for documentation. For example, the Broadcom SoCs are the heart of the entire (and highly successful) Raspberry Pi line of single board computers, and even then it was years before they released a heavily redacted datasheet and internal register list for some of the lower end chips. Some of the internal hardware still requires 'blobs' - chunks of raw binary data/code that the Linux kernel loads blindly - to get the camera, video hardware, and display header (I think?) to work.
It baffles me that a company that is completely opaque is able to maintain such a large market segment. Anyway. The point is Broadcoms website is thoroughly unhelpful - more marketing fluff rather technical data. (In fact, sometime in the last few years they removed the product brief they used to have posted!)
Based on previous interactions I didn't actually bother writing in to see if they would share a datasheet. This is an issue because we can't write code for processor that we don't know the internal working of. We're going to need to do some detective work and practice some Google-fu to get the information we need - if we can find it at all.
Prior Work
The first stop is Google. I'm essentially starting from scratch, so any and all information is potentially useful. This device has been in the wild for eleven years and it stands to reason that somebody else may have done some digging already. Rather than reinvent the wheel, I want to locate that information and incorporate it into my overall perception of the device.Sparkfun
Sparkfun Electronics was first on scene all the way back in 2006, and actually did some great groundwork.They identified the major parts, and even found and dumped the serial EEPROM on the board - the binary image of which you can download here. I am actually surprised that they never got a C&D letter about that. In particular, they dropped this little bomb:
"The real kicker was that we found unencrypted 8051 code in the file. We don't know if it is checksumed or anything, but you should be able to hack away. This seems to indicate that the entire Wii Remote functionality is contained on this M24128 EEPROM. Nifty."
It is unclear how exactly they determined that there was 8051 code in the dump - my best guess is that they ran it through an 8051 disassembler and took a look at the output. This breakdown provided tantalizing hints but we need to go deeper.
The Keyglove Project
Around this time I discovered that the BCM2042 was used in various keyboards and mouse devices. Obvious, in retrospect, but not something I had thought about before.Maybe I could buy a few of these devices on eBay or other East Asia store sites and deconstruct them? I would assume that these devices would be simplier and cheaper than a Wiimote and thus let me figure out the ball/pin out of the BCM2042. Turns out one Jeff Rowberg did a lot of the work for me back in 2011, on his path to building the Keyglove, a "wearable, wireless, open-source input device". (It's a glove with sensors and a Bluetooth module on it.) Early on he was dismantling wireless keyboards for the castellated Bluetooth modules inside them, and he happened to be working with units that were built around the BCM2042. As part of his work he did a brief survey of the market and found a number of east Asia manufacturers building essentially identical modules with the same chip.
While interesting and informative (go read his page if you want the nitty gritty details) he was focused on the module use instead of the bare chip. However, one of his side notes made mention of an design guide by a company called Avago Tech that apparently gave a detailed overview on how to construct an optical mouse using a BCM2042-based module.
Avago Tech doesn't exist anymore - it purchased Broadcom back in 2015 and subsumed the name (although it is still traded as AVGO on the NASDAQ). Consequently, Jeffs link to the design guide is dead.
After a little bit of Googling various names I stumbled across the Avago ADNK-3043-BRBT - Bluetooth Optical Mouse Designer’s Kit design guide. It too uses a BCM2042 module, and while it doesn't provide any of the details I was after (ball out, pin functionality) it does mention the exact part number of the module: Broadcom BCM92042MDX-B88. Well, maybe I can find a datasheet for that. Back to teh Googles!
The FCC
...And the top link on Google was for the US Federal Communication Commissions website. The FCC runs a public database for consumer electronics. If it has a device has an FCC ID - and it better if it's using Bluetooth in the USA - the manufacturer is required to provide various documentation proving that their device isn't going to cause interference with the neighbors TV or make pacemakers stop working. Among the required documents are the electrical schematics. Unfortunately (for us) companies have the option of applying for confidentiality for various documents - and that is exactly what Nintendo did with their schematics.I didn't even bother checking until I got to this point, and I was right anyway. But what about other companies that might happen to use that same part and/or module? There are a lot of companies in east Asia that pump out cheap computer accessories, and all of them are supposed to have FCC IDs on file.
Well, that is exactly why the FCC website popped up on the top of the Google search! It took me here: BLUETOOTH KEYBOARD Schematics bcm92042mdx-b88 Wagons Digital Co., Ltd. Bingo! That document appears to be the official Broadcom provided electrical schematic for the BCM92042MDX-B88 module, document number 115056-0020. We got part values, brief descriptions of pin functions, and most importantly the associated ball out numbers of the BGA-88 package. Instead of submitting the full schematic for their keyboard, the people at Wagons Digital Co., Ltd. just forwarded along Broadcoms "Proprietary & Confidential" schematic to the FCC.
It's not as great as a full datasheet, but combined with a little bit of testing (the ball grid numbering scheme should be obvious but it's best to check) we have most of the external physical specs of the chip and a "known good" wiring diagram. Victory.
A word on copyrights and proprietary information
You may have noticed that I didn't post images of, or link to a local copy of the BCM92042MDX-B88 module schematic. Here is the problem: this document is copyrighted by default, and the "Broadcom Proprietary & Confidential" message at the bottom strongly suggests that the schematics were never supposed to 'get out' onto the public Internet. I expect Broadcom will protect it's information with Cease and Desist letters and/or DMCA take-down notices, and while I am not a lawyer I would assume they would be thoroughly within their rights to do so. Frustrating, but it's just the way the law is configured right now in the USA. Fortunately, there is a work around.Most of you are probably familiar with Andrew "bunnie" Huang. He has an impressive list of achievements under his proverbial belt, often working with his friend xobs.
In particular we're interested the the Fernvale project. In it, bunnie and xobs do something very similar to what I'm trying to do here: given a working consumer device (or a whole pile of them) and test equipment, reverse engineer the functionality of a microcontroller that the manufacturer really isn't interested in opening up. I encourage you to go read the full write-up as it is quite fascinating, but the important bit to take away from the project is that facts are not copyrightable. Bunnie uses the example of a phonebook: if one was to duplicate the pages of the phonebook via photocopier or scanner or whatever, that would technically be a copyright infringement. The company that produced the book has various rights protecting the duplication and dissemination of that work. However, the facts contained within that phonebook - the phone numbers - cannot be copyrighted.
In theory, one can manually write down a list of phone numbers from a phonebook, print up a bunch of posters with these numbers, and then post these posters around town (for example) without fearing copyright infringement. The theory here is that I should be able to state facts about the the Broadcom BCM2042 - pin descriptions and placements, internal register addresses and functions, that kind of thing - and so long as I don't directly copy the documentation provided by Broadcom I should be in the clear from a copyright perspective. Which is why I don't just post images of the BCM92042MDX-B88 module schematic. It should be safe to make statements about it, but I can't just serve a copy out from my website. All that said, please note that I am not a lawyer. If Broadcom comes after you, you're on your own.
Wiibrew Wiki and Beeloot
WiiBrew is a wiki dedicated to running homebrew software on the Nintendo Wii.As part of this, there has been a tremendous amount of work put into reverse engineering the hardware of the system. My notes don't indicate why I didn't make this my first stop - these people put a lot of effort into figuring out how the Wiimote works. The EEPROM section of the Wiimote page goes into detail regarding the modifyable contents, but also makes mention that the "firmware stored in the Wiimote has been disassembled". Enter beeloot:
beeloot - 07/01/2009 This is a complete dump of the firmware of my Wiimote. This archive includes a dump of the I2C EEPROM. By modifying the code in the EEPROM I have been able to dump the full address range of code memory, as well as the various code banks. Code memory uses banking mechanism to extend 8051 addressing space beyond 64K. Common area is at 0x0000-0x7FFF, banked area is at 0x8000-0xFFFF. Current code bank is selected via bits 3-2 of port 1. P1[3:2] = 00 => code bank 0 P1[3:2] = 01 => code bank 1 P1[3:2] = 10 => code bank 2 P1[3:2] = 11 => code bank 3 It seems like KEIL C51 compiler has been used to compile the firmware. For example inter-banks function calls use patterns identical to those generated by the C51 compiler. I hope that this material will be useful and will help the community to further understand the inner workings of the Wiimote. Perhaps also some fun things will come out of this (there is for example a serial interrupt handler). Have fun! Directories bank0\ Dump of the code memory 0x8000-0xFFFF bank 0 bank1\ Dump of the code memory 0x8000-0xFFFF bank 1 bank2\ Dump of the code memory 0x8000-0xFFFF bank 2 bank3\ Dump of the code memory 0x8000-0xFFFF bank 3 common\ Dump of the common code memory 0x0000-0x7FFF eeprom\ Dump of the I2C EEPROM contents xram\ Dump of the external data memoryYou can download the dumped file here: B37F523.zip (Beeloots origonal comments were on the Wiihacks forum, but that website has since gone under.)
Aaaaand that is about as far as I got before some other shiny thing caught my attention.
Hopefuly I piqued your interest, though. I'd really like to see these devices opened up.