FM Radio Upgrade Reverse Engineering

The Pip-Boy FM FM Radio upgrade module was an optional addon by by The Wand Company to their Pip-Boy 2000 Mk VI. I bought mine quite a few years ago now for £30 GBP but I’ve since seen them go for almost 10 times that on eBay which has kind of put me off hacking on mine given the scarcity of them.

That said, I’ve always been curious about the four exposed pads in a hole on one end—could I power it from them? Could I use the amplifier inside to play my own audio? Recently, I spoke with Richard at The Wand Company about the exposed pads on the FM Radio upgrade. He shared a picture showing how the modules are positioned for production testing, where I assume pogo pins make contact with the pads for automation of testing. This reignited my interest in hacking the module, so I took the bold step of cracking it open to uncover its secrets.

Hardware

I’ll be honest, I was really surprised by what I found inside, I thought this module would have been a relatively simple FM tuner with nothing too complicated going on inside, what I was not expecting to find was an Arm Cortex based microcontroller.

Integrated Circuits

The whole board is really well labelled but with no schematics we’ll need to reverse engineer a little bit to understand how this thing is put together. I started by writing down each IC reference and then using a combination of educated guesswork and some Google-fu to work out which parts were which, I’ve laid out the results of my guesswork below:

I2C Bus Exploration

So the one big initial question I had around this board was, what are those exposed pads, and diving inside the case I pretty quickly traced that these are wired back around to the main board to the pins marked up as SDA, SCL and V+, so these pads are actually I2C, not UART as I had previously assumed. On the other side of the main board, adjacent to the I2C hookup wires, there are pads labeled GND, RST, DIO, and CLK. Could these potentially be SPI, with RST likely being the usual STM32 reset pin. I’ll need to probe CLK and DIO with an oscilloscope to determine their purpose. They might be Serial Wire Debug (SWD), though I would have expected DIO to be labeled differently if that were the case—perhaps something more like SWDIO.

Anyway, now that I know the mystery pads are I2C, I soldered some short leads to a JST connector and plugged it up to a Raspberry Pi do some investigation. What is good to know though is that I can power the module this way, I’ve removed the 3x AAA batteries and now just power the module with 3.3V over V+. So anyway, what’s on that I2C bus?

Doing an i2cdetect I can see that there are two addresses appearing on the bus, there’s an 0x16 and an 0x63.

$ i2cdetect
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:                         -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- 16 -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- 63 -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

We’ll have to do some best guesses here again, my guesswork and some initial i2cdump’s suggests that 0x63 could be the FM radio, and 0x16 some kind of memory. The flash memory chip we identified earlier is an SPI connection according to the datasheet, so perhaps is not that, but it could just be something that’s being exposed by the STM32 instead. The FM radio datasheet suggests that the control interface to this IC is either 2-wire or 3-wire, I’m making the assumption that 2-wire is synonymous with I2C in this context and that’s what’s at address 0x63 but how can we find out for sure?

Who lives at address 0x63?

Taking another approach to work out what’s happening on the I2C bus I hooked up my scope and performed a few actions on the device to see what would trigger events. The first event was to simply boot the device and capture any activity. The below shows a snippet of that boot sequence:

But what does it mean? We can zoom a bit and start stepping through and attempting to decode some of the data.

Initially we can see something write to 0x63, the write contains the data 01 90 05 followed by a series of reads all containing 00 00 00 00 00 00 00 00. Then 60ms or so later there’s another block of writes, each of the writes are listed below:

W 12 00 00 01 01 C1
W 12 00 02 01 80 00
W 12 00 02 02 00 01
W 12 00 11 07 00 00
W 12 00 11 00 00 02
W 12 00 18 00 00 7F
W 12 00 40 00 00 32
W 12 00 11 08 00 32
W 12 00 12 01 00 0C
W 12 00 12 02 00 00
W 12 00 14 01 2A 30
W 12 00 14 00 22 2E
W 12 00 14 02 00 0A
W 12 00 14 03 00 03
W 12 00 14 04 00 0A
W 12 00 40 00 00 11

