Investigating a ZECTRIX E-Paper Terminal: Hardware, Firmware, and Zig

Investigation date: 2026-10-21

1. Executive conclusion

The connected device is a standalone ESP32-S3 e-paper terminal, not a plug-and-play USB monitor or a Linux computer. Its installed application identifies itself as xiaozhi 3.6.1, with board SKU zectrix-s3-epaper-4.2. It uses ESP-IDF / FreeRTOS, LVGL, and a SPI-connected e-paper display.

USB serial logging, reset, ROM download access, security queries, and a complete 16 MiB flash read were demonstrated. Secure Boot and flash encryption are disabled. No usable USB shell, display-upload command, or USB audio interface was found. Custom firmware is a practical development route, but no replacement firmware was flashed during this investigation.

Evidence categories

• Measured: observed through USB enumeration, serial logs, chip queries, or binary analysis of the flash backup.
• Documented: stated in official documentation for the corresponding NOTE4 development hardware. The physical PCB revision and exact panel have not been independently verified.
• Proposed: a development direction, not an implemented or tested capability.

2. Investigation sequence

1. Enumerated the USB device tree using macOS ioreg. system_profiler SPUSBDataType returned no device information, so it was not used as evidence of absence.
2. Compared USB enumeration before and after physically disconnecting the e-paper device. The Espressif JTAG/serial node was the only device that disappeared, identifying the correct USB endpoint.
3. Opened the serial port at 115200 baud and passively captured runtime logs.
4. Triggered a reset through serial control lines and captured startup logs identifying the chip, application, board SKU, peripherals, and network behavior.
5. Used esptool 5.6.0 to query security settings and flash capacity, then read the entire flash using a temporary RAM-resident stub.
6. Parsed the partition table and application descriptor from the backup. The populated application's embedded SHA-256 matched its image contents.
7. Tested help and ? after startup. Only normal log output was observed; no shell prompt or command help appeared.
8. Compared the findings with official hardware, firmware, API, and open-source documentation, and researched Zig toolchain support.

3. Hardware inventory

No SD-card expansion capability was established.

4. USB identity and behavior

The device was connected through a GenesysLogic USB hub. Serial paths may change with the host, hub, or port.

It did not enumerate as a conventional display, mass-storage device, or USB Audio Class microphone. The Espressif USB product name describes the controller interface, not the complete e-paper product.

Opening the serial port or changing DTR/RTS can reset the chip. Some initial command probes overlapped startup; the help/? test was repeated after startup before drawing the limited conclusion that no interactive command interface had been found.

5. Installed system and firmware

An initial runtime signature was:

I (751713) SystemInfo: free sram: 112179 minimal sram: 108103

This matched the open-source xiaozhi logging implementation. The subsequent startup log and application descriptor confirmed the application name and version directly.

Startup registered these MCP tool names:

self.disp.network
self.dev.power
self.memo.search
self.time.set_datetime
self.timer.countdown
self.timer.pomodoro
self.weather.set_location
self.get_device_status
self.audio_speaker.set_volume
self.get_system_info
self.reboot
self.upgrade_firmware

Registration is evidence of application functionality, not proof of a USB-accessible MCP server. None of these tools was remotely invoked during the investigation.

The running firmware attempted to connect to a saved Wi-Fi network but repeatedly reported that no access point was found. It was not brought online, so cloud display delivery and network control remain untested.

6. Storage and memory

6.1 Flash partition layout

The partition table was parsed from the full-device backup.

The remaining address space contains the bootloader, partition table, and layout gaps. The application reported a 4096 KB filesystem with approximately 24 KB used at startup. Filesystem overhead and subsequent writes affect actual usable capacity.

6.2 What the capacities mean

• 16 MiB flash: nonvolatile storage shared by firmware, configuration, OTA slots, and files; not 16 MiB of free file space.
• 8 MiB PSRAM: volatile working memory for buffers and application state; contents do not survive power loss.
• Current file partition: 4 MiB under the installed partition layout.
• A custom layout could reclaim some firmware-slot space, but changes OTA and recovery assumptions. Existing image offsets must not be reused blindly after repartitioning.

6.3 Raw content sizes

The PCM calculation assumes 16-bit samples; the unit's sample bit depth was not established. An entirely available 4 MiB partition would hold approximately 131 seconds of that raw audio before filesystem/container overhead. In practice, space is shared with other content. Long recordings should be streamed to a host rather than retained entirely in flash.

