Project Start Prompt

flux

I reconciled both prior reports, ran a fresh ERC snapshot, and dispatched the full verified repair list. The remediation executor has now completed, but ACUs were exhausted before I could retrieve its final report or independently validate the resulting schematic.
PCB layout remains blocked pending:
  • Fresh ERC review and repair confirmation
  • Block-by-block validation of power, clocks/reset, SDRAM, USB/ULPI, display, microSD, audio, controls, and SWD
  • Confirmation that no critical pin-mux conflicts or datasheet violations remain
Received notification from "Rockbox Bring-Up Schematic" that it finished — picking the work back up.

flux

The remediation executor has completed, but I cannot retrieve or inspect its report because the account currently has no available ACUs. No additional project changes or validation were performed in this turn.
PCB layout remains blocked until these steps are completed:
  • Confirm every requested repair landed in the schematic.
  • Run fresh ERC and resolve critical errors.
  • Independently validate power, clocks/reset, SDRAM, USB-C/ULPI, display, microSD, audio, controls, and SWD.
  • Verify pin multiplexing and datasheet compliance before declaring bring-up readiness.
Inspect schematic repairs
Check ERC issues
Validate power interfaces
Check pin multiplexing
Sign up to send

Files

Schematic

Layout

Preview

Open-Source Modular Rockbox Player — Project Specification
1. Product Vision
Create a repairable, open-source portable music player that combines Echo's Rockbox-compatible architecture with lessons from Tangara's open hardware and touch-wheel implementation. The physical design should blend vintage transparent Game Boy character with the modern, functional transparency associated with Nothing.
2. First-Version Scope
Phase-1 Bring-Up Revision (current schematic scope)
  • Echo R1 Rev1-derived STM32H743 + 32 MiB SDRAM motherboard.
  • One external microSD only; internal system card deferred.
  • Fixed D-pad, A/B/X/Y, Start, Select, reset, hold/power access, and a volume encoder with push-to-mute.
  • 320 × 240 18-bit RGB LCD interface on a sourced 35-position FPC connector; exact panel remains a controlled uncertainty.
  • USB-C device with USB3320 ULPI high-speed PHY and external ESD protection.
  • TLV320AIC3104 codec with separate volume-controlled headphone and fixed line outputs.
  • Connectorized 1-cell LiPo with power-path charging, NTC provision, and battery measurement.
  • Smart pogo modules, touch wheel, second microSD, magnets, wireless, and enclosure geometry are explicitly deferred.
  • Portable, vertically oriented dedicated music player.
  • Echo-compatible Rockbox baseline; avoid unnecessary divergence from the existing target.
  • One full-width, hot-swappable smart control module at a time.
  • Two control modules:
    1. SNES-style D-pad, A/B/X/Y, Start, and Select.
    2. iPod-inspired capacitive touch wheel with directional click regions and center select.
  • Permanent host controls: rotary volume encoder with push-to-mute and OFF / ON / HOLD slider.
  • No Bluetooth in v1.
3. User Interface
Display
  • 2.4-inch, 320 × 240, non-touch IPS display.
  • Preserve compatibility with Echo/Rockbox display assumptions where practical.
Gamepad Module
  • SNES-inspired arrangement.
  • D-pad on left.
  • A/B/X/Y cluster on right.
  • Start and Select centered below or between primary controls.
  • X is the default dedicated play/pause control.
Touch-Wheel Module
  • Tangara-informed capacitive sensing architecture.
  • iPod-inspired wheel interaction without copying proprietary mechanical details.
  • Dedicated bottom click region for play/pause.
  • Center select and remaining directional/menu click regions mapped to Rockbox actions.
Permanent Controls
  • Side-mounted rotary encoder: turn for volume; press to toggle mute/unmute.
  • Three-position physical slider: OFF / ON / HOLD.
4. Swappable Module Interface
  • One rigid, full-width smart module installed at a time.
  • Magnetic alignment and retention, with mechanical keying to prevent incorrect insertion.
  • Six pogo contacts:
    • Two 3.3 V contacts.
    • Two ground contacts.
    • I²C SDA.
    • I²C SCL.
  • Each module includes a small microcontroller for scanning controls, identification, event reporting, debounce, and touch processing.
  • Host firmware automatically identifies the installed module.
  • Hot-swap behavior must prevent bus lockup, false events, and unsafe power sequencing.
5. Storage
For Phase 1, populate only one externally accessible microSD card with card detect, ESD, and controlled power/hot-swap support. The dual-card product architecture remains a later revision.
  • Internal microSD card under the service cover, reserved for Rockbox, themes, configuration, and recovery.
  • Externally accessible microSD card for the removable music library.
  • The music card should be replaceable without opening the enclosure.
6. Audio and USB
  • 3.5 mm TRS volume-controlled headphone output.
  • Separate 3.5 mm TRS fixed-level stereo line output, clearly labeled.
  • USB-C for charging, file transfer, and digital audio where supported.
  • No balanced analog output in v1.
7. Power and Repairability
The Phase-1 rail and source-current calculations are maintained in the project file Phase 1 Power Budget. Current estimates do not support claiming 20-hour runtime; operation while charging and safe thermal/NTC behavior take priority over runtime optimization in this revision.
  • Target at least 20 hours of typical music playback, subject to measured power-budget validation.
  • Internal LiPo pouch battery, service-replaceable rather than hot-swappable.
  • Keyed battery connector; no soldering required for routine replacement.
  • Screwed enclosure with no structural adhesive.
  • Battery, display, jacks, controls, and module interface should be replaceable as subassemblies where practical.
8. Mechanical Direction
  • Approximate starting envelope: 78 × 125 mm, 18–22 mm thick.
  • Game Boy Pocket-like vertical proportions and comfortable rounded lower body.
  • Permanent outer chassis frame with a smaller recessed control cassette.
  • Module should sit flush or nearly flush and resist pocket shear loads independently of pogo spring force.
9. Visual Direction
  • Transparent or translucent shell options with intentional internal layout.
  • Vintage clear-console reference, modernized with clean geometry and restrained detailing.
  • Nothing-inspired visible fasteners, structured internal graphics, and carefully routed visible elements.
  • Avoid ornamental fake circuitry; exposed features should correspond to real functions.
10. Open-Source and Documentation Goals
  • Publish editable schematic, PCB, mechanical CAD, firmware patches, module protocol, BOM, assembly instructions, and repair documentation.
  • Prefer obtainable components with documented second-source or substitution paths.
  • Document connector wear items and battery replacement procedure.
11. Validation Criteria
  • Boots and runs Rockbox reliably.
  • Reads both microSD cards according to their assigned roles.
  • Detects either control module without rebooting or locking the I²C bus.
  • All navigation and playback actions remain accessible on both modules.
  • Volume encoder and mute function operate independently of installed module.
  • Headphone and line outputs meet their intended level and noise requirements.
  • Typical playback runtime reaches the 20-hour target or deviations are documented.
  • Enclosure survives repeated module swaps and remains serviceable with ordinary tools.
12. Deferred Features
  • Bluetooth audio.
  • Wi-Fi or streaming services.
  • Balanced analog output.
  • Touchscreen UI.
  • Waterproofing.
  • Production certification and high-volume tooling.

  • 1. Product Vision

  • 2. First-Version Scope

  • Phase-1 Bring-Up Revision (current schematic scope)

  • 3. User Interface

  • Display

  • Gamepad Module

  • Touch-Wheel Module

  • Permanent Controls

  • 4. Swappable Module Interface

  • 5. Storage

  • 6. Audio and USB

  • 7. Power and Repairability

  • 8. Mechanical Direction

  • 9. Visual Direction

  • 10. Open-Source and Documentation Goals

  • 11. Validation Criteria

  • 12. Deferred Features