Bitaxe – PSRAM Log Capture Unavailable / Logs Lost

Run `curl -s http://<bitaxe-ip>/api/system/info | jq` (or hit the URL in a browser) and read the `version`, `boardVersion`, and `freePSRAM` / `psramSize` fields. Note them. AxeOS builds older than `v2.9.0` shipped before the `log_buffer.c` ring buffer landed in `bitaxeorg/ESP-Miner` PR #1646 — they cannot persist logs across a reboot regardless of hardware. `psramSize: 0` (or missing) tells you the firmware can't see PSRAM. These two numbers determine whether the fix is a 60-second OTA or a deeper rebuild.

Open the [Bitaxe Web Flasher](https://bitaxe.org/flasher) in Chrome or Edge (it needs WebSerial). Plug the Bitaxe in via USB-C. Select your board variant (Supra / Ultra / Gamma 601-602 / Gamma Turbo 800 / Hex). Pick the latest stable AxeOS release from the dropdown. Flash. Wait for the post-flash reboot. Re-test `/api/system/log` after triggering one panic (push an obviously-bad pool URL, or `curl -X POST http://<ip>/api/system/restart` then watch the buffer). On `v2.9.0` and later, the soft-reboot persistence is on by default — no further config required.

Confirm the ESP32-S3 module is the `WROOM-1 N16R8` (16 MB Flash + 8 MB Octal SPI PSRAM). Run `esptool.py --port COM4 chip_id` (replace COM4 with your serial port — `ls /dev/tty.*` on macOS, `/dev/ttyUSB0` on Linux). Output should include `Chip is ESP32-S3 (revision X)` and `Features: WiFi, BLE, Embedded PSRAM 8MB (AP_3v3)` for an N16R8. If `Features` does not list embedded PSRAM, the module physically does not have the RAM and no firmware change adds it. That is a hardware swap, not a fix — book D-Central or replace the module with an N16R8.

Check the boot banner at `115200 8N1` for the PSRAM init line. Watch for `I (xxx) esp_psram: Found 8MB PSRAM device`, `I (xxx) esp_psram: Reserving pool of 32K of internal memory for DMA/internal allocations`, and `I (xxx) cpu_start: Application information: ... PSRAM: enabled`. If those lines are absent on a confirmed N16R8 module, the firmware was built with `CONFIG_SPIRAM=n` — wrong sdkconfig for this board. Reflash an official AxeOS factory image via the Web Flasher; do NOT keep running custom firmware that disables PSRAM on a board that physically has it.

Trigger one controlled panic to test the ring buffer. From a serial monitor, send a `POST` to a known-malformed pool config (or pull the USB-C cable mid-`/api/system/restart` for a hard reset). On the next boot, `curl http://<ip>/api/system/log` should return the pre-reset tail of `ESP_LOG*` output including the `rst:0x3 (SW_CPU_RESET)` reason. If logs return for `rst:0x3` but vanish for `rst:0xf`, your panic source is a brownout — the panic handler never runs because the rail collapsed first; jump to Step 7.

If the boot banner shows `rst:0xf (RTCWDT_BROWN_OUT_RESET)`, the panic handler never executed and the ring buffer never flushed — fixing the log endpoint requires fixing the brownout. Measure the 5 V rail at the barrel jack / USB-C / XT30 input under load with a multimeter (Fluke 117 or equivalent). Target ≥ 4.85 V sustained while the ASIC is hashing. Below = PSU undersized, cable too thin, or barrel jack worn. Replace the PSU with one rated 25 % above board nameplate (Hex draws ~75 W, GT ~30 W, Supra/Ultra/Gamma ~15 W). The brownout disappears, the panic handler runs, the ring buffer survives.

Check the `partitions.csv` shipped in your firmware build. Open the `ESP-Miner` repo at the version tag matching your boot-banner version (`https://github.com/bitaxeorg/ESP-Miner/blob/v2.x.y/partitions.csv`) and confirm the file declares an `otadata`, two `app` partitions, an `nvs` partition, a `spiffs` / `littlefs` partition for the web UI, and — for full coredump support — a `coredump` partition with `Type=data, SubType=coredump`. Stock AxeOS ships a coredump partition on releases that support it. A custom build without it cannot save coredumps to flash; the panic dies in PSRAM and is lost on power-cycle.

If you maintain a custom firmware fork, edit `partitions.csv` to add `coredump, data, coredump, , 64K,` (offset auto-calculated). In `sdkconfig` (or via `idf.py menuconfig`), enable: `CONFIG_ESP_COREDUMP_ENABLE_TO_FLASH=y`, `CONFIG_ESP_COREDUMP_DATA_FORMAT_ELF=y`, `CONFIG_ESP_COREDUMP_CHECKSUM_CRC32=y`, and confirm `CONFIG_SPIRAM=y` plus `CONFIG_SPIRAM_MODE_OCT=y` (Hex / GT use Octal PSRAM). Rebuild with `idf.py build`. Flash. After the next panic, pull the coredump with `espcoredump.py -p COM4 info_corefile -t b64 build/esp-miner.elf`. That is the same forensic data Espressif's IoT BSPs ship with — it isn't D-Central magic, it's published Espressif workflow.

If `/api/system/log` is empty post-`v2.9.0` despite N16R8 hardware and a clean factory image, full-erase the flash before reflashing. Run `esptool.py --port COM4 erase_flash`, wait for `Chip erase completed successfully`, then re-flash via the Web Flasher. The erase clears any orphaned NO_INIT memory checksum that the firmware will reject as corrupt (`log_buffer.c` validates a checksum on the persisted struct — a corrupt one is dropped, and you see an empty buffer). Cold-boot the device; the checksum re-initializes clean.

If the device persisted logs yesterday and stopped today, check whether you flashed an older release in between. AxeOS does not version the NO_INIT struct yet; flashing a build with a different `log_buffer_t` layout invalidates the checksum and yields an empty endpoint until the next clean panic re-initializes the struct. Flash forward to the latest stable, soft-reboot once with `curl -X POST http://<ip>/api/system/restart`, and the buffer is back. Pinning to one AxeOS major-minor across a deployment avoids this.

When PSRAM and the ring buffer are healthy but you still want a deeper trace, attach `idf.py monitor -p COM4` permanently to a logging laptop. The serial console captures `ESP_LOGI` / `ESP_LOGW` / `ESP_LOGE` output in real time at `115200 8N1` regardless of whether the ring buffer survives. Pipe to a file: `idf.py monitor -p COM4 | tee bitaxe-$(date +%F).log`. Two parallel logs (PSRAM ring + UART pipe) catch every failure mode — the ring buffer survives reboots, the UART pipe survives brownouts. Belt and suspenders.

If the panic block contains `(Cache disabled but cached memory region accessed)` and you're trying to capture it via the ring buffer, you may not — that exception class fires during ISR execution while flash cache is disabled, which is exactly when the panic handler can't safely read the linker-mapped log strings. Capture this flavour of panic via UART only. The log buffer endpoint may legitimately stay empty for cache-region panics; that's a known ESP-IDF constraint, not a Bitaxe bug.

For the small-but-real population of Bitaxe boards where `chip_id` confirms N16R8, AxeOS is current, partitions are correct, sdkconfig is right, brownouts are ruled out, AND `/api/system/log` is still empty across multiple controlled panics — that is hardware-induced PSRAM corruption. Symptoms: random `(LoadProhibited)` panics with `EXCVADDR` in the `0x3F8xxxxx` external RAM range, `heap_caps_check_integrity_all(true)` returning errors on every check, AxeOS reporting wildly fluctuating `freePSRAM` values. The PSRAM die or its solder joint under the WROOM-1 module is failing. Module swap territory — Tier 4.

Tier 4 — D-Central bench. Ship the Bitaxe to [D-Central ASIC + Bitaxe Repair](https://d-central.tech/services/asic-repair/). We stock graded `ESP32-S3-WROOM-1 N16R8` modules and the hot-air rework gear to swap them. Typical bench process: confirm the panic via UART capture, pull a `chip_id` and `flash_id`, reflow the existing module first (often fixes a marginal solder joint), retest with a controlled panic, swap the module if reflow fails. 3-7 business-day turnaround. As the company that pioneered the Bitaxe Mesh Stand and Hex heatsink, we have the bench depth to fix this without you sending the board to a generic ESP32 shop that doesn't know AxeOS partition layout.

Document the version pinning in your operations notes — for fleet operators: pin AxeOS to the same minor across all units, cache the matching `.bin` + `.elf` artifacts in your own S3 / git LFS, and snapshot `partitions.csv` + `sdkconfig` for any custom builds. The whole point of PSRAM-backed logs is reproducible debugging. If three Bitaxes panic with three different firmwares, you cannot correlate. If three Bitaxes panic on the same firmware with persisted logs, the upstream maintainer can fix it on the first issue you file.