← Projects
flipper-zero intermediate 16 hr ago ◯ 4 min read

Build a Flipper Zero CAN Bus Diagnostic Tool with an MCP2515 Module

Build time: 3-4 hours
Tools needed: Soldering iron (for header pins, optional if your MCP2515 board is pre-populated), small Phillips screwdriver, computer with ufbt toolchain installed, USB cable
Parts List
flipper zerocan busmcp2515obd-iigpiocustom appufbtvehicle diagnosticshardware expansion

The Flipper Zero's SPI-capable GPIO header makes it a surprisingly capable host for an MCP2515 CAN bus controller — the same chip used in countless Arduino and ESP32 OBD-II projects. Wired up and paired with a small custom Flipper app, it becomes a pocket-sized CAN bus sniffer and diagnostic tool: something you can plug into a vehicle's OBD-II port, a 3D printer's CAN toolhead bus, or any other CAN network to passively log traffic, decode standard OBD-II PIDs, or inject test frames, all without a laptop. This project walks through the wiring, the firmware side, and building a minimal custom Flipper app with ufbt to read and display frames on the built-in screen.

How This Differs From a Generic ESP32 CAN Setup

MCP2515-over-SPI wiring for CAN bus work is well documented for Arduino and ESP32 hosts. What makes this project distinct is doing the same job from the Flipper Zero specifically: using its GPIO pins as the SPI host, building a dedicated ufbt-based app with the Flipper's GUI and button input instead of a serial monitor, and getting a genuinely portable, battery-powered, no-laptop-needed diagnostic tool that fits in a pocket. If you already have an ESP32 CAN rig on your bench, this project gives you the field-portable counterpart.

Safety Note Before You Start

Reading CAN bus traffic passively is safe and non-destructive. Transmitting frames onto a live vehicle's CAN bus is not something to do casually — modern vehicles use CAN for everything from the instrument cluster to steering and braking systems in some architectures, and malformed or unexpected frames can trigger fault codes or, in rare cases, unexpected behavior. Start in listen-only mode on any vehicle network. Save frame injection for a bench setup, a 3D printer toolhead bus, or a vehicle you're comfortable troubleshooting afterward — never a vehicle you depend on, and never while it's being driven.

Wiring the MCP2515 to the Flipper Zero GPIO

MCP2515 Module PinFlipper Zero GPIO PinFunction VCC3V3Power (confirm your module is 3.3V-tolerant — many breakout boards include a regulator and level shifting; the bare MCP2515 chip itself is 2.7–5.5V tolerant on logic, but check your specific board) GNDGNDGround CSGPIO (e.g. pin 2)SPI chip select SO (MISO)GPIO (e.g. pin 3)SPI data out from MCP2515 SI (MOSI)GPIO (e.g. pin 4)SPI data into MCP2515 SCKGPIO (e.g. pin 5)SPI clock INTGPIO (e.g. pin 6)Interrupt — signals when a new frame has arrived

Check the Flipper Zero's official GPIO pinout documentation for the exact pin numbering before wiring, since pin assignment in your app code has to match whatever physical pins you choose. Add a 120-ohm termination resistor across CAN-H and CAN-L if your module doesn't already include one and you're the only node on the bus segment — most vehicle OBD-II ports already have termination built into the vehicle's own bus, so don't double up resistors there.

Setting Up the ufbt Development Environment

  1. Install Python 3 and pip on your computer, then install ufbt with pip install ufbt.
  2. Run ufbt create APPID=can_sniffer in an empty project folder to scaffold a new custom Flipper app.
  3. Add an MCP2515 SPI driver to your app — you're writing C against the Flipper's furi/SPI HAL, so port the register-level init sequence (CNF1/CNF2/CNF3 bit timing registers, mode control) from any existing open MCP2515 driver rather than starting from the datasheet cold.
  4. Build and flash with ufbt launch while the Flipper is connected over USB — this compiles your app and pushes it straight to the device for testing.

Reading Standard OBD-II PIDs

Once your app can receive raw CAN frames, decoding standard OBD-II diagnostic data (engine RPM, coolant temperature, vehicle speed) means sending a request frame on CAN ID 0x7DF with the appropriate PID byte and parsing the response on 0x7E8. This is the same request/response pattern used by every generic OBD-II scan tool; the practical work is just formatting the eight-byte request frame correctly and parsing the padded response. Display the decoded values on the Flipper's screen using the standard Furi GUI canvas API, updated on each received frame via the INT pin's interrupt callback.

Practical Uses Beyond Vehicle Diagnostics

The same hardware and app work unmodified on any CAN bus, not just vehicles: Klipper CAN toolhead boards, industrial sensor networks, and any other CAN-based system you might need to sniff or troubleshoot in the field. Because it's running on battery power with no laptop required, it's genuinely useful for quick field checks — confirming a CAN bus is alive and terminated correctly, or capturing a burst of frames to analyze later — in situations where pulling out a full laptop and USB-CAN adapter is overkill.

This is a GPIO hardware-expansion project in the same spirit as other Flipper Zero add-on builds — it leans on the device's SPI-capable header and the ufbt toolchain rather than any exotic hardware, and the result is a genuinely pocket-sized CAN bus tool that didn't exist as an off-the-shelf product before Flipper's GPIO header made it this accessible.