NerdMiner – Partition Table Corrupt

Cold power-cycle for 60 full seconds. Unplug USB completely (not a hub power switch — full disconnect at the host). Wait. Plug back in to a known-good data USB port on a laptop or desktop, not a bus-powered hub. Some interrupted-OTA states auto-recover on a clean cold boot via the ESP-IDF rollback mechanism, which falls back to the previous valid OTA slot. If the QR code paints or the `NerdMinerAP_XXXXXX` SSID broadcasts, you are recovered for now — but read step 2 before flashing anything new.

Open `bitmaker-hub.github.io/diyflasher` in Chrome, Edge, or Brave. Firefox and Safari do not implement WebSerial — they will refuse to connect. Click Connect, pick the serial port that appears. In the variant dropdown, pick the entry that exactly matches your hardware silkscreen (T-Dongle-S3, T-Display S3, NerdMiner-S3, ESP32_ST7735). Tick the Erase Flash checkbox if available — this prevents stale partition data from layering under the new write.

Flash one of the latest stable releases — but verify against the issue tracker first. Open the BitMaker-hub/NerdMiner_v2 releases page. Skim recent Issues for `partition` or `CRC` filed against the version you are about to flash. If recent reports flag a version, drop one minor release back. Click Install in the diyflasher and watch the progress bar. Takes 60-180 seconds. The ESP-S3 reboots automatically at the end.

Watch the serial monitor for the boot banner during the post-flash reboot. Open a serial monitor at `115200` baud. A clean boot shows: `ESP-ROM:esp32s3-20210327`, then `Build:Mar 27 2021`, then a partition table summary listing `nvs`, `otadata`, `app0`, `app1`, `spiffs`, then the app starting. If you see all of that, you are recovered — proceed to WiFi/pool config in step 9. If the CRC mismatch error returns, escalate to Tier 2.

Check Bitmaker-hub Discord and Facebook group for confirmed partition-table-corrupt reports against your specific firmware version. Half the time someone has filed an issue and a workaround `partitions.csv` is already pinned. Save that file locally. Community-pinned workarounds usually predate the upstream fix by weeks and are the fastest route to a working board if your variant is hit by a known-bad release.

Install Python 3 and `esptool` on your laptop. On Windows, download from python.org and tick `Add Python to PATH` during install. On macOS use `brew install python3`. On Linux it is preinstalled on most distros. Then `pip install --upgrade esptool`. Verify with `esptool.py version` — you want 4.7.0 or newer for full ESP32-S3 support. Older versions miss the `--chip esp32s3` flag entirely and silently mis-detect the chip.

