Rev 1 exposed coupled unknowns

Rev 1 attempted eight outputs through four stereo codecs before its basic signal chain was validated. Repeated initialization, identical I²C addresses, a mux, two digital-audio groups, distributed master clock, repeated analog interfaces, and difficult firmware were coupled. A critical MCLK route also landed on the Teensy carrier’s neighboring 3.3 V pin rather than the intended clock-capable connection. The route stopped the board, but even a patch would have left control, framing, analog requirements, startup behavior, and firmware unresolved.

Rev 2 narrowed the problem until it could be proven

Rev 2 retained Teensy 4.1, replaced four codecs with one CS42526, used one timing plan, added six buffered outputs, protected the input, and made probing straightforward. It communicated with and configured the codec, generated clocks and serial audio, drove DACs, and produced clean buffered output. Four output channels were exercised individually, two concurrently, and an RCA output fed an external amplifier and speaker.

Rev 3 moved the unknowns upward

Rev 3 integrated RT1062 directly and added ESP32-WROVER-E for Bluetooth, UI, settings, web-style control, and commands. It retained CS42526 for two inputs and six outputs, and added USB paths, screen connection, buttons, rotary encoder, GPIO expansion, independent programming, and deeper isolation. The goal was a standalone device, but bare-processor boot, flash, clocks, reset, USB, ESP software, interprocessor contract, analog inputs, and product controls all became independent risk surfaces.

Where the build stopped

The complete front and most of the rear were soldered. A small capacitor group and RT1062’s 4.7 µH external core-buck inductor remained. The order contained 1 µH ESP-buck inductors, not the RT1062 part. The board was never powered and no Rev 3 firmware was written. The plan was to reuse Rev 2 audio, codec-control, clocking, and DMA work, then extend it for analog input, ESP communication, Bluetooth audio, UI, and DSP. Funding ran out during assembly; attention later shifted to the 600 W Amp + DSP; and the architecture’s shortcomings were already visible.

What Rev 3 demonstrates

Rev 3 demonstrates fabricated, near-complete product-scale integration: component selection, schematic architecture, dense processor support, power distribution, analog I/O, communication paths, and deliberate observability and isolation. It does not demonstrate boot, clocks, communication, conversion, Bluetooth, DSP, display operation, or analog performance.

Current redesign conclusion

A successor would use a purpose-built DSP and newer ESP-class controller; remove screen, buttons, game-style UI, and broad GPIO unless requirements justify them; size the analog regulator to the load; add analog-stage headroom; and begin from downstream amplifier requirements. Complexity must be purchased with a clear requirement, interface contract, startup plan, and proving test.

Evidence to show

• Rev 1, Rev 2, and Rev 3 board comparison
• Coupled complexity → deliberate simplification → product reintegration diagrams
• Rev 2 waveform and RCA → amplifier → speaker flow
• Rev 3 front/back assembly photographs
• Designed / assembled / powered / validated matrix
• Original architecture versus redesign direction

From processor user to platform owner

Rev 2 used Teensy 4.1 because it packaged RT1062, bootloader, flash, crystals, power support, USB, and a known software environment. Rev 3 mounted RT1062 directly so DSP lived on one board. In exchange, every system the module supplied had to be recreated.

A reference-derived implementation

The support architecture followed PJRC’s general approach: RT1062, MKL02Z32 boot controller, W25Q16 SPI NOR flash, 24 MHz main crystal, 32.768 kHz RTC crystal, USB, reset and boot controls, external 3.3 V regulation, and RT1062’s internal core buck. Extra decoupling was added in some areas. Placement and routing were original Rev 3 work; this was not a clean-sheet boot architecture.

Startup is a chain

High-input and always-on internal domains wake first. RT1062 then asserts PMIC_ON_REQ to enable external 3.3 V, powering processor I/O, MKL02, and flash. Once stable, MKL02 asserts DCDC_PSWITCH, allowing the internal buck to create approximately 1.15 V core power through the external inductor. Only then can ROM, bootloader, and application code execute. MKL02 also supports reset, boot-mode, debug, data, clock, program-button, and status behavior for recovery and programming.

The missing part that stopped the platform

L2, the required 4.7 µH core-buck inductor, was absent from the DigiKey order. The ordered 1 µH parts are for the ESP buck and are not substitutes. The core-buck path remained incomplete, so the board was left unpowered rather than risking partial startup.

Lesson

Direct integration created learning in BGA support, boot, sequencing, clocks, USB, flash, and dense layout, but much of that work did not directly improve the audio product. Use the most capable platform whose support burden is justified by the application.

Evidence to show

• RT1062 subsystem schematic and processor-area PCB render
• MKL02, flash, crystal, USB, and reset callouts
• Startup-sequence diagram
• Order excerpt and unfinished L2 location

