Native firmware patch that makes the Ford Convers+ instrument cluster display Bluetooth audio track title & artist — the same way it already does for USB.
The Convers+ cluster (MCU: NXP MAC7116) shows track metadata for USB and CD sources, but the Bluetooth Audio screen stays blank because the firmware never processes the BT metadata CAN messages. This project adds that missing piece natively in firmware — no external CAN bridge, no extra hardware, no companion app.
- ✅ Bluetooth track title and artist now appear on the BT Audio screen
- ✅ Reuses the cluster's own, already-working media text pipeline (the USB path)
- ✅ Up to 19 characters per field — which is exactly the Bluetooth module's own maximum (see Limitations)
- ✅ Robust: oversized or malformed metadata from the phone/BT module cannot overflow anything or crash the cluster
- ✅ Ships as patch scripts only — you patch your own firmware dump; no Ford binaries are redistributed
Tested on: Ford Mondeo MK4 facelift (FL), model years 2011+ — Convers+ cluster, firmware 1412-FL, VBF partition
CS7T-14C026-CD. Other cars/versions that use the same Convers+ cluster may work, but are currently unverified (see Compatibility).
Patched cluster on a Ford Mondeo MK4 FL — the BT Audio screen now shows the live track title ("Stars Will Align") and artist ("Kygo, Imagine Dragons") streamed over Bluetooth.
This modifies the firmware of a safety-related vehicle component. You do this entirely at your own risk.
- Bricking is a real possibility. A bad flash can leave your instrument cluster unbootable. Recovery may require JTAG/BDM hardware and is not guaranteed.
- You will likely void your warranty and may violate the terms of your vehicle's software.
- Always keep a verified, complete backup of your original firmware and EEPROM before flashing anything. Store it somewhere safe.
- Your firmware dump contains your VIN and other vehicle data — never upload it publicly.
- This is not affiliated with, endorsed by, or supported by Ford. "Ford" and "Convers+" are used only to identify the target hardware.
- The authors accept no liability for any damage, loss, or injury. If you are not comfortable reading a disassembler and recovering a bricked ECU, do not proceed.
If any of the above scares you — good. Stop here.
| Item | Value |
|---|---|
| Confirmed vehicle | Ford Mondeo MK4 facelift (FL), 2011+ |
| Cluster | Ford Convers+ IPC |
| MCU | NXP MAC7116 (ARM7TDMI-S, Thumb, big-endian, ARMv4T) |
| Firmware base | 0x5000 |
| Confirmed firmware | 1412-FL, VBF partition CS7T-14C026-CD |
| Head unit (confirmed car) | Blaupunkt MCA, with a discrete Bluetooth module (C7ST-14D212) that puts the metadata on the CAN bus |
| Other vehicles / versions | Untested. Other Fords using the same Convers+ cluster may work. The patch is cluster-side, so what matters is that some module (a discrete BT module and/or the head unit) broadcasts the metadata on the bus — and on which ID (see TESTING.md; use --canid if it differs). The patch scripts verify the exact bytes they expect at each hook site and abort if they don't match, so they will refuse to patch an incompatible image rather than corrupt it. |
If you have a different firmware version and the scripts abort, please open an issue with your version string — the offsets can usually be ported.
Bluetooth sends track metadata over CAN ID 4B1 (source byte 0x12), as ISO-TP text frames in the format [field][source][01][01][text]. Stock firmware treats 4B1 as a dead 2-byte "signal" and throws the text away.
The patch installs a small code cave hooked into the CAN receive path (before the message is dispatched by type), which:
- reads the raw FlexCAN mailbox and filters for CAN ID
4B1, - reassembles the ISO-TP payload (First / Consecutive / Single frames),
- feeds the completed text into the same media dispatcher the USB path uses, which writes it to the Bluetooth metadata store the screen already reads.
A second, tiny patch to the BT Audio screen renderer relocates one string buffer so title and artist can each be up to 19 characters without one overwriting the other.
Full technical write-up: docs/HOW_IT_WORKS.md.
- Python 3.8+
- A way to read and write your cluster's firmware (e.g. via the bootloader / a VBF flasher). This project does not flash for you — it only produces the patched image.
- Optional, for verifying/experimenting: Capstone (
pip install capstone) and Unicorn (pip install unicorn) if you want to disassemble or emulate.
Community resources for dumping and flashing Convers+ clusters can be found on the microhacker forum.
All commands take explicit file paths. Nothing is committed to this repo — you work on your own dump locally (see
.gitignore).
0. Back up first. Dump your firmware and EEPROM and keep verified copies.
1. Extract the code partition from your firmware image (the 0x5000-based program image). If your dump already is that image, use it directly as main.bin.
2. Apply the CAN patch (BT metadata → media store):
python tools/apply_patch_v3.py main.bin main_patched.binThe script prints the hook it found and asserts it matches before writing. If it aborts with a mismatch, your firmware version differs — stop and open an issue.
3. Apply the renderer patch (19-character fields):
python tools/apply_render.py main_patched.bin main_patched.bin4. Repack into a flashable VBF, using your original VBF as the template (keeps the correct part number, address and CRCs):
python tools/vbf_tool.py pack original.vbf main_patched.bin main_patched.vbf5. Flash main_patched.vbf with your usual tool, then play a Bluetooth track and open the BT Audio screen.
- 19 characters max per field — and this is not our limit, it's the Bluetooth module's. The module truncates every field to 19 characters at the source, before it ever transmits over CAN, so no firmware change on the cluster side can show more (the extra characters never leave the phone/BT module). 19 also happens to be the cluster architecture's own ceiling (the stock field handler and buffers cap there), so the two limits line up perfectly.
- The
~truncation marker, and why 18 vs 19 barely matters. When a title/artist is longer than the module allows, the Bluetooth module sends the first 18 characters followed by a~(0x7E) as the 19th, meaning "there's more." The cluster stores that~but does not render the glyph — it's simply ignored on screen — so e.g. "Turn the lights off (remix)" shows as "Turn the lights of" (18 characters). A real 19th character is therefore only ever visible when a title is exactly 19 characters long; for anything longer the 19th slot is the module's~, which isn't drawn. So the 18→19 change is, in practice, marginal — it only recovers that exact-19 edge case. - Handles
4B1only (not4B0). The two carry the same text but interleave at the frame level; processing both corrupts the shared reassembly buffer.4B1alone is complete. - Robust against bad input. The reassembly is bounded by a single clamp plus a per-frame guard, so oversized (even 250-char), unterminated, orphaned or garbage frames from the BT module are safely truncated or ignored — they cannot overflow the scratch buffer, corrupt neighbouring fields, or crash the cluster. See HOW_IT_WORKS.md §11.
- Album is reassembled too, but many clusters don't show an album field on the BT screen.
- Tested on one firmware variant (see Compatibility).
tools/
apply_patch_v3.py CAN 4B1 → media store code cave (hook @0x236f6, cave @0x83240)
apply_render.py BT Audio renderer patch (relocates the title buffer)
vbf_tool.py VBF pack/unpack (CRC16-CCITT + CRC32)
make_test_frames.py generate/send CAN 0x4B1 test frames to verify the cluster
emulate.py run the patch on your own dump in an emulator (no car needed)
docs/
HOW_IT_WORKS.md full reverse-engineering write-up
FLASHING.md dump → patch → pack → flash walkthrough
TESTING.md prove the patch works by injecting known 0x4B1 frames
Start with no hardware at all. You can run the patch on your own firmware dump in an emulator and watch a simulated Bluetooth track make it all the way to the BT Audio display — no car, no CAN adapter:
pip install unicorn
python tools/emulate.py --dump main.binIt patches a throw-away copy exactly the way you'd flash it, injects a 0x4B1 metadata frame, runs the real cluster code, and tells you in plain language whether the title/artist reached the screen — and whether your firmware version is even supported. See docs/TESTING.md → emulator.
Then, on the bench or in the car: the patch displays only what arrives on the bus as CAN 0x4B1. Before assuming the flash failed, inject known test frames to check the cluster side independently — see docs/TESTING.md. If an injected title shows up, the patch is fine and the issue is that your Bluetooth source isn't broadcasting 0x4B1.
Different head units use different IDs. Some units (e.g. a Blaupunkt MCA) put Bluetooth metadata on a different CAN ID than 0x4B1. If a bus capture shows your metadata on another ID, you can retarget the patch with the experimental --canid option — see docs/TESTING.md → different CAN ID.
Issues and PRs welcome — especially ports to other firmware versions (please include your version string and the bytes the scripts report). Please never attach firmware dumps or VBF files to issues; they contain Ford code and your VIN.
MIT © 2026 andrzejogh
Not affiliated with Ford Motor Company. Trademarks belong to their respective owners.