## Patching the S1NN UHV Bluetooth Module This all started when I was helping a friend retrofit Bluetooth into his 2008 Passat R36. On paper, it should have been easy grab a BT module from the wreckers, plug it in, code it, done. But in reality the module flat-out refused to work with the steering wheel buttons, it displayed on the RNS510 and cluster, but no button presses registered no matter what coding I tried, everything looking fine on diagnostics, but no response. We quickly figured out why, the UHV module we got was a newer 5K0 kind (the type VW used from 2009-2014 made by S1NN). His R36 was still running the earlier steering wheel module that only sends 1 byte CAN messages for button presses. The UHV module expected 4 byte messages only. ![[No_paired_phone.png]] It seems like sometime between 2008 and 2009 VW updated the button press DLC to 4 bytes, the new format does keep the the "symbol" in the same location byte 0, but adds to the message format with a press time counter and variant id marker, these aren't overly important for accepting a phone call. The "official" solutions were - Hunt down an older 3C0 Nokia module (rare, expensive, and getting harder to find). - Or upgrade the steering wheel control module to a newer generation that speaks 4-byte. Both options, were time and money (Nokia units can sell for $200+) I already had a spare 5K0 unit sitting on my bench. So I opened it up. Inside I found a welcome surprise, a TI TMS470R1SF55 MCU and a standard TI 20-pin JTAG header footprint, this was all the invitation I needed. ![[UHV_JTAG_Soldered.png]] ## Dumping and Debugging I hooked it up with my normal combo, Olimex adaptor + OpenOCD, after soldering on the JTAG headers, dumped the firmware, and did a bit of live debugging while simulating CAN messages for both button types. It did not take long to find the issue, the firmware really was rejecting the 1-byte messages at the validation layer. And just like in my earlier [[TRW450 Reverse Engineering Writeup]] project, the patterns were familiar: TI TMS470 code, ARM7TDMI in big-endian, tables for DLC lengths, and CAN logic that followed what I had seen before. So I dropped the firmware into Ghidra, traced the routines, and memory I saw debugging and the fixes basically wrote themselves. ![[Decompiled_CANRX.png]]![[CAN_RX_Table.png]] ## The Patches **DLC Fix** - **Offset:** `0x85ce9` - **Change:** `0x04 → 0x01` This one is simple, it changes the `CanRxDataLen` entry for CAN ID `0x5C1` (steering wheel buttons). Now 1-byte DLC messages are accepted alongside 4-byte ones. **LSM Detection** - **Offset:** `0x539a3` - **Change:** `movne r0, #0x0 → movne r0, #0x3` This patch is only required if your SWCM does not support the "MFSW via LIN" coding. Instead of returning "nothing detected" when the LSM message does not contain the valid bytes, it now assumes both steering wheel and display are present. That ensures button presses always get routed somewhere. ## Checksums & ODX The next step was getting it back into a ODX file so it could be flashed with ODIS or VCP. The ODX format embeds the entire binary inside `<FLASHDATA>` tags, it has an internal CRC32 and an ODX CRC32_ADLATUS (these both use different polynomials and ones bit-flipped) Once both checksums formats were worked out, it was just a matter of repacking the ODX data with the patches and corrected checksums. --- ## Part Numbers and Families For context: - **Nokia HT-2/HT-3 (2006–2009)** `1K8-035-730`, `3C0-035-730`, `3C8-035-730` - Natively support both 1 and 4-byte DLC. Rare now. - **S1NN / Parrot CK5050+ (2009–2014)** `5K0-035-730`, `7P6-035-730` - Common, cheap, but limited to 4-byte DLC until patched. - **Novero HT-4/HT-5 (2010 onward)** `5N0-035-730`, `3C8-035-730-A` and later - Premium line, with rSAP, PBAP, A2DP, even Wi-Fi in later years. - **Others (Temic, Harman/Becker, etc.)** mostly Skoda/SEAT modules with mixed feature sets. If you want more info, the Ross-Tech [Telephone Retrofitting overview](https://wiki.ross-tech.com/wiki/index.php/Telephone_Retrofitting) has the best table of part numbers, suppliers, and supported profiles. --- ## Results After flashing the patched firmware: - B6/Mk5 wheel buttons with 1-byte messages fully functional - Later wheels with 4-byte messages are still functional The hardware is excellent for these units, they contain a Parrot CK5050+ module. At the time, this was a premium bit of Bluetooth hardware, high-end chipset, audio DSP, A2DP. The limitation was purely in firmware. --- ## Wrap-Up What started as a retrofit problem on a friend’s R36 ended up being a cool side project that will allow modern BT hardware in many cars. It’s worth adding that none of this was really S1NN's "fault" They would have built it exactly to the CAN matrix and test cases VW provided. The backwards-compatibility requirement for 1-byte messages simply never made it into the spec. And S1NN didn’t stay a "Bluetooth box" company for long. A few years after these UHV modules, they were working on full audio systems. In fact, they’re the team behind the original Tesla Model S/X premium sound package the ones that first carried the "Sound by S1NN" branding.