The UIC is the gamepad's auxiliary microcontroller. It is connected to the CPU over the SPI bus.

Given the characteristics, the UIC could be a STM8L151R8. It has 4KB of RAM, 2KB of EEPROM and 64KB of FLASH.

Pins 1 and 2 are connected to test points TP233 and TP234 respectively. Pin 1 doesn't seem to be connected to anything else. Pin 2 is connected to a simple reset circuit.

Pin 1 would be the SWIM debug pin, but as far as I've seen, SWIM seems to be entirely disabled on the UIC.

Bootloader commands must be sent in two bytes, where the second byte is the first byte negated. Additionally, the read/write commands have basic integrity checks on the input data.

The only exception is command 0x7F.

Bootloader commands only apply when the UIC is in firmware upload mode (ie when no firmware is installed). In this mode, it is required to send command 0x7F before the other commands become available.

The command set is based on the official STM8 bootloader command set, with a few differences:

• The data returned by command 00 FF is wrong
• Command 21 DE does not take an address
• Command 11 EE is limited to 128 bytes
• There is no memory erase command

Get bootloader version and supported commands.

Response is 8 bytes: 0x79, 0x05, 0x10, 0x00, 0x11, 0x21, 0x31, 0x43.

The first byte is the bootloader's standard 'OK' code. The latter 7 bytes are hardcoded.

The second byte is the number of command bytes. The third byte is the bootloader version. The subsequent bytes theoretically list the supported commands. In practice, the list advertises command 0x43, but it isn't supported.

This command doesn't seem to do much beyond returning a fixed response, so it probably just serves to ensure the UIC is ready for a firmware upload. On the gamepad, the host ignores the response bytes.

Read memory.

First set of parameters: 5 bytes, AA BB CC DD EE

• AA = address bit 24-31
• BB = address bit 16-23
• CC = address bit 8-15
• DD = address bit 0-7
• EE = AA^BB^CC^DD

A response is sent after the first set of parameters: 0x79 = OK, 0x1F = error (incorrect parameters).

Second parameter: one byte, length of data to read. Maximum length allowed is 128.

A second response is sent after this second parameter byte, with same values as the first response.

If the second response is 0x79, it is followed by the requested data.

Finalize firmware upload.

Response is one byte: 0x51.

This command writes the bytes 0xA5 0x5A at address 0x1010, to indicate that a firmware is installed. Then the UIC is reset.

Write memory.

First set of parameters: 5 bytes, AA BB CC DD EE

• AA = address bit 24-31
• BB = address bit 16-23
• CC = address bit 8-15
• DD = address bit 0-7
• EE = AA^BB^CC^DD

A response is sent after the first set of parameters: 0x79 = OK, 0x1F = error (incorrect parameters).

Second parameter: one byte, length of data to write. Maximum length allowed is 128.

A second response is sent after this second parameter byte, with same values as the first response.

Then the data to be written is sent, followed by one checksum byte. The checksum is the data length XORed to each data byte.

A third response byte is sent: if the integrity check passes and the data is successfully written, the response is 0x79, otherwise it is 0x1F.

This command is used to upload firmware data to the UIC's FLASH memory.

In firmware upload mode, command 0x7F returns 0x79.

Set UIC state.

Parameter: one byte, the UIC state to switch to.

There are restrictions on which state you can switch to based on the current state, see UIC states to see which transitions are possible.

Write UIC memory. Used to write to the EEPROM.

Parameters: AA BB CC

• AA = address bit8-15
• BB = address bit0-7
• CC = length

Followed by CC bytes of data.

After sending the parameter bytes, the host should wait atleast 60 microseconds before sending the data. Sending the data too early can cause the UIC-side DMA to malfunction.

Address must be within range 0x1100..0x17FF.

Before using this command, the EEPROM must be unlocked for writing via command 0x06. After all data is written, command 0x04 must be used to commit the changes to EEPROM. Command 0x02 may be invoked multiple times in a row.

Internally, this command redirects the provided address to RAM at 0x01B7. Command 0x04 does write back RAM data to EEPROM.

Read UIC memory. Used to read the EEPROM.

Parameters: AA BB CC

• AA = address bit8-15
• BB = address bit0-7
• CC = length

Response is CC bytes of data.

Address must be within range 0x1100..0x17FF.

Internally, this command redirects the provided address to RAM at 0x01B7, where a copy of the EEPROM data is kept.

EEPROM write disable. Commits EEPROM writes. Should be invoked after writing to EEPROM.

After invoking this command, the host should wait atleast 140 milliseconds before sending further UIC commands.

Query the current UIC state.