Force ROM bootloader entry. Unplug USB. Press and hold the BOOT (or IO0) button on the board — labelled `BOOT` on most LILYGO boards, sometimes `IO0` on generic kits. While holding, plug USB back in. Hold 3 full seconds after plug-in, then release. The ESP-S3 mask-ROM (burned at the Espressif foundry, impossible to corrupt) responds on serial as `waiting for download` — quiet, NOT the CRC-fail boot-loop banner. On stubborn LILYGO boards, also pulse `EN` to GND while holding `IO0` (documented LILYGO quirk per Meshtastic issue #3430).

Run full `erase_flash`. Command: `esptool.py --chip esp32s3 --port COMx --baud 460800 erase_flash`. Substitute `esp32` for `esp32s3` if you have an ESP32-WROOM original (4 MB). Substitute `COMx` for your actual port. Takes 15-45 seconds. Wipes bootloader at `0x0`, partition table at `0x8000`, both OTA slots, NVS, PHY init, SPIFFS — everything. The mask-ROM is in silicon and is not touched. This single command resolves root causes #1, #2, #4 in one shot.

Download the matched factory bundle. Open the BitMaker-hub/NerdMiner_v2 releases page. Download the ZIP for your exact variant for the version you want to install. Extract. Verify three files are present: `bootloader.bin`, `partitions.bin`, and `firmware.bin` (or a combined `nerdminer-<variant>-vX.Y.Z.bin`). All three must come from the same release ZIP. Mixing versions across these three files is root cause #3 and will reproduce the CRC failure on first boot.

Flash all three at canonical addresses in one command. Re-do step 7 if the chip exited ROM mode after `erase_flash`. Then run: `esptool.py --chip esp32s3 --port COMx --baud 460800 --before default_reset --after hard_reset write_flash -z --flash_mode dio --flash_freq 80m --flash_size detect 0x0 bootloader.bin 0x8000 partitions.bin 0x10000 firmware.bin`. Watch for `Hash of data verified.` after each file — that means the post-write read-back matches what was written. If any file reports a hash mismatch, the SPI flash sector for that address is suspect — escalate to Tier 3 forensics.

Forensically dump and validate the existing partition table BEFORE you re-flash, if you want to know which root cause hit you. Capture: `esptool.py --chip esp32s3 --port COMx --baud 460800 read_flash 0x8000 0xC00 part_dump.bin`. Run twice with 10 seconds between attempts. Diff with `fc /b part_dump.bin part_dump2.bin` (Windows) or `cmp` (Linux/Mac). Identical = stable but corrupt content (root causes 2, 3, 4, or 5). Different bytes between reads = SPI flash sector at `0x8000` is worn — Tier 4. Then `python gen_esp32part.py part_dump.bin part_dump.csv` — if that errors with `CRC32 mismatch` or `invalid magic byte`, confirmed corrupt table.

Generate a known-good partition table from the matching `partitions.csv`. From a fresh `git clone https://github.com/BitMaker-hub/NerdMiner_v2`, copy the `partitions.csv` for your exact variant (look in the variant's `boards/` or `partitions/` subdirectory — file names like `partitions_8MB.csv` or `partitions_16MB.csv`). Run `python gen_esp32part.py partitions.csv partitions.bin`. The output `partitions.bin` is exactly 3072 bytes (`0xC00`). Any other size means your `partitions.csv` is wrong — fewer or more entries than expected, or malformed line endings. Fix the CSV, regenerate.

Flash the regenerated partition table by itself if you want to isolate the fix. With the chip in ROM mode: `esptool.py --chip esp32s3 --port COMx write_flash 0x8000 partitions.bin`. Then power-cycle. Watch the serial monitor — you should see the second-stage bootloader successfully read and parse the new table. A `No bootable app partitions` message after this confirms the table is valid but the app slots are still empty — go back to step 10 to flash `bootloader.bin` and `firmware.bin` at their canonical addresses.

UART-level fallback when the on-board USB connector is dead. Solder or clip a 3.3V USB-to-UART adapter (FT232RL or CP2102 on a 3.3V breakout) to the ESP32-S3 `TX0` / `RX0` / `GND` / `EN` / `IO0` test pads — adapter TX to board RX, adapter RX to board TX, common GND. Power the NerdMiner from its normal USB; do NOT backfeed 5V from the UART adapter. Short `IO0` to GND, pulse `EN` to GND for hardware reset, release `EN` first then `IO0`. Run all `esptool.py` commands against the new UART COM port at `--baud 230400` — high baud silently corrupts on flying-lead signal integrity.

Brownout-safe re-flash from a known-stable power source. If steps 8-10 keep producing CRC fails on first boot, the original flash session was likely brownout-corrupted (root cause #4). Move the NerdMiner to a powered USB-3 hub or a desktop chassis port. Use a thick (>=22 AWG conductors), short (<=30 cm) USB-C data cable. Repeat steps 7-10 at `--baud 115200` instead of `460800` — slower writes are far more brownout-tolerant if you cannot improve the power source. A laptop on AC power is mandatory.

Stop DIY and ship to D-Central if: forensic step 11 confirms SPI flash sector wear (different reads at the same address), `esptool.py chip_id` still fails after the manual BOOT+EN dance with fresh cables and fresh host, `espefuse.py summary` shows burned `FLASH_CRYPT_CNT` or `SECURE_BOOT_EN = 1`, the on-board USB-C connector pads are torn off the PCB and you do not own a fine-tip iron, the ESP32-S3 module is visibly scorched / cracked / swollen, or your own hot-air reflow attempt moved or partially lifted the module. D-Central stocks all five NerdMiner variants and bench fixtures pre-loaded with every factory firmware.

What D-Central does at the bench: re-runs the full UART recovery on a known-good 3.3V harness with a scope on the USB enumeration. If UART also fails, hot-airs the SPI flash chip (preheat 150 C, top-side 320-340 C, ~30 s) and replaces it with a fresh pre-programmed unit carrying the matched bootloader + partition table + firmware for your variant. For sector-wear cases on cheap clone modules, swaps the entire ESP32-S3 module — faster and more reliable than chasing flash. Burn-in for 30 minutes against `solo.ckpool.org` to verify hashrate before shipping back.

Ship safely to D-Central. ESD bag inside a padded mailer or small rigid box. NerdMiners are physically small and survive light shipping but the USB connectors are fragile. Include the cable and power source you were using (rules them out as cause), plus a written note: firmware version flashed, variant picked, exact serial-monitor output captured, whether `read_flash` of `0x8000` was attempted, whether `espefuse summary` was checked. Mention any DIY UART soldering — D-Central removes flying leads before final inspection. Canada Post small-packet or UPS Ground; D-Central HQ receives and opens within 48 hours on business days.