If this is the radio, the datasheet lists a command under 0x12 labeled SET_PROPERTY. Following that, there’s a byte always set to 0x00, and the next two bytes could represent the property being set. If that’s the case, it suggests the boot sequence configures a series of properties on the FM radio, which makes perfect sense.

Now, digging more into the datasheet it’s clear this is definitely the radio, the command structure in the datasheet is listed as:

CMD            0x12      SET_PROPERTY
ARG1           0x00
ARG2 (PROP)    0x??
ARG2 (PROP)    0x??
ARG3 (PROPD)   0x??
ARG5 (PROPD)   0x??
Status         -->0x80   Reply Status. Clear-to-send high

This perfectly matches up with the data we see on the scope of 6 bytes being written followed by 16 bytes being read where 0x80 being read indicates the clear-to-send (CTS) reply status. Now we’re relatively confident in what we’re looking at lets go over the captured data again and work out what is being sent on boot.

Boot Sequence

Tuning

I’m experimenting more with the device’s interactions. When a button is pressed to scan forwards or backwards, the radio tunes through FM channels. Monitoring the I2C bus during this process, I observe a write of 20 04, followed by periodic 14 writes every 50ms for approximately 3 seconds.

Scanning again over the datasheet we can see that the command 0x20 is FM_SEEK_START and the 0x04 sets the ARG WRAP which says it determines whether the seek should wrap or halt when it hits the band limit.

The subsequent calls to 0x14 are GET_INT_STATUS to which the docs state “…this command should be periodically called to monitor the STATUS byte”. In one example I got 0x80 which translates to a status of CTS, no ERR and nothing on the interrupts.

I also managed to catch a write to 22 01 which is an FM_TUNE_STATUS which queries that status of a previous FM_SEEK_START call, the arg of 0x01 here is an INTACK to that “if set, clears the seek/tune complete interrupt status indicator.” After the usual 0x80 CTS there’s 8 bytes of data 80 01 22 9C 14 03 00 01, for fun let’s see what that means:

So What?

You might wonder if all this exploration was pointless—what’s the purpose, and what’s the use? Well, we’ve now confirmed the exact FM radio chip in use and established that it’s controlled over I2C by the STM32. But here’s the big question: can I also control it?

The simplest test I could think of was this: can I turn it off? To try, I tuned the radio, turned up the volume so I could hear it clearly, and then used the Raspberry Pi connected to the I2C bus to send the command i2cset 0x63 0x11. Sure enough, it audibly clicked off!

So, what else can we query? There’s a command to retrieve the part number, chip revision, firmware version, patch revision, and component revision numbers. That could be extremely useful for pinpointing exactly what we’re dealing with:

$ i2cget 0x63 0x10 i 9
0x80 0x05 0x36 0x30 0x00 0x00 0x37 0x30 0x44

Interpreting the data from the datasheet, the last two digits of the part number are 05, which confirms our earlier assumption that this is an Si4705—neat! The firmware version is reported as v54.48.000, with the component revision listed as v55.48 and the chip revision as 68.

I also tested sending the command i2cset 0x63 0x21 0x04, which successfully triggered the radio to seek the next station, mimicking the functionality of the side buttons. After seeking, we can replicate the scope output we observed earlier and use the FM_TUNE_STATUS command to determine which station it tuned to:

$ i2cget 0x63 0x22 i 9
0x81 0x01 0x23 0x78 0x13 0x04 0x00 0x01 0x01

In this case, 90.8 MHz (according to a Google this could be BBC Radio 3 where I’m located), with a pretty poor signal, as expected again.

So who is device 0x16?

I will come back to that in a part 2, as I think this has already gone on quite long enough, thank you for reading if you got this far.