Intended roles

RT1062 was intended to configure CS42526, generate codec clocks, move ADC/DAC samples, execute DSP, and apply gain, routing, and filter changes. ESP32 was intended to receive Bluetooth audio and handle screen, controls, settings, web-style interface, spare GPIO, and high-level commands. The objective was to protect real-time audio from UI and connectivity work.

Streaming versus control

I²S was planned for Bluetooth audio, with ESP32 remembered as master. UART TX/RX provided commands for volume, filters, routing, and settings. An additional GPIO was intended for ready/busy, interrupt, handshake, or synchronization, but its exact role was never finalized. The seven physical point-to-point links can be isolated and probed.

Independent domains and defined links

The ESP32 and RT1062 use separate clocks and boot paths. The interprocessor architecture defined audio transport, command traffic, and a handshake link between them. Rev 3 never reached firmware integration or hardware validation of those connections.

Lesson

The processor split gave real-time audio and product-interface work clear owners. A next revision should keep that separation while limiting UI, expansion, and extra controls to features supported by the product requirements.

Evidence to show

• RT1062/ESP responsibility matrix
• Physical-link and separate-clock/boot-domain diagrams
• UI, GPIO expander, and expansion callouts
• Original dual-MCU direction versus DSP + modern ESP direction

The earlier clock lesson

Rev 1 attempted to distribute 12.288 MHz MCLK while Teensy generated the remaining audio timing. The intended MCLK branch landed on a neighboring 3.3 V carrier pin, and the board never achieved working codec audio. The broader failure was that timing had not been treated as one complete architecture.

Rev 2 corrected this with one master: the RT1062 within Teensy generated MCLK, BCLK, LRCLK, and serial audio for CS42526. Recovered firmware shows a 48 kHz system with 12.288 MHz MCLK, 3.072 MHz BCLK, 24-bit samples in 32-bit stereo slots, and multiple TX lanes feeding DAC pairs. That configuration produced working analog output.

Rev 3 froze the proven codec-side relationship

The bare RT1062 was intended to remain codec master. The schematic routes OMCK, shared LRCLK, shared SCLK/BCLK, three DAC serial-data lanes, one ADC serial-data return, plus I²C, RESET, and interrupt relationships. Zero-ohm links and probe access allow individual signals to be disconnected, observed, or externally driven.

Exact Rev 3 frequencies and framing were never implemented. A 48 kHz system was intended, with Rev 2 firmware serving as a planned baseline rather than a Rev 3 measurement.

Expanded entry paths and two clock domains

Two RCA inputs would pass through active stages to CS42526 ADCs, return digitally to RT1062, receive DSP, and leave through six DAC/output channels. ESP32 would receive Bluetooth audio and transfer it to RT1062 over separate I²S. A direct digital entry was conceptually possible through RT1062, but no dedicated external digital-audio connector is recovered in the root schematic.

The RT1062 owned codec timing, while the ESP32 was designed to send Bluetooth audio through its own serial-audio link. The processors used separate clock domains and defined audio, command, and handshake connections, but Rev 3 never reached firmware integration or hardware validation of that bridge.

Lesson

Reuse proven timing cores, but treat every new clock-domain boundary as a new architecture with explicit buffering, ownership, startup, and failure behavior.

Evidence to show

• Rev 1 incorrect-MCLK connection versus Rev 2 single-master domain
• Rev 2 recovered clock values and waveform
• RT1062-to-CS42526 map and audio-entry path diagram
• ESP32/RT1062 independent-clock-domain diagram
• Isolation links and planned firmware-reuse map

Protected entry and rail split

Approximately 9 V enters through a fuse, SMAJ10A TVS clamp, and ceramic/bulk capacitance. The recovered root schematic does not show confirmed reverse-polarity protection, so Rev 3 must not inherit that claim from Rev 2. TPSM863252 creates the 5.4 V intermediate rail; TPS7A4700 is fed directly from protected input and creates 8 V for OPA1678 analog stages.

Local load-class rails

5.4 V feeds TLV75733 codec-digital 3.3 V, TPS7A2050 codec-analog 5 V and input biasing, and TLV62568 plus 1 µH L1 for ESP32, MCP23017, CP2102N, and ESP support. The codec-digital 3.3 V net also controls 8V_EN, expressing the intended relationship that op-amp rail should not enable until codec digital rail is present. The processor startup network and screen/interface branch also derive from the system infrastructure.

Processor sequencing

Beyond the rail tree, always-on RT1062 domains wake, PMIC_ON_REQ enables external 3.3 V, MKL02 and flash become powered, then MKL02 asserts DCDC_PSWITCH so the internal buck can create approximately 1.15 V through 4.7 µH L2. If external 3.3 V, MKL02 state, switch, inductor, or core network is wrong, CPU cannot reach ROM execution.

