Hacking Hacking the WiiU gamepad

[Arisotura]

That's what I have in mind. The Wii U can update the gamepad's firmware, and we'll make use of that

Post automatically merged: Apr 17, 2025

Hey, we found something that could be very interesting for development purposes.

A while ago, Lazr drew my attention to these pads on the motherboard:

They are under the battery connector. They're exposed when you take off the battery cover.

Anyway, while looking at the gamepad's I/O registers, I found out that there are 3 distinct UARTs. UART2 is the one that is used for IR comm, while the service firmware uses UART1 as a debug output (and apparently also accepts input over it).

This got me thinking, and I did some testing and probing, and... turns out those pads are UART1!

So far, the pinout is as follows:
1 = RX
2 = ???
3 = TX
4 = Vcc (2.8V)

So this could serve as a handy debug output. I'd yet have to reverse-engineer the UART hardware properly, but the RX and TX pins can also be controlled directly with the GPIO registers (0xF00050D8 and 0xF00050D4, respectively).

 

[Tur7L3]

SInce the Wii U communicates with the Gamepad, there is chance in the future that we can deploy the custom firmware via the Wii U? Or the communication between the two doesnt envolve any data, only streaming?

It can involve data (í.e. Gamepad updates) and Í’m guessing that’a what World be used for the proposed installer

 

[Arisotura]

Well, I reversed a bunch of the UART hardware. Enough to get some communication going... but I don't really know enough about error states.

That's the debug console from the service firmware.

I also wanted to try sending stuff -- according to the code, the service firmware can also take commands to do various things, so I wanted to play with that. However it seemed to crash with a broken error code every time I pressed a key, so...

I think it was because my setup wasn't good. I hacked together a UART bridge with an Arduino and level shifters, but it was causing weird issues in my tests too, I was receiving corrupted values and getting error conditions.

So I ordered a proper USB/UART adapter thingy. We'll try to play with this stuff again whenever I receive it

Fun related thing: my UART test code is based off register writes I logged from my experimental gamepad emulator. Those values caused the baudrate to be absurdly low (40baud or so). I found out that it was because I wasn't emulating register 0xF0000044.

The service firmware has code to calculate the UART register parameters based on a given baudrate and the UART input clock, which is at 0xF0000044 for UART1. The value there is 1, which means 16MHz. However, on the emulator, that code read 0, which means 32MHz...

I quickly hacked that register to 1, and sure enough, I was getting different parameters. Tried those and they yielded the correct baudrate, 115200baud.

However, I transcribed the code that was used to calculate those parameters, and tested it with different baudrates. I found that it is bugged and returns incorrect parameters for certain baudrates. The fix was just matter of swapping two lines.

Amusing.

I also want to dig deeper into the service firmware, as it provides invaluable insight into the gamepad hardware. For example I was able to find how to set the status LEDs, so that's fun. I'm also hoping to figure out the last remaining chunk of the gamepad hardware, the camera controller and h265 decoder. Those are pretty intimidating.

PS-

if you wanna play around with the service firmware console, the parameters are: 115200 baud, 8 data bits, 1 stop bit, no parity.

 

[awesomeee]

A while ago, Lazr drew my attention to these pads on the motherboard:

That's the same person that fixed my wii u a few weeks ago lmao
I checked some of their links and yea they are really really skilled with wii u stuff. Even got somewhat GCN controller on the U

Anyways does this flash chip thing require soldering? My two questions are how difficult it is to take the pad apart and can ya link gary's chip thing lol

 

[Arisotura]

Best to ask Gary himself, I think. I don't know much about it.

Also, the chip is under the motherboard, so that requires taking off the motherboard, which is quite fiddly. If you have a rev 01 motherboard (ie. not the one with the speakers soldered to it), there are test points for the SPI bus that you can access without taking off the motherboard. See https://kuribo64.net/wup/doku.php?id=test_points .

 

[awesomeee]

Alrighty, ill stay out of this beta testing stuff for now then. Seems pretty complicated

 

[Arisotura]

Yeah it's better if you're not comfortable with that kind of hardware stuff... hopefully I can get off my ass and get things somewhat finished. Apparently my brain finds it more fun to go and reverse-engineer stuff... heh.

 