7. Recording and audio possibilities

The hardware is suitable for voice capture. Startup logs show successful ES8311 initialization, I²S receive/transmit channel creation, and input/output enablement at 16 kHz mono. The firmware later disables idle audio paths.

This is not yet an acoustic recording test. The following remain unverified:

• Whether microphone samples contain usable sound.
• Sample format, bit depth, channel mapping, gain, and clipping behavior.
• Whether stock firmware offers a recording-to-file feature.
• Whether stock firmware exposes any audio streaming protocol usable by a local host.

A practical proposed workflow is:

1. Hold a device button to begin capture.
2. Stream audio to the Mac over a custom USB or Wi-Fi protocol.
3. Save or transcribe on the Mac.
4. Return recognized text or task status to the e-paper display.

This requires implementation and hardware validation. The existing USB interface cannot currently be treated as a plug-and-play microphone.

8. Control options

8.1 USB: demonstrated versus unverified

Disabled Secure Boot and encryption, together with demonstrated download access, make custom-firmware work feasible. They do not constitute a completed flashing or recovery test.

8.2 Keep the installed firmware and use the cloud

The official cloud API documents device management, to-dos, synchronization intervals, and image/text display pushes.

Base URL: https://cloud.zectrix.com/open/v1/
Authentication header: X-API-Key: <private API key>

Relevant endpoints:

GET  /devices
POST /todos
POST /devices/{deviceId}/display/image
POST /devices/{deviceId}/display/text
POST /devices/{deviceId}/display/structured-text

The documented image endpoint accepts multipart uploads, up to five images and 2 MB per image. Text pushes support up to 5,000 characters and a documented font-size range of 12–48. The device ID is the MAC address. Optional page IDs enable persistent page storage according to the API documentation.

This route requires working Wi-Fi connectivity, account/device association, and a valid API key. None of the cloud operations was exercised against this unit.

8.3 Other firmware interface evidence

Binary inspection found references to:

• MQTT communication and command payload handling.
• HTTP to-do, display, and configuration synchronization.
• A provisioning web portal, including http://192.168.4.1 and advanced configuration routes.
• BLUFI provisioning.
• NFC command handling.

The official feature guide documents NFC text-record commands such as {"cmd":"sync"} and a custom OTA URL command. These were not tested. Firmware strings and documentation do not establish reachability, authentication requirements, or complete protocol behavior on this unit.

8.4 Replace the application firmware

The official MIT-licensed reference project supplies a display driver, board mappings, and peripheral demonstrations for the monochrome development hardware. It is not the source code of the full installed consumer-style firmware or cloud service.

A simple proposed design is a Mac-side renderer plus a USB-connected device application that receives text/bitmaps, refreshes the display, and reports button events. Wi-Fi and audio can be added once the display path is validated.

Before flashing, independently establish that the physical board and panel match the chosen driver. NOTE4, NOTE4 DevKit, and NOTE4C images must not be treated as interchangeable.

9. Can the firmware be written in Zig?

Yes, with a toolchain constraint: this unit uses Xtensa LX7, not RISC-V. The investigated community integration states that upstream Zig's LLVM backend does not support Xtensa; ESP32-S3 requires an Xtensa-enabled Zig toolchain/fork. A normal upstream Zig setup for ESP32-C3/C6 is not interchangeable with an S3 build.

The community project kassane/zig-esp-idf-sample lists ESP32-S3 as a supported target and labels its overall status Experimental. Its documentation points to a customized Zig toolchain distributed through kassane/zig-espressif-bootstrap. These are community integration resources, not a claim that this investigation validated an officially supported Zig SDK.

Recommended integration

Prefer compiling Zig application code into a static library and linking it through the ESP-IDF build. Use C ABI boundaries; where a driver only exposes C++ APIs, add a thin extern "C" wrapper instead of rewriting the driver.

Pin the Zig fork/revision, ESP-IDF version, ABI, and build options together. Do not assume that the Mac's existing Zig installation can target the board. Zig code would be linked into a complete firmware image, not copied onto the installed system as a standalone executable.

