The architecture I was trying to build

The target sample rate was 48 kHz, and the selected audio plan called for a 12.288 MHz master clock. Rev 1 used a dedicated oscillator so the four codecs could share one MCLK source. The Teensy was intended to generate BCLK and WCLK/LRCLK, with every codec operating as a slave on one of two digital-audio buses.

The oscillator branch was intentionally routed toward the Teensy's clock-capable connection. The planned external-clock configuration was valid; the issue was that the trace reached the neighboring 3.3 V pin instead.

The problem was not unrelated clock domains or an unfinished clocking method. The board was designed to distribute the same oscillator-derived reference to the codecs and Teensy; the error was the pin connection at the Teensy.

What the fabricated board actually connected

At the Teensy carrier, the MCLK branch terminated on the neighboring 3.3 V power pin instead of the intended clock connection. The MCLK trace reached the Teensy area, but it was connected to the wrong pin.

I found the routing error during bring-up, around the time the Teensy was installed for basic firmware testing.

A board modification may have been technically possible. A cut-and-jumper repair could potentially have disconnected the wrong carrier pad and connected the clock branch to the intended destination. But recoverability is not the same as a reason to keep investing in the board.

What the scope did and did not show

The remembered MCLK observations were taken with the Teensy removed. In that configuration, approximately 12.288 MHz was observed at the oscillator or source, the MCLK test point, and each of the four codec areas. That supports a limited claim: the unpopulated-carrier network distributed a clock-like signal across the board.

The measurements clearly showed ringing and various waveform shapes at different locations on the board. The original scope captures are not currently available, but the observed behavior was enough to show that the clock network needed a more deliberate design.

The board included a source damping resistor, but its initial value was selected as a rule-of-thumb starting point for later tuning rather than derived from a complete transmission-line model. It was not a protection device for the Teensy. It was an intentional signal-integrity adjustment point whose final value was never optimized.

Most importantly, the ringing was not proven to cause codec failure. Firmware never reached a stage where codec communication, TDM framing, conversion, or analog performance could isolate that causal chain. The clock waveform is evidence about signal quality, not a complete explanation for why audio never worked.

Why I stopped instead of patching it

By the time the carrier error was understood, Rev 1 already required four codec configurations, an I²C mux sequence, two unfinished TDM frame plans, a distributed MCLK network, and an external analog interface that had not been fully specified. Repairing one trace would not remove those integration burdens.

The routing mistake became the decision point where additional bring-up stopped feeling worthwhile. That is different from proving the mistake was the only failure. It was the most visible defect in a system that still had several unvalidated dependencies.

Rev 2 used a simpler architecture centered on one multichannel codec. The lesson was not merely to check a pin number more carefully. It was to reduce the number of simultaneous unknowns and make the next board easier to partition, configure, and prove.

From a stereo source to a multichannel target

The starting requirement was simple to state: accept one stereo USB audio stream, process it inside the Teensy, and produce eight independently modifiable analog outputs. The intended processing included routing, mixing, volume adjustment, delay, basic EQ, and crossover filtering. The eight-output architecture was intentional, with fixed processing rather than a user-configurable interface.

Four stereo codecs supplied the planned conversion capacity. The upper-right device also carried the only planned stereo ADC path. The challenge was not just sending more samples; it was keeping logical channels, peripheral capabilities, codec registers, physical nets, and analog connectors consistent across the complete chain.

Why I split the bus

Instead of one eight-channel TDM bus spanning the entire board, I planned two four-output groups. One bus served the codec pair on one side, and the other served the remaining pair. At the time, two smaller groups felt easier to reason about and avoided distributing one larger bus everywhere.

The Teensy was intended to generate BCLK and WCLK/LRCLK and transmit playback data. Each codec would operate as a slave and use its assigned time slots. The architecture fit the system I was building, but the MCU peripherals, codec modes, and slot assignments still needed to be defined together.

Keeping the two groups separate simplified board routing, but it required the clocks, data format, channel naming, and firmware behavior to stay aligned across both buses.

The missing channel and timing plan

I routed the PCB before the complete TDM channel and timing plan was defined. Frame width, slot count, slot width, codec transmit and receive slots, and logical channel order had not been finalized from the USB input through DSP processing, bus slots, codec outputs, and physical headers.

The upper-right codec had a physical ADC return routed back toward the Teensy, but its receive frame and slot plan were not finished. The physical connection alone did not define a working input channel.