[awesomeee]

Its no worries! Do whatever works. Breaks and other stuff / finishing stuff up are totally okay including this

Ill be sure to still try the melonpad thing when its more publicly available as a wii u installer in the future (I accept any risks of course)

Would the github be a good place to report any bugs?

̶M̶a̶y̶b̶e̶ ̶s̶o̶m̶e̶d̶a̶y̶ ̶w̶e̶ ̶w̶i̶l̶l̶ ̶g̶e̶t̶ ̶M̶e̶l̶o̶n̶D̶S̶ ̶f̶o̶r̶ ̶D̶R̶C̶ ̶p̶o̶r̶t̶

 

[Lazr1026]

I got the debug console working on one of my Gamepads as well. I had a USB UART converter around from 2022ish, so thought "why not?"

The hardware stuff is super easy. 3 wires.


I have absolutely no idea what use this will have, if at all. Still cool!

 

[plasmagrass]

asking the obvious but anyone tried pressing enter several times to see if there's suddenly a prompt appearing?

 

[Lazr1026]

asking the obvious but anyone tried pressing enter several times to see if there's suddenly a prompt appearing?

theres no prompt, but there is commands one can run. not sure what you can do with them though...

 

[Arisotura]

you can change UIC config stuff, wifi stuff...

it appears that the commands are grouped in different categories (ie. "con xxxxx", "uc_config xxxxx", ...) and while you can get a list of possible commands for a given category, there isn't a way to get a full list of all commands.

so we'd need to dig through the service firmware code and compile a full list...

however, the UART stuff might prove useful for development, as a debug output, but also as a way to upload code. I'm considering adding support in melonpad...

 

[Arisotura]

I received my USB UART thingy, so...

Putting together a quick UART bootloader. I intend to provide it for people who want to code for the gamepad and aren't afraid to do a bit of hardmodding.

One would have to manually program this bootloader into their gamepad's Flash memory. As far as UART is concerned, I added a selector. UART1 is the debug serial port we discussed above, so you'd need to solder wires to that. UART2 is the IR port. In theory it should be straightforward to support it, but I can't test it. But if it works, it has the advantage that no soldering is required.

 

[awesomeee]

Good progress. Hope all goes well!

Post automatically merged: Apr 26, 2025

On a seperate note is the gamepad’s wifi anything good or bad? Like how good is it

 

[Arisotura]

Not sure what you mean by 'how good'? It's 5GHz. I haven't really had a chance to test the range because the FPGApad isn't very portable, but it should be equivalent to a regular gamepad's range.

 

[awesomeee]

Not sure what you mean by 'how good'? It's 5GHz. I haven't really had a chance to test the range because the FPGApad isn't very portable, but it should be equivalent to a regular gamepad's range.

