flash.pingequa.com

Appearance

Flashing glossary ​

Every term here is one you actually run into while flashing a board from a browser. Each entry gives the short definition first, then why it matters when something goes wrong.

Browser flashing ​

Web Serial API ​

The browser API that lets a web page talk to a USB serial device. It is what makes flashing from a web page possible at all — no installed tool, no driver bundle from us.

Available in Chrome and Edge 89+, Chrome on Android, and Firefox 151+ on desktop. Safari and every browser on iOS/iPadOS do not implement it, so they cannot flash. Two requirements catch people out: the page must be on HTTPS, and the port picker only opens in response to a click — a page cannot silently grab your serial ports.

See Web Serial is not supported.

esptool / esptool-js ​

esptool is Espressif's official command-line flashing tool. esptool-js is the JavaScript port that runs in the browser — it is what this site uses under the hood, so the same protocol and the same error messages you would see on the command line show up here too.

That is why searching an error string from this site often lands you in the espressif/esptool issue tracker: it is literally the same tool.

Download mode (boot mode) ​

The state an ESP32 has to be in before it will accept new firmware. On boot the chip samples GPIO0: held low, it enters the serial bootloader (download mode) instead of running your app.

Most boards enter it automatically. When automatic entry fails you hold BOOT (GPIO0), tap RESET, then release BOOT. If the chip is not in download mode, flashing fails with a connection error rather than a clear "wrong mode" message.

See enter download mode for verified per-board sequences, and wrong boot mode detected.

DTR and RTS ​

Two control lines on a USB-serial adapter that boards wire to the ESP32's reset and boot pins so software can enter download mode without you pressing anything.

esptool's mapping is DTR → GPIO0 and RTS → EN (CHIP_PU, reset), both active low. Auto-reset fails when a board does not wire these lines through, wires them differently, or omits the 1 µF–10 µF capacitor between EN and GND that Espressif's reference circuit uses. That is the usual reason a third-party board needs the manual BOOT/RESET dance while an official devkit does not.

Flash offset ​

The byte address in the chip's flash where an image is written — 0x0, 0x1000, 0x8000, 0x10000 and so on. A firmware release is usually several images, each with its own offset.

Offsets are not guessable. They differ by chip family (an ESP32-S3 bootloader does not live where an ESP32 one does) and by how a firmware was built. Writing an image to the wrong offset is one of the few ways to genuinely break a board from a browser. This is why this site ships a verified offset set per device rather than letting you type one in.

Bootloader and partition table ​

The bootloader is the small image that runs first and starts your firmware. The partition table tells it how flash is carved up — app, filesystem, NVS, OTA slots.

They matter for flashing because they are separate images at separate offsets: a firmware zip that contains only the app image will not boot a blank board, and a partition table that disagrees with the app produces a board that flashes cleanly and then boot-loops.

CH340, CP2102, CH9102 ​

The USB-to-serial bridge chips found on most dev boards. They are what your OS sees as a serial port; the ESP32 itself is behind them.

Which one your board uses decides whether you need a driver. Some newer ESP32s (S2, S3, C3, C6) have native USB and no bridge chip at all, so they appear as a serial device with no driver.

See USB serial drivers.

Radios and modules ​

Sub-GHz ​

Radio work below 1 GHz — the 315 / 433 / 868 / 915 MHz ISM bands used by garage remotes, doorbells, sensors and key fobs. A plain ESP32 has no Sub-GHz radio, so Sub-GHz features in any ESP32 firmware require an add-on transceiver.

CC1101 ​

Texas Instruments' low-power Sub-1 GHz transceiver, the usual add-on for Sub-GHz work on ESP32 boards. Per TI it covers 300–348 MHz, 387–464 MHz and 779–928 MHz, with 2-FSK, 4-FSK, GFSK, MSK, OOK and ASK modulation at 0.6–600 kbps.

Some boards have one built in (the T-Embed CC1101 variant); on the rest it is a module you wire to the SPI bus. If a firmware's Sub-GHz menu is present but does nothing, this chip is usually what is missing.

nRF24 (nRF24L01+) ​