Codec register setup and Teensy peripheral configuration were also unfinished. The buses were routed, but TDM traffic, channel order, and capture behavior were never completed or validated on Rev 1.

What I would define before routing now

Before routing, I would define the full channel and timing plan: how every source, processing block, output, bus, slot, and MCU peripheral fit together. Then I would prove one codec and one bus before copying that approach across the board.

The component-level decision

I chose the codec for its I²S support, 3.3 V-compatible digital interfaces, 48 kHz operation, and 24-bit audio. One stereo codec appeared to meet those needs, and using four of them provided a direct path to eight outputs.

I did not complete a formal trade study between four stereo codecs and one multichannel codec. Four codecs provided the output count I wanted, but I underestimated how much control, clocking, configuration, and validation work came with repeating the same device four times.

The address conflict arrived late

All four codecs shared a fixed I²C control address. I found that conflict after substantial routing work, so I added an I²C mux instead of changing the device selection. The mux gave each codec its own control branch.

Firmware still had to select each mux branch and initialize all four codecs in the right order. That setup and recovery behavior was never completed.

The mux resolved the address conflict, but it added another layer of setup and firmware work to an already complex board.

Four copies meant four states

Each codec added a control target, local supply and decoupling network, analog interface, MCLK load, bus-slot assignment, and startup state. The upper-right codec added a second role because it needed both ADC and DAC configuration while the other three primarily served output channels.

Reset behavior was shared and weakly controlled. Each codec was held enabled by a pull-up, so the Teensy could not independently force a known reset state or recover one device. The distributed MCLK network and two TDM buses added more repeated dependencies across the physical board.

Each codec was reasonable on its own. Together, four devices required coordinated control, clocking, reset, slot assignment, and recovery behavior before the board could reach audio testing.

What changed in the next revision

Rev 2 used one CS42526 multichannel codec. That did not make multichannel audio simple, but it reduced the number of control targets, clock loads, analog support circuits, and board-level connections that had to work together.

Four repeated codecs meant four times the setup, control, and validation work. That was the part I needed to account for before committing the PCB layout.

If I used a repeated design again, I would define the initialization and recovery plan, assign every logical channel, and prove one complete path before committing the repeated layout.

A channel count is not an interface specification

Rev 1 had one stereo input and eight outputs, but I had not defined the electrical requirements for the equipment connected to them. I had not set the target levels, impedance, connector arrangement, return path, cable assumptions, or protection requirements.

The outputs were intended for bench inspection and eventual connection to an external amplifier, but that external interface had not been defined.

Reference circuits filled the vacuum

Codec reference circuits informed the coupling and filtering, but they did not define the system around the board. I treated them as more of the interface definition than they actually were.

There were no dedicated output buffers or line drivers. The output network therefore depended heavily on whatever external load would eventually be attached, even though that load had not been selected. Without a defined load, I could not design or test the output stage around a real requirement.

Returns and connectors were unresolved

The two-pin headers likely carried left and right without a dedicated local ground; the external return path was not defined.

The return path extended beyond the PCB into the connector, cable, source, load, enclosure, and power system. Because those relationships were not defined, I could not evaluate noise, common-mode voltage, or fault behavior as one system.

External analog protection was similarly absent. There was no completed strategy for electrostatic discharge, out-of-range voltage, shorted outputs, unknown cable capacitance, or powered external equipment. These gaps belong to the interface definition, not to an afterthought placed beside the connector.

The better order of operations

I would define the voltage, load, connector, return path, and protection requirements first, then prove one representative channel before repeating it across the board.

The topology

Rev 1 accepted external 5 V through a two-pin header. That raw 5 V path powered the Teensy. Separate linear regulators produced the board's main 3.3 V rail, its 1.8 V rail, and an additional 3.3 V rail dedicated to the oscillator and clock section.

The separate clock supply was intended to keep that section quiet and locally controlled. I chose linear regulators because they were simple and low-noise for this prototype.

Three LEDs indicated rail presence, and distributed test points allowed the main rails to be checked during bring-up. Those details made initial power-up more observable than several of the board's other subsystems.

What bring-up actually established

Bring-up confirmed board-level 3.3 V and 1.8 V, the rail LEDs, and basic Teensy power. It did not verify codec-local rails, ripple, thermal behavior, or operation under an audio load.

The missing calculations

