More than you ever wanted to know about the MULF2 High Basis BMW Module
Being out in LA, I recently bought a car – I ended up with a used BMW. It’s pretty sweet, but I’m me so obviously I’ve moded just about everything I can without actually buying parts. Mostly that means software mods – windows up on key fob lock press, that sort of thing. But I’ve also been trying to mod bluetooth into it, and only recently had success. Tonight I got curious and took the module which controls bluetooth and USB aux-in apart (referred to as a MULF2 High Basis, it lives in the trunk and connects to a USB plug in the center console). Here’s what I found.
TOP SIDE: Not much interesting, mostly glue logic.
MOST bus interface controller
Hex Schmidt Trigger (glue logic)
Octal buffer (glue logic)
PCI USB 2.0 Host Controller
This one’s interesting in that it’s a full-fledged host controller like you’d find in your PC – it advertises compatibility with built-in OS drivers in Linux and Windows. It suggests that the board is probably running some kind of embedded Linux, which makes lots of sense. Interestingly, it looks like the chip has both 2x USB1.0/1.1 controllers and a separate USB2.0 controller, with two transceivers (physical ports on the chip) for them to connect to. So you can be running 2x 1.1 ports or 1x 1.1 and 1×2.0, for example. If I had to guess, the controller is running 1 and 1, with the USB2.0 dedicated to the center console port, and the USB 1.1 going to the on-board bluetooth controller (see below).
500k Gate Spartan 3E automotive FPGA
Not especially surprising – if I had to guess, they’re using it to implement a MOST PCI controller or something like that. Really, it could be anything or a bunch of things, though.
Renesas SH7780 (R8A7780)
400MHz 32-bit CPU with 32-bit PCI bus
This isn’t especially interesting. Just some generic RISC CPU. But it probably has the horsepower to run a stripped-down embedded linux. More likely, it’s actually not, though, it’s probably running a lighter-weight RTOS.
Definitely DRAM or SRAM of some kind (running memory for the CPU)
Unfortunately, I can’t find any info on size or anything. If it’s big DRAM, that probably means the board runs embedded linux. If it’s smaller, probably a more compact RTOS. Tough to say – the 512mbit flash is definitely program memory (the SH7780 has none), and 512Mbit (64MB) is big enough for a compact embedded linux.
It’s interesting, I’m not really sure what the unpopulated BGA (ball-grid array) below the flash would have been. It doesn’t look like a spot for another RAM or flash chip, which would have been pretty expected (use free space on your PCB to add more ram, then if the programmers can optomize the software enough, just stop populating one chip to save a couple bucks a unit).
Bluetooth 2.0+EDR USB 1.1 Slave
This chip runs the Bluetooth show. Basically, it’s a USB1.1 Bluetooth dongle plugged into the computer that runs on the rest of the board. Via software in the chip, you can choose to implement whatever profiles you want supported by the Bluetooth 2.0+EDR spec, including Handsfree (as they’ve done) and probably A2DP too (wonder why they haven’t?). It could be that the rest of the computer is too slow to handle A2DP, or that streaming the audio data from the chip requires a USB2.0 port (the only one of which I can only presume is occupied by the center console port). Curious either way why the hardware should theoretically support bluetooth streaming, but they’ve seemingly omitted the capability.
BONUS: I forgot to write the number of the chip on the top right. Initially I thought it might be an audio DAC, but maybe or maybe not. After USB and MOST, there are 6 wires going into the MULF – the big ones are pretty clearly +12V and electrical ground. That leaves 4. They could be l/r/ground/something, but I think not. I think they’re CAN-HI, CAN-LOW, CAN-V+ and CAN-GND for diagnostic/vehicle bus communication. Most people tend to think diagnostics for the MULF are over the MOST port, and there’s a MOST-CAN bridge somewhere in the dash, but I’d still bet anything those 4 are CAN for basic control (the vehicle is on, do your thing, etc).
If that’s true and no analog audio out happens in the MULF, I’m not sure why they didn’t simply implement A2DP. It’d have been easy enough. And now that I think of it, the chip is probably an audio ADC for microphone input, since that IS wired into the MULF. Maybe I’ll go pull mine apart again and probe it, now I’m curious.