No Zig firmware was compiled or run on this device. The first proposed proof should be small: a Zig startup message, receipt of one USB command, and a visible display update, followed by audio capture if needed. A pure-Zig bare-metal rewrite of boot, drivers, and radio integration is not recommended for the initial project.

10. Project ideas

E-paper is suited to infrequent, event-driven updates and persistent information. It is not suited to smooth video, continuously scrolling logs, or a high-rate audio waveform display. Image retention after power-off does not imply the MCU is still running.

11. Hardware pin reference

The following is the official NOTE4 DevKit V1.0 mapping, not a teardown-confirmed pinout of this individual unit.

All GPIO uses 3.3 V logic. Do not drive GPIO directly with 5 V.

12. Backup and reproducibility

Preserved image

/Users/jin/Backups/zectrix-db4e54/factory-20261021.bin

Size: 16,777,216 bytes.

SHA-256:

f9a7c15b0e1ffec676f031bde34dc4d1c22e33c53dc746dd7d8ed9fb911777c7

Directory permissions were set to 700; image permissions were set to 600. The populated ota_0 application's embedded SHA-256 validated successfully. This verifies that application's internal image consistency, not every byte of the complete device against an independent reference, and not restorability.

The image may contain Wi-Fi credentials, device credentials, and user data. It was kept outside the code repository. Do not publish or commit it.

Tools and commands exercised

Tools were installed in an isolated temporary environment at /tmp/ink-usb-probe. That environment is disposable and should not be assumed to persist.

The following inspection and backup operations were executed, with the serial port shown as it existed during the investigation:

# Enumerate USB and serial devices.
ioreg -p IOUSB -w 0
ioreg -r -c IOSerialBSDClient -l -w 0

# These esptool operations can reset or interrupt the running device.
/tmp/ink-usb-probe/bin/esptool --port /dev/cu.usbmodem1301 \
  --baud 460800 --after hard-reset get-security-info

/tmp/ink-usb-probe/bin/esptool --port /dev/cu.usbmodem1301 \
  --baud 921600 flash-id

/tmp/ink-usb-probe/bin/esptool --port /dev/cu.usbmodem1301 \
  --baud 921600 read-flash 0 0x1000000 \
  /Users/jin/Backups/zectrix-db4e54/factory-20261021.bin

shasum -a 256 /Users/jin/Backups/zectrix-db4e54/factory-20261021.bin

These are a record, not an instruction to overwrite the preserved backup. Use a new filename for subsequent reads. No erase, flash-write, or eFuse-write command was run.

13. Development and safety rules

1. Confirm the exact physical board revision and display before selecting a firmware image or pin mapping.
2. Preserve the full flash image and hash before changing firmware or partitions. Recovery has not yet been tested.
3. Do not casually burn eFuses or enable Secure Boot/encryption. Such changes can be irreversible and cannot be undone by restoring flash.
4. Keep backup images, Wi-Fi credentials, device keys, and API keys private. Do not include raw boot logs in public reports without checking them: this firmware logs identifying and credential-like fields.
5. Avoid simultaneous access to the serial port. Port opening and DTR/RTS changes can interrupt recording or reset the device.
6. Follow the matched panel driver's power and refresh sequence. Full refresh, partial refresh, and grayscale have different timing and ghosting characteristics.
7. Test real acoustic capture and a visible screen update before claiming end-to-end functionality. Initialization logs alone are insufficient.

14. Final state and open questions

The original application booted and emitted normal logs after the read-only investigation. The device was deliberately reset and a temporary RAM stub was used, but no intentional flash erase/write, eFuse change, or configuration change was performed. Normal firmware startup may update persistent state, so flash is not claimed to be byte-for-byte unchanged across the session.

Open questions:

• Exact PCB revision and physical panel/controller match.
• Real microphone and speaker performance, including actual sample format.
• Any undocumented stock USB command protocol.
• Cloud compatibility and control behavior once properly provisioned.
• Actual refresh latency, grayscale quality, power consumption, and battery life.
• Zig toolchain/build compatibility on the local Mac and this hardware.
• Successful backup restoration.

15. Sources

• Official NOTE4 DevKit development guide
• Official e-paper reference project
• Official cloud API documentation
• Official feature guide
• Official open-source scope and licensing
• Official developer-kit product page
• Xiaozhi system information source
• Community Zig + ESP-IDF integration
• Community Xtensa Zig toolchain releases