The regulators were selected around the expected board current draw. What remained untested was thermal behavior, ripple, transient response, and efficiency under real operating conditions.

Power entry was not fault-tolerant

Rev 1 assumed controlled bench power and had no complete fault or startup strategy. It proved that the board could turn on, not that the power system met operating requirements.

The expected sequence

Rev 1 assumed the rails would rise, MCLK would start, the Teensy would boot, and firmware would configure the codecs. That sequence was neither enforced nor observed.

The codecs were always enabled

Each codec had a pull-up that kept its reset or enable state asserted high. The Teensy could not independently hold all codecs in reset during rail and clock startup, release one device for isolated testing, or recover one device after a control fault.

That made four device states dependent on uncontrolled power-up behavior. The I²C mux could isolate configuration traffic, but it could not force a codec back into a known hardware state. Control-bus selection and reset control solve different problems.

A better design would give the controller control over codec reset so each device could be started, tested, and recovered in a known state.

Readiness was never observed

Firmware had no verified indication that the rails and MCLK were ready. The system also had no defined retry, recovery, mute, or shutdown behavior.

The state machine I would design now

A revised design would hold codecs in reset until rails and MCLK were valid, initialize and verify one device at a time, then enable audio. The behavior after a timeout, brownout, or clock loss should be explicit.

From four layers to six

Rev 1 began as a four-layer idea. Routing four codec sections, two digital-audio buses, a distributed master clock, controller connections, power, and analog I/O became congested enough that the design moved to six layers.

The design used a standard six-layer stackup, but its actual impedance and return paths were not analyzed.

Adding layers solved routing access, but layers alone do not create signal integrity. The placement of reference planes, where a route changes layers, how return current crosses that transition, and how branches are formed still determine the physical current path.

Rules I remembered instead of deriving

I used remembered length targets instead of a timing budget tied to the drivers, receivers, topology, and allowed skew. Matching trace lengths looked disciplined, but it was not enough to define whether the routed system would work.

Topology and return current mattered more

The MCLK network included a source resistor, branches, a test point, four codec destinations, and the mistaken Teensy connection. Those branches and loads mattered more than trace length alone.

A via only changes layers cleanly when its return path can transition with it. That was not planned systematically on Rev 1.

That return path is not a secondary cosmetic concern. Every digital signal is a current loop. The outgoing trace and its reference-plane current together determine coupling, emissions, susceptibility, and what a probe will observe.

A more defensible routing process

I would define the drivers, receivers, timing limits, stackup, topology, and return paths before tuning trace lengths. Length matching should support the design, not substitute for understanding it.

What Rev 1 did well

Rev 1 included useful test access to MCLK, I²S/TDM, I²C, rails, ground, and analog connectors. That access supported board-level rail checks and the Teensy-removed MCLK measurements, but it did not make the subsystems independently testable.

Observation without control

Because the MCU, mux, clocks, codecs, and analog network stayed connected, a measurement could not isolate the failing subsystem. There was no easy way to disconnect a bus, inject a known source, substitute a clock, or reset one codec without affecting the rest of the board.

A staged proof plan

A better debug layout would let each subsystem be tested separately: local rail checks, known clock and audio injection, reset control, and a clear place to measure each stage.

Designing for evidence

Future boards need a few deliberate control and measurement boundaries: disconnects, injection points, reset access, current sensing, and compact probe points.

The reconstructed bring-up sequence

The assembled board was first inspected and checked for obvious unpowered shorts. The Teensy was left out during the initial carrier-board power-up so the base rails and clock network could be observed without involving the controller module.

Board-level 3.3 V and 1.8 V were measured at test points, and the three power-status LEDs illuminated. Approximately 12.288 MHz was then observed at the MCLK test point and at the four codec areas. Different locations showed different qualitative overshoot and ringing behavior.

The Teensy was installed later. It powered, accepted programming, and ran basic blink firmware using the general-purpose indicators. The best current reconstruction places recognition of the mistaken MCLK-to-3.3 V carrier connection around this stage, but the exact discovery sequence is not securely documented.

Work stopped instead of continuing through codec initialization, TDM setup, or audio testing. The sequence is reconstructed from board evidence and memory, not a lab log.

What was never validated

No codec, TDM, USB-audio, DSP, or analog path was validated. Local codec rails, analog performance, protection, and power behavior also remain unmeasured.

Why this boundary is the result

Rev 1's value is the clear record of what basic bring-up proved and what it exposed for Rev 2.