Nordic Semiconductor's 2.4 GHz transceiver, used for 2.4 GHz protocol work. It operates in the 2.400–2.4835 GHz ISM band at 250 kbps, 1 Mbps or 2 Mbps.

It is a separate radio from the ESP32's own Wi-Fi — adding one does not extend Wi-Fi range or capability, it gives access to a different set of 2.4 GHz protocols.

RTL8720DN (BW16) ​

The Realtek dual-band wireless SoC on the BW16 module — 2.4 GHz and 5 GHz Wi-Fi (802.11 a/b/g/n) plus BLE 5.0.

It matters for one reason: the common ESP32 chips — the original ESP32, S2, S3, C3 and C6 — have no 5 GHz radio, so their firmware (Marauder, Bruce and the rest) can't work on 5 GHz. Espressif's newer ESP32-C5 does add a 5 GHz radio, and this site flashes C5 boards too — but that is a separate chip. The RTL8720DN puts dual-band Wi-Fi plus BLE 5.0 on the one BW16 module, which is what 5Ghost on the BW16 uses.

Note that a BW16 is not flashed with esptool — it is a Realtek part with its own bootloader and protocol.

ESP32 variants (S2, S3, C3, C5, C6) ​

Not one chip but a family, and the differences bite when flashing. The original ESP32 is Xtensa dual-core with 2.4 GHz Wi-Fi. The S2 and S3 are Xtensa with native USB. The C-series is RISC-V — and the ESP32-C5 is the first with a dual-band 2.4 + 5 GHz radio.

They do not share bootloader offsets or, in some cases, download-mode behaviour. A firmware built for one will not run on another.

Firmware terms ​

brucePins ​

Bruce's pin-configuration data — which GPIOs your CC1101 or nRF24 module is wired to. Bruce cannot guess your wiring, so without it RF features have nothing to talk to even with the module attached.

On supported device pages this site writes the configuration over the serial link right after flashing, so you do not have to type it into the device by hand.

FAP (Flipper Application Package) ​

A Flipper Zero application file (.fap) — an app installed onto the Flipper's SD card, not a firmware replacement. Installing one does not change the firmware and cannot brick the device.

This is the difference between the companion app pages (which install a .fap) and Flipper custom firmware (which replaces the firmware).

Custom firmware (CFW) ​

A community-maintained replacement for a device's official firmware — Momentum, Unleashed and RogueMaster for the Flipper Zero; Bruce, Marauder, GhostESP for ESP32 boards.

For the Flipper, all three main options are GPL-3.0 forks of the official firmware and are installed the same way. See which firmware should I flash?.

Evil portal ​

A captive-portal page served by the board to devices that connect to its Wi-Fi network — the "sign in to continue" screen pattern. A standard feature across ESP32 security firmware, and one that is only lawful to run against networks and people you have permission to test.

Deauthentication (deauth) ​

A management frame that tells a Wi-Fi client to disconnect. In the original 802.11 design these frames are unauthenticated, which is what makes deauth tooling possible at all.

Protected Management Frames (PMF/802.11w), mandatory in WPA3, are designed to stop exactly this — so results against a modern network are often not what older tutorials describe.

Wardriving ​

Mapping wireless networks by moving around with a receiver and logging what it sees, usually with GPS so each observation has a location. What the Scout Lite is built for.

Board shorthand ​

CYD (Cheap Yellow Display) ​

Community nickname for the ESP32-2432S028 — a cheap ESP32 board with a built-in touchscreen, and by extension a family of similar boards with different screen sizes and USB layouts.

The variants matter when flashing: they differ in USB bridge chip and display driver, so "the CYD" is really several boards. See the CYD page.

Bricked ​

A board that will no longer boot or accept firmware. Worth being precise about, because most "bricked" boards are not: if a board still enters download mode, it can be re-flashed, and recovery is the same operation as a normal flash.

Genuinely unrecoverable states are rare from browser flashing, since it uses the chip's own ROM bootloader — which lives in read-only memory and cannot be overwritten.

Sources ​

Checked 2026-07-25.

For educational and lawful testing only. Comply with the laws that apply where you are.

Last updated:

Released under the MIT License.

© 2026 PINGEQUA