Reconfiguration

The CY8C29466 is reconfigurable at two distinct timescales, and the interplay between them defines how the ESP32-PSoC relationship works. Tier 1 is fast — the M8C core writes configuration registers while the chip is running, swapping a full analog topology in under 12 microseconds. Tier 2 is slow — the ESP32 reprograms the PSoC’s flash via the ISSP protocol, replacing the entire firmware image in a few seconds. Tier 1 is an instrumentalist’s hands on the keys. Tier 2 is an organ builder changing the ranks.

Electronic topology switching in analog synthesizers has a forty-year history, but until recently it operated exclusively at the patch level — something you set before playing, not something that changed while notes sounded. The Oberheim OB-8 (1983) was the first instrument to reconfigure an analog filter electronically, using CMOS switches to rearrange a CEM3320 between two modes. The Oberheim Xpander (1984) expanded this dramatically to fifteen filter response curves derived from weighted pole-mixing combinations, and it remains the high-water mark for per-voice topology variety in a production instrument. But the Xpander’s filter mode was a patch parameter — you selected it, saved it, recalled it, and it stayed fixed for the duration of performance.

A new generation of instruments has begun to change this. The AJH Synth Xpander-inspired VCF module (2024) placed the pole-mixing coefficients under voltage control, enabling CV-driven mode selection at audio rates. The Future Retro Transfer (2024) offers analog morphing between sixteen filter modes. The UDO DMNO (2025) features dynamically switchable filter topologies per voice. These represent genuine progress toward dynamic analog reconfiguration, but all operate within a predefined set of modes — the circuit topology is fixed at design time, and what changes is which configuration of that fixed topology is active.

Timbre resolves this constraint by making topology reconfiguration a register write operation — not a selection from a menu, but an arbitrary rewiring of the analog fabric. The Lineage page traces this evolution from patch cables through electronic switching to PSoC register writes.

Tier 1 — Runtime Register Writes

The M8C core can write any analog configuration register during normal operation. A single register write takes 2–4 CPU cycles (~100–200ns at 24 MHz). Seventeen internal registers control a full analog topology swap across all 12 blocks — at the conservative 12 MHz clock rate, the entire operation completes in 136 CPU cycles, under 12 microseconds. At 24 MHz, it is roughly half that.

This is the mechanism behind mid-note topology switching. A held note can transition from bandpass self-oscillation to relaxation oscillation, or from lowpass to bandpass to highpass filtering, without releasing the key. The registers involved are the SC block control registers (ASCxxCR0–3) for capacitor ratios, the column clock registers for SC clock divider (pitch), the analog mux registers for input/output routing, and the control register bits for block enable/disable.

What changes at runtime	Mechanism	Typical latency
SC clock divider (pitch)	Column clock register	~100–200 ns
Capacitor ratios (cutoff/Q)	SC block CR registers	~100–200 ns
Input/output mux routing	Analog mux registers	~100–200 ns
Block enable/disable	Control register bit	~100–200 ns
Comparator threshold	Type C block reference select	~100–200 ns
Gain settings	Capacitor network selection	~100–200 ns
Full topology swap (all 12 blocks)	17 coordinated register writes	< 12 us

The constraint is that all register values must be anticipated by firmware logic already in flash. The M8C can only write values its code knows about. If you want an oscillation mode the current firmware does not implement, you need Tier 2.

Two Approaches from AN2104

Cypress Application Note AN2104 (“PSoC 1 Dynamic Reconfiguration with PSoC Designer”) describes two strategies for implementing runtime reconfiguration.

PSoC Designer Overlays are the IDE-native approach. You define multiple hardware configurations in the graphical editor, and the tool generates overlay code that loads and unloads complete block arrangements. The API is high-level — LoadConfig_oscillator(), UnloadConfig_filter() — and the toolchain manages the register details. This is convenient but heavy: each overlay carries a full configuration image, and the load/unload cycle is more ceremonial than a raw register write needs to be.

DIY register manipulation is the lean alternative. You create two projects in PSoC Designer with different block configurations, diff the generated PSoCConfigTBL.asm and PSoCConfig.asm files, and write custom routines that flip only the registers that differ between the two. These routines are small — roughly 30 bytes each — and execute in deterministic time. For Timbre, where every byte of the 32 KB flash matters and configuration transitions need to be fast and predictable, this is the preferred approach. The PSoC Designer overlay system remains useful for initial prototyping and for extracting the register values that the DIY routines will use.

Glitch Behavior

