The goal here is to write some Rust drivers via the HAL. Not really interested in nafarious or useful things coming out of this, it's just fun. This is all based on "version 3" of the PCB. For high resolution pictures see the FCC test results.
- AT45DB021E 2Mb SPI EEPROM
- TLV320DAC3203 DAC (Reference Guide)
- TCA8418 Keypad Scanner
- CC2530F256 SoC with 802.15.4 radio
- BMA222E Accelerometer
- Unknown amplifier for the speaker. Ten pin, marked 77flg76
Notes:
- The DAC has both SPI and I2C to control the DAC's configuration and the mode pin has been permanently set to I2C.
- The keyboard scan matrix IC might be the same one used in the PocketCHIP which would be nice as I have one of those too.
Interesting bits about the wiring on the PCB
There are a few voltage regulators on the board (one in particular for the audio circuits). The primary logic level is driven directly from the batteries. Other voltages (and regulators) are on board but I haven't double checked them relative to each other.
Tapping into the I2C bus can be done directly above the keyscan matrix. SCL goes out to TP28 and SDA to TP29.
While the keypad scanner IC, the DAC, and the accellerometer all share the I2C bus, the PCB has 0Ω resistors bridging the bus to each device. This means that it's possible to isolate any of these devices from the bus. The two test points are the only feasible place to tap into the bus however, so it will be difficult to operate them in isolation at the same time. In testing, driving the reset pin of the SoC low keeps the bus quiet and the DAC's logic active.
I'm currently having spurious data coming in from the bus, but it may be due to the long test leads (~2 feet) that are in use. I'm making use of a Bus Pirate and will be using a Logic 8 as a secondary checker of truth when I visit my local hacker space. As all of the devices' registers are well documented, the importance here is somewhat lower.
The EEPROM is the only device to use the SPI bus. MOSI is TP36, MISO is TP39 and somehow clock is either not brought out at all or is hidden under the EEPROM.
There is one bi-directional I2S channel between the DAC and the SoC. This is strange magic and I don't understand it yet.
- P0_* control the I2S audio data being sent to/from the DAC
- P1_1 is sent to TP30 and connects to transitor Q2 to drive the infrared LED.
- P1_* control the various lines to the EEPROM.
- P2_1 is the debug data for in-circuit programming to TP53
- P2_2 is the debug clock for in-circuit programming to TP54
- P2_4 is sent to TP1 at the accelerometer. Analog value for acceleration.
- RESET_N is sent to TP51
GPIO control on pins COL 6, 7, and 8 drive the red, green and blue indicator LEDs above the microphone and are active high. COL 9 controls the keypad back lighting through Q1 on the opposite side of the board and is active low. While both the backlight and the indicator are enabled or disabled from the TCA8418, they are driven independently from an additional set of transisitors controlled from the SoC. This allows the fading in and out of either without having to write to the TCA8418. It does make me wonder why they ran the backlight to this chip at all though...
The ROW7 pin is not connected to any devices.
The interrupt line goes to one of the lower pins of P0 on the SoC. Because the SoC is so small I can't quite tell but it's between P0_0 and P0_2. Unfortunately this is not brought out to any test points I could find on the board.
Only the right audio channel is brought out from the DAC. It's put through an amplifier and sent off to the speaker and can be sampled from TP42.
The MICBIAS is run to the microphone.
The accelerometer outputs a value on TP1 when it's moved and corresponds to the interrupt pin INT1. The second interrupt INT2 comes out to TP26. There is a third test point, but I can't tell which trace it connects to. My best guess given where the trace is headed is CSB which on this chip is left floating while in I2C mode.
Because the footprint of accelerometers is shared amoungst different makes and models, I have to assume that this test point has some feature on a different chip. The footprint may also explain why there are many 0Ω jumper resistors as it may allow slightly different devices to be used without respinning the board.
The device supports multi-byte write to registers in the chip. For example, the DIR{A,B,C} registers are all written to with a single write when the remote boots to define the data direction of the various pins.
Because the interrupt routine on the remote is always active, the SoC should be held in reset and polling done to find the key presses. The device holds 10 events (press or release) in a stack which should be read from the beginning of the stack. The address auto-increment will be diabled here so multiple reads will pull and auto-decrement the internal pointer for this data. The linked document will have everything you need.
The chip seems to have an external enable line as it only shows up on the bus during startup. I'm not sure which pin is responsible, but if the SoC is held in reset the DAC is present on the I2C bus.
Without the master clock that is selectively provided by the main controller, no sound can be output from the device. This was tested by enabling the 'beep enable' bit in register 0x47.
The device is a fairly simple 8051-based microcontroller with a Zigbee radio. There are quite a few development Zigbee development devices around using this chip. For programming resources, I've found this page from Texas Instruments. If I can dump / reflash the firmware I could possibly provide the clocks needed for the DAC, but I'm not overly interested in learning the toolchain for this. There are quite a few tools on Texas Instruments' site for this microcontroller and it might be worth revisiting for some projects in the future. I find the idea of a mesh network on discarded remotes a fun idea.
According to this Universal Electronics page (OEM designers of this remote) the wireless networking is Zigbee RF4CE.
For programming, the data sheet calls out these pins and they are shown in the programming timings chart:
| Signal | Pin | Test Point |
|---|---|---|
| DEBUG_CLK | P2_2 | TP54 |
| DEBUG_DATA | P2_1 | TP53 |
| Reset | RESET_N | TP51 |
Fun, but I have no idea where TP52 went when they were numbering this. :)
Devices to program these chips seem fairly inexpensive on Chinese retail websites and it does show only three wires (RST, DD and DC) are required here. Bare chips can be had on DigiKey so for future projects that's definitely a good way to unlock the system.