Debug boundaries

The design intended codec and ESP to remain isolatable if RT1062 failed; codec rails could be disconnected and lab-supplied; clock links could be opened and externally driven; and ESP/RT1062 communication links could be isolated. This extends Rev 2’s links and selective access into an explicit board architecture of isolation, injection, and observability.

Missing L2 and redesign lesson

The 4.7 µH L2 was not ordered; 1 µH ESP parts are not substitutes. The board was not powered, so no rail voltage, ripple, timing, protection, injection, or thermal behavior was measured. A redesign should size analog regulation to actual load while providing useful voltage headroom. A prototype power tree must define both how a system runs and how each subsystem can be proven without trusting the rest.

Evidence to show

• Protected-input and full rail map
• Startup chain diagram
• Rail test points, indicators, links, and injection boundaries
• Missing-L2 order comparison and staged first-power checklist

Progression across revisions

Rev 1 wanted one stereo input and eight outputs without engineering the interfaces around real sources or loads. Rev 2 corrected output: CS42526 produced six differential DAC channels and repeated OPA1678 stages converted, filtered, and buffered them into RCA outputs. It produced measured sine output and fed an external amplifier and speaker. Rev 3 retained that output architecture and added the input direction.

Two active inputs and six active outputs

Two RCA inputs were intended to enter CS42526 ADCs through OPA1678 stages that create the differential pair required by the converter and present expected source conditions. The topology was based on the codec reference design, not a formal product requirement.

Three stereo DAC pairs create six differential outputs. Three dual OPA1678 packages implement six differential-to-single-ended filtering/buffer channels from a quiet 8 V rail to six RCA connectors. The filters were intended to reduce out-of-band converter noise and present a practical signal to external amplification.

Physical capacity is not a specification

Rev 3 had no locked consumer, professional, or automotive target for headroom, Vrms, source/load impedance, cable length, DC fault, ESD, short protection, noise, distortion, matching, or amplifier compatibility. External grounding through RCA shields, supplies, and downstream amplifier was not fully defined. “Two inputs and six outputs” describes channel architecture—not qualified interface performance.

Lesson

A redesign should begin with downstream amplifier impedance, required level, cable/ground arrangement, noise target, faults, and available supply headroom. More useful op-amp headroom, a load-appropriate regulator, and explicit ground-loop requirements should follow. First define the external interface, then choose and calculate the converter support circuit.

Evidence to show

• Rev 1/2/3 analog comparison and two-input/six-output map
• Single-ended-to-differential and differential-to-single-ended diagrams
• OPA1678/8 V callouts
• RCA-to-amplifier requirements table and future measurement plan

Preferred high-speed environment

The stack was L1 top/components/primary fast routes, L2 main solid ground, L3 power/mixed routing, and L4 bottom/components/slower and escape routing. L1 and L4 were not treated as equivalent high-speed layers. Fast routes were intentionally kept on L1 where possible so they referenced L2 directly; bottom was mainly slower traffic and unavoidable escape/cross-under routing.

Signal priority and analog separation

Fast traces were kept away from unrelated circuitry and crossings were avoided where they lacked solid ground separation. When crossings were necessary, their risk was judged by signal speed rather than arbitrary geometry matching. Analog input/output circuitry was grouped near the lower board, and fast digital traffic was kept out so analog ground did not become the main return path for processor traffic.

Stitching, fencing, and local plane damage

Pours, via stitching, and fencing were intended to improve ground continuity, connect local pours, contain return current, and create a coherent reference. This was a methodological step forward. Execution was not perfect: clearances and antipads around dense RT1062 routing created local slots and narrow ground paths. Dense stitching can undermine the plane it is meant to help; density, antipad geometry, escape routing, and continuity must be reviewed as one electromagnetic structure.

Debugability as physical architecture

Rev 3 made RT1062-to-codec clock, data, and control links disconnectable and accessible on both sides; the ESP links received similar treatment. Major rails could be separated and lab-supplied. The intent was that a dead RT1062 would not prevent codec/ESP study, and that external known clocks could be injected into an isolated codec side. Everything important should be measurable, isolatable, injectable, and falsifiable one system at a time.

What it proves

Schematic and PCB architecture show improved routing discipline, grounding intent, analog separation, and debug planning. Because the board was never powered, they do not prove ringing, crosstalk, jitter, noise, return-current behavior, EMI, or analog performance.

Evidence to show

• Four-layer stack and critical-route maps
• Analog-separation and pour/stitching overlays
• RT1062 via-antipad/ground-slot examples
• Codec/ESP isolation diagrams and revision-to-revision debug comparison