Reconfiguration is atomic at the individual register level but not glitch-free across multi-register transitions. Switching the capacitor network of an SC block can produce a transient as the charge stored on the old capacitor configuration encounters the new one. Phase 1 characterization will determine which transitions produce audible artifacts and which are clean enough for mid-note use. Some transitions — particularly those that change only the clock divider or gain without altering the capacitor topology — are expected to be clean.

Tier 2 — ISSP Flash Reprogramming

ISSP (In-System Serial Programming) is Cypress’s protocol for rewriting the PSoC’s entire flash from an external host. When the host is another microcontroller rather than a dedicated programmer, Cypress calls this HSSP (Host-Sourced Serial Programming). Either way, the result is the same: a complete 32 KB firmware image written to the PSoC, replacing everything — M8C code, configuration tables, register initialization values, and operating logic.

The protocol uses three wires: SDATA (bidirectional data), SCLK (clock), and XRES (external reset). Each ISSP vector is 22 bits long, with the host writing and reading SDATA on the rising edge of SCLK and the target responding on the falling edge. Maximum clock rate is 8 MHz. Flash is programmed in 64-byte blocks, with a wait-and-poll handshake after each block where the target pulls SDATA high while the erase/write operation completes (up to 100 ms worst-case per block). A full 32 KB reprogram takes several seconds.

The architectural gift of the CY8C29466 is that SDATA and SCLK share pins with I2C. SDATA is P1[0] (I2C SDA) and SCLK is P1[1] (I2C SCL). The same two wires that carry parameter updates during performance carry firmware images before a session. No additional wiring is needed for the “organ memory” feature — it is built into the pin assignment.

The programming sequence from the ESP32’s perspective:

1. Assert XRES on the target PSoC, holding it in reset
2. Switch from I2C master mode to ISSP bit-bang mode on the same pins
3. Stream the new firmware image via the ISSP protocol
4. Release XRES — the PSoC boots with new firmware
5. Resume I2C communication

Organ Memory

The analogy is deliberate. A pipe organ has stops — physical ranks of pipes with fundamentally different tonal character (Diapason, Reed, Flute, String). The organist selects ranks before playing; they do not change mid-performance. Timbre’s Tier 2 works the same way. Before a session, the ESP32 programs each voice chip with a firmware image that defines its voice architecture — not just which register values to use, but what firmware logic interprets parameters, how the analog blocks are organized, and what oscillation modes are available. Different images produce fundamentally different instruments, the way different organ ranks produce fundamentally different timbres.

The ESP32 stores multiple 32 KB firmware images in its flash (at 4 MB, it can hold over 100 voice architectures). Selecting a new architecture means reprogramming the target chip — a few seconds of downtime per voice, acceptable between songs or during setup.

Open-Source Implementations

Project	Platform	Notes
micropython-issp	MicroPython / PyBoard	Pure Python, most portable. MicroPython runs on ESP32, making this close to a drop-in starting point. Includes .hex file parser.
arduino_hssp	Arduino	Based on Cypress AN44168, ported by Dirk Petrautzki. Includes flash dump capability and STK500-compatible protocol with extended commands.
AN44168 reference code	Portable C	Official Cypress code, originally targeting CY8C29466 as host. Designed to be ported to any microcontroller with minimal changes.

Operating Models

The two reconfiguration tiers create a design space for the ESP32-PSoC relationship. Four operating models occupy that space, each trading off flexibility against complexity.

Model	Name	Tier(s)	ESP32 role	PSoC role	Reconfiguration speed
A	Smart Peripheral	1	Sends parameters	Interprets and applies	Microseconds
B	Dumb Fabric	1	Sends raw registers	Proxies writes	Microseconds
C	Organ Memory	2	Reprograms flash	Boots and runs	Seconds
D	Hybrid	1 + 2	Both	Both	Both

Model A — Smart Peripheral

This is the current architecture. The PSoC firmware understands voice parameters — it receives high-level I2C commands like {cutoff: 2000, Q: 0.8, mode: BANDPASS} and translates them into register values internally. The ESP32 does not need to know the register map. The PSoC is an autonomous instrument module that speaks a musical parameter language.

The limitation is that every timbre configuration must be anticipated at firmware-write time. The PSoC can only produce sounds its firmware was designed to produce. Adding a new oscillation mode means writing new PSoC firmware.

Model B — Dumb Fabric

The ESP32 calculates all register values itself and sends them directly over I2C. The PSoC firmware is minimal — a register write proxy. This inverts Model A: maximum flexibility (any configuration the hardware supports, without firmware changes) at the cost of higher I2C traffic and the requirement that the ESP32 carry full knowledge of the PSoC register map.