Sorry it was a silly question was curious if it was like a fast wifi chip (like good wifi speeds / mbps that kinda stuff. Not sure why i asked but its all good

 

[Arisotura]

Haven't been very active lately. Was coding the UART bootloader (and a small hello world app), but haven't really felt like coding lately. Just been doing other fun shit.

Anyway, exciting news!

I dumped the gamepad's boot ROM!

I was able to do a pretty standard voltage glitch attack. I'm not sure the boot ROM can be dumped in software, though.

It's a bit cursed. The boot ROM is mapped at 0x00000000, that is, it's an overlay over main RAM (instead of being at 0xFFFF0000 as I'd have expected). It is disabled by a plain old lockout bit (I think it's bit 12 in register 0xF0000000).

Potentially more exciting part, the boot ROM supports 3 different ways of loading code: SPI, UART and I2C.

The UART one uses, you guessed it, UART1, the debug serial header thing.

However, which method is used depends on bits in register 0xF0000000. I have yet to figure out if those can be controlled.

But if this can be controlled: it would be a way to load code into a stock gamepad with minimal modding. Just soldering a few wires, no dealing with the FLASH, no FPGA madness. Maybe one could even design a dongle PCB thingy that would fit nicely where needed so you don't need to solder wires.

Going to test all this shito. I'll keep you informed.

--

EDIT-

I figured out!

See this post for reference: https://gbatemp.net/threads/hacking-the-wiiu-gamepad.661890/post-10633869

Shorting pad 2 to ground enables UART boot!

Settings are: 115200 baud, 8N1. It first takes 4 bytes: the total code length, LSB first; then all the code bytes. The code is loaded at address 0x00000000, and automatically booted when all the bytes have been sent.

It is a bit annoying in that the format is different than that of the regular SPI bootloader, so it needs a different link script. It would be similar to a firmware code binary (LVC_), except it would require more initialization to get the hardware going.

Either way, looks like I don't even need to bother with making a UART bootloader at all

--

EDIT2-

Appears it should be possible (and quite easy) to dump the boot ROM in software after all. For whatever it's worth...

 

[Arisotura]

Little status update... since the latest developments in gamepad world, I'm standing at crossroads. Maybe will take a break from this stuff.

Basically, my idea was to provide a simple UART bootloader so other people could also mess with the gamepad without having to wait for melonpad. Then it turns out this functionality already exists in the gamepad's boot ROM, so I don't even need to make that.

However I did start wondering about what I could do on the gamepad, now that "loading code" is a mostly solved problem.

Keep going with melonpad as originally intended?

Make a full-fledged custom firmware? Someone suggested a moonlight port for the gamepad. That could be an interesting idea, and could also be in combination with stock gamepad functionality (ie. connecting to a WiiU, etc). Said CFW could also integrate melonpad's intended functionality and serve as a little homebrew boot menu.

I was also thinking of something to port as a technical demo of sorts. blargSNES? I'm not positive the gamepad would be fast enough for blargSNES, but I guess I can try... maybe the fun DMA stuff could be used to accelerate video rendering somehow.

But I think what I want to do in the near future is reverse-engineer the last big chunk of gamepad hardware, the camera controller and h264 codec. It will be a requirement if we are to do any sort of CFW. Besides, who would say no to some good reverse-engineering work?

There was also the idea of extending gamepad functionality, like for example adding a SD card. It's an interesting idea from the technical challenge standpoint. We have interfaces like SPI and SDIO, but we'd need to find an unused GPIO to act as a select line for the SD card.

So? What does the community think?

 

[Flame]

Little status update... since the latest developments in gamepad world, I'm standing at crossroads. Maybe will take a break from this stuff.

Basically, my idea was to provide a simple UART bootloader so other people could also mess with the gamepad without having to wait for melonpad. Then it turns out this functionality already exists in the gamepad's boot ROM, so I don't even need to make that.

However I did start wondering about what I could do on the gamepad, now that "loading code" is a mostly solved problem.

Keep going with melonpad as originally intended?

Make a full-fledged custom firmware? Someone suggested a moonlight port for the gamepad. That could be an interesting idea, and could also be in combination with stock gamepad functionality (ie. connecting to a WiiU, etc). Said CFW could also integrate melonpad's intended functionality and serve as a little homebrew boot menu.

I was also thinking of something to port as a technical demo of sorts. blargSNES? I'm not positive the gamepad would be fast enough for blargSNES, but I guess I can try... maybe the fun DMA stuff could be used to accelerate video rendering somehow.

But I think what I want to do in the near future is reverse-engineer the last big chunk of gamepad hardware, the camera controller and h264 codec. It will be a requirement if we are to do any sort of CFW. Besides, who would say no to some good reverse-engineering work?

There was also the idea of extending gamepad functionality, like for example adding a SD card. It's an interesting idea from the technical challenge standpoint. We have interfaces like SPI and SDIO, but we'd need to find an unused GPIO to act as a select line for the SD card.

So? What does the community think?

Is it possible to mod somehow and use a Raspberry Pi PICO with a gamepad?

But I love the research you're done for the community so far.

 

[awesomeee]

Someone suggested a moonlight port for the gamepad

That would be SO FUN! Keep it in consideration. FPS would be limited of course since technical limitations.

As for the UART / bootloader stuff I have no idea since technical terms but all seems good

I would say something along the lines of boot into a custom firmware homebrew loader maybe? There you could select booting into Wii U mode or any homebrew apps