Response is one byte: the current UIC state.

The UIC starts in state 11.

EEPROM write enable. Should be invoked before writing to EEPROM.

Query input data.

Response:

Button bitmask:

Power status:

Extra button bitmask:

Touchscreen data:

Each sample is 4 bytes long: 2 bytes for the X coordinate, 2 bytes for the Y coordinate. The X and Y coordinates take up 12 bits.

The remaining bits are used to store a touchscreen pressure reading. See the libdrc page on input data for more information.

Begin firmware update. After this command is sent, command 0x7F will return 0x79, and the UIC will be ready to accept a firmware upload.

WARNING: the UIC remembers the 'waiting for firmware update' state even after a full power-off.

Parameter: unknown, set to zero.

Toggle backlight.

Parameter: 0x00=off, 0x01=on.

Returns some status bit.

This commands reads the value at 0x0006 in RAM, and returns bit 1 of that value. Not sure what the value means, but it seems tied to the blue power LED, so it is likely related to the power management system.

The stock gamepad firmware waits for the return value from this command to become 1 before doing wifi initialization, so this is likely related to wifi power too. Not waiting for it to become 1 before doing wifi init will cause the wifi hardware to stop functioning when it becomes 1.

Response: one byte, 0 or 1.

Reboot the gamepad.

Query firmware ID/version.

Response: 0x2F or 0x3F when a firmware is installed. 0x79 when a firmware needs to be uploaded.

WARNING: the following is theoretical and has not yet been successfully replicated so far. A firmware upload gone wrong can and will brick the UIC.

The process to upload a new UIC firmware is as follows:

1. Send command 0x7F to identify the currently installed firmware
2. If command 0x7F returned 0x2F or 0x3F: send command 0x09 to switch to firmware update mode. Check with command 0x7F until it is effective.
3. Send bytes 0x00, 0xFF. Receive 0x79. (1)
4. Receive 7 bytes.

Then you are ready to upload the firmware data, in chunks of 128 bytes maximum. For each chunk:

1. Send bytes 0x31, 0xCE. Receive 0x79.
2. Send bytes AA, BB, CC, DD, EE (where AA=address bits 24-31, BB=address bits 16-23, CC=address bits 8-15, DD=address bits 0-7, EE=AA^BB^CC^DD). Receive 0x79. (2)
3. Send byte AA (where AA=length of this chunk). Receive 0x79.
4. Send each data byte, then a trailing byte AA (where AA=length of this chunk XORed to each data byte). Receive 0x79.

When all chunks are uploaded, send a final command:

1. Send bytes 0x21, 0xDE. Receive 0x51. (3)
2. Your new UIC firmware is now up and running!

(1): Each “send, receive” line is understood as one single SPI transaction. “Receive 0x79” means to keep receiving bytes until receiving a nonzero value. A value of 0x79 indicates success. In the stock firmware code, under some circumstances, another value will prompt retry attempts, while under other circumstances it will be an outright failure case.

(2): The address is in UIC memory space. The UIC firmware upload starts at address 0x9000.

(3): “Receive 0x51” means to keep receiving bytes until receiving a value that isn't 0x79. A value of 0x51 indicates success.

The UIC has 15 possible states. The state determines what it will do, for example, input polling is only done in certain states.

The current UIC state can be retrieved with command 0x05, and changed with command 0x01. The following table shows which state transitions are allowed:

An X denotes an allowed state transition. For example, if the UIC is in state 0, you may switch to state 1, but not to state 2.

When powering on the gamepad, the UIC starts in state 11, which is an idle state (where, among other things, no input polling is done). Switching to states 3 or 4 puts the gamepad in sleep mode. Pressing the power button turns the gamepad on again, but this time the UIC is in state 0 and ready to go.

TODO: work out and document what the various states do. Also, maybe different EEPROM parameters start the UIC in a different state?

States 3 and 4 may not work correctly under certain conditions, like if the backlight is on.

The gamepad's expansion port is connected to the UIC's I2C BUS. It hasn't been used by any retail device, however it is used by Nintendo for diagnostics purposes.

The diagnostics firmware contains a test named “CHECK USB JIG PULLED OUT”, which implies that Nintendo's device is a USB adapter of sorts.

To further prove this, the “POWER_USB” bit in the power status bitmask (in the command 0x07 input data structure) is set or cleared after attempting to probe device 0x48 on the I2C bus.

It isn't clear whether the USB jig serves to transfer data to/from the gamepad somehow, or whether its sole purpose is to activate the diagnostics mode. The retail UIC firmware doesn't appear to contain any functions for interacting with an expansion device beyond the aforementioned probing.