Model B is most valuable during Phase 1 characterization, where the ability to poke individual registers from the ESP32 without reflashing the PSoC accelerates experimentation.

Model C — Organ Memory

The ESP32 stores multiple complete PSoC firmware images and programs them via ISSP before a session. Different images represent fundamentally different voice architectures — not just different register presets, but different firmware logic. One image might implement a subtractive synth topology; another might configure the blocks for FM-style interaction; a third might dedicate all 12 blocks to a single massive filter chain.

The downside is speed. Programming takes seconds per chip, so architecture changes happen between songs, not between notes.

Model D — Hybrid (Recommended)

Model D combines A and C, with B as a diagnostic escape hatch. The lifecycle has three layers:

Voice architectures (Tier 2, ISSP) define the fundamental character of a voice — how the analog blocks are organized, what oscillation modes are available, what the parameter space looks like. These are loaded before a session, like selecting organ ranks.

Parameter control (Tier 1, I2C) provides real-time expressive control within a voice architecture — pitch, cutoff, resonance, VCA gain, oscillation mode switching. This is the performer’s hands on the keys.

Diagnostic mode (Tier 1, raw registers) is a special I2C command prefix that bypasses the firmware’s parameter interpretation and writes registers directly. This exists for Phase 1 characterization and development, not for production performance.

stateDiagram-v2
    classDef teal fill:#134e4a,stroke:#0d9488,color:#ccfbf1

    [*] --> SessionStart
    SessionStart --> ISSP_Load: ESP32 selects voice architecture
    ISSP_Load --> Ready: Flash complete (~3s per chip)
    Ready --> I2C_Control: Normal performance
    I2C_Control --> Ready: Parameter updates (Tier 1)
    I2C_Control --> DiagMode: Raw register prefix
    DiagMode --> I2C_Control: Exit diagnostic
    Ready --> ISSP_Load: Song change / preset recall

    class SessionStart,ISSP_Load,Ready,I2C_Control,DiagMode teal

ISSP and the I2C Mux

In a 16-voice system, the TCA9548A I2C multiplexer sits between the ESP32 and the voice chips. This works for normal I2C traffic, but ISSP is not an I2C protocol — it is a proprietary bit-bang sequence that happens to use the same physical pins. The mux cannot pass ISSP traffic.

The solution is per-chip XRES lines. An I/O expander (MCP23017 or PCA9555) gives the ESP32 individual reset control over each PSoC. To reprogram a specific chip, the ESP32 asserts that chip’s XRES (putting it into programming mode), disables the mux channel, and bit-bangs ISSP directly on the shared bus. All other chips are in normal operation and ignore the bus traffic — only a chip held in reset responds to ISSP vectors. After programming, the ESP32 releases XRES and re-enables the mux for normal I2C.

Approach	Complexity	Additional wiring	Notes
Per-chip XRES via I/O expander	Low	One GPIO per chip from expander	Clean isolation, recommended
Dedicated ISSP bus	Medium	Separate SDATA/SCLK lines	Uses additional ESP32 pins
Mux bypass with analog switches	High	Analog switch matrix	Over-engineered for this application

The per-chip XRES approach has a secondary benefit: individual chip reset capability is useful for error recovery during normal operation, independent of ISSP.

References

Application Notes

Document	Title	Relevance
AN2104	PSoC 1 Dynamic Reconfiguration with PSoC Designer	Core reference for Tier 1 runtime reconfiguration — overlay API and DIY register manipulation
AN44168	PSoC 1 Device Programming Using External Microcontroller (HSSP)	Reference code for Tier 2 ISSP programming from an external MCU
ISSP Programming Spec	PSoC 1 ISSP Programming Specifications (Doc #001-13617)	Protocol-level specification for ISSP vectors, timing, and security
AN2014	Basics of PSoC 1 Programming	Quick-start guide to programming interface connections and modes

Open-Source Projects

Project	URL	Notes
micropython-issp	github.com/twisteroidambassador/micropython-issp	Pure MicroPython ISSP implementation, closest to ESP32 drop-in
arduino_hssp	github.com/trou/arduino_hssp	Arduino port of AN44168 with flash dump and STK500 extensions

Cross-References

For the analog block architecture and register-level details of the CY8C29466, see CY8C29466 Reference. For how the reconfigurable fabric produces sound through self-oscillation modes, see The Voice Engine.