ESP Flasher for Flipper Zero: reflashing an ESP chip from the device

Flashing from the handheld rather than from a laptop

The premise of this app is that you should not need a computer to write firmware to an ESP chip. The Flipper Zero already has a serial port exposed on its GPIO pins, a screen to drive a menu, and a way to run small native applications, so the logic is that the Flipper itself can be the programmer. The project is written in C and relies on Espressif's esp-serial-flasher library for the actual protocol, which is the same code the Espressif tooling uses, so the flashing itself is not a reimplementation. The hardware requirement is modest but specific: an ESP chip wired to the Flipper's UART pins, and the README points to an ESP pinout and wiring reference on another Flipper GPIO repository for the connection details. A Wi-Fi devboard is the example given. The value of the approach is a bench workflow where the target board stays attached to the Flipper and the firmware cycle does not involve a second device.

The chip list the app covers

The README lists the supported targets explicitly, and the list covers the current Espressif line fairly completely:

Supported targets: ESP32
ESP8266
ESP32-S2
ESP32-S3
ESP32-C3
ESP32-C2
ESP32-H2

Two things are worth reading off that list. The ESP8266 is still there, which matters because it is the part most commonly found in older devboards and cheap modules, and the C series and the H2 are included, so the app is not limited to the mainstream S3 part. What the list does not include is anything outside the Espressif family, so the app is an ESP flasher rather than a general purpose programmer. The repository layout backs up the C implementation. The sources are named by role rather than by module, with `esp_flasher_app.c` and its headers for the application and GUI, `esp_flasher_uart.c` for the serial transport, and `esp_flasher_worker.c` for the work that runs outside the UI thread. There is a `file/` directory for file handling, `scenes/` for the GUI screens, `assets/` and `screenshots/` for resources, a `docs/` directory, and a `lib/` directory that holds the vendored serial flasher library alongside a `.gitmodules` file.

Getting the app onto the device

There is no package manager route, so installation is a manual file copy, and the README is explicit about the steps. First you must be logged in to a GitHub account, because otherwise the downloads in the next step do not work. Then you navigate to the FAP Build GitHub Actions workflow, select the most recent run and scroll down to the artifacts. The FAP is built for the `dev` and `release` channels of both official and unleashed firmware, so you download the artifact matching your firmware version. You then extract `esp_flasher.fap` from the downloaded ZIP and copy it to the Flipper Zero SD card, preferably under Apps/GPIO alongside the other GPIO apps. The README adds a practical note about qFlipper: if you are using it to transfer files you need to extract the ZIP content to your computer first, because qFlipper does not support dragging directly from a ZIP file, at least on Windows. For developers, the README says you can also build the app yourself from a local clone using ufbt.

A worked example and the boot mode dance

The usage guide, credited to @francis2054, walks through flashing a specific firmware as the example, and it is worth reading for the shape of the flow rather than the specific target. You download the files the board needs, which for the Wi-Fi Devboard means three of them: the `0x1000` bootloader, the `0x8000` partition table and the `0x10000` firmware, with the boot app noted as not needed for that method. You put them in a folder, rename the firmware file to `Firmware.bin`, and copy them into the `esp_flasher` folder inside `apps_data` on the SD card, with an SD card adapter preferred over qFlipper for the transfer. Then you plug the devboard into the Flipper and put the chip into its bootloader mode, which the guide describes as holding the boot button while pressing reset once and releasing boot after two seconds. In the app, under Apps then GPIO, you choose Flash ESP, pick the bootloader, partition table and firmware entries, and press the flash control.

The firmware mismatch warning and the retry path

The documentation is unusually candid about failure modes, and one in particular. If the Flipper firmware you are running does not match the files you have downloaded, you may get an API mismatch error, and the app suggests trying Continue anyway, while noting that otherwise the app needs to be rebuilt or you might need to update the firmware on the Flipper. That is the direct consequence of the app depending on a specific firmware API. A second failure mode is documented in the flow itself: if you get errors during the flash, press the back button once and repeat the boot mode step and try the flash again, which points at a reset state on the target chip rather than a data problem. There is also a top level instruction to use the app at your own risk, with the reason given plainly: the app hardcodes addresses for ESP chips. That is the central engineering trade-off in this project, and it is a real one. A hardcoded address table is fast and simple, and it is also bound to a specific chip and a specific memory layout, so a chip variant with a different flash map is where this design would break.

Where this tool is the wrong choice

The boundaries are narrow but clear. The first is scope of hardware. Only the Espressif parts listed are supported, so a project that also uses an STM32, an RP2040 or a bare ATtiny has no use for this app and would need a different tool entirely. The second is direction. The app writes flash. There is no documented read, verify or dump operation, so if your task is to check what is currently on a chip, to back it up before flashing, or to confirm the write succeeded by reading it back, this is not the tool. The third is the trust model. The application is a community built FAP that you install by extracting a file from a GitHub Actions artifact, on a device where you may store other credentials and keys, and the project asks you to run it at your own risk. The fourth is maintenance momentum. The last push was on 2026-05-06, the newest tag is v1.7 from 2025-08-20, and the previous releases were v1.6 in August 2024 and v1.5 in February 2024, so the release cadence has slowed considerably. That is fine for a settled tool, and it is a reason to check the build status before you rely on it.

Editorial conclusion

The ESP Flasher app fits a Flipper Zero user who works with ESP based boards on the bench and wants to reflash them without pulling a USB cable and a host tool into the loop, which is convenient when the device is already wired to the target board. It is the wrong choice if you need to flash other chip families, if you want to read or verify a flash rather than write one, or if you are unwilling to run a community built app on your device. Before you use it, check that the FAP build you download matches the firmware channel of your Flipper, and read the warning about hardcoded addresses, because a mismatch between firmware and app is the documented failure mode. The last push was on 2026-05-06, the newest release is v1.7 from 2025-08-20, and the code is GPL-3.0 licensed.

Frequently asked questions

Official sources

1. 0xchocolate/flipperzero-esp-flasher on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases