Drumboy Pro Wiki

Specifications HW

CPU & Clock Tree HW

IC2 is the STM32H723ZGT6 (Arm Cortex-M7, LQFP-144) — the single MCU driving every subsystem on Drumboy_Main: SDRAM over FMC, the display and control surface over GPIO, the audio codec over I2S3/I2C3, and MIDI/Sync over two USARTs.

It's clocked from an 8 MHz HSE crystal (Y1, ABM7-8.000MHz-D2Y-T). CubeMX's RCC.* block gives the exact multiplier chain for all three PLLs:

Boot & debug pins

SDRAM HW

IC1 is an IS42S16800J-7TL-TR (128 Mbit, 8M×16, SOP-54), providing 16 MB of external sample memory at 0xC0000000, streamed by the ten instrument layers during playback.

The hardware FMC SDRAM controller times the interface entirely in SDCLK cycles:

Display (LCD) HW

The NT35510 panel carries its own onboard GRAM (graphics RAM) and refreshes the screen from it independently. The STM32 writes commands and pixel data into that GRAM over a 16-bit parallel bus: LCD_D0–D15 map to plain GPIO_Output pins on Port B (PB0–PB15), toggled directly by the firmware's Lcd driver.

LCD_IM0–IM2, the NT35510's interface-mode select, are hardwired via 0 Ω links (R33→+3.3V_DIG, R34/R35→GND_DIG) on Drumboy_Main itself, fixing the panel to 16-bit 8080 parallel mode at power-up. Brightness is switched through LCD_BL.

Backlight power comes from a dedicated boost converter. The panel reaches the board over the 51-pin, 0.3 mm-pitch Hirose FH26W FPC (J2).

Audio Codec HW

IC7, an SGTL5000XNBA3R2 in QFN-33, is the entire analog audio path — headphone amp, line-out DAC and line-in ADC all live inside this one chip. It's controlled over I2C3 and streams PCM over I2S3:

I2S3 runs on its own PLL3-derived kernel clock, in fractional mode: CubeMX reports I2S3.RealAudioFreq at 44.099 kHz.

The codec's supply is electrically separated from the rest of the board — +3.3V_DAC (IC5) and +1.8V_DAC (IC6) are their own LDO outputs, riding on a ferrite-isolated +5V_DAC rail with its own GND_DAC net, distinct from the digital +3.3V_DIG/GND_DIG domain that powers the MCU and LCD.

Control Surface & I/O Expansion HW

The 42 keys and 42 LEDs run behind six MCP23017 16-bit I2C GPIO expanders (U1–U6), split across two I2C buses:

The three input expanders (U1–U3), from Drumboy_Main.kicad_sch — identical circuit, different address strap and net names.

Only the three input expanders (X/A/B) have their INT line wired to an EXTI-capable MCU pin — matching the firmware's GPIO EXTI table (MX_X_INT→PD11, MX_A_INT→PA0, MX_B_INT→PA1). The three LED-driver expanders (C/D/E) are pure outputs and don't need one. I2C3 is shared between the codec and the three input expanders; I2C4 is dedicated to the three LED-driver expanders. Between them, the schematic's net list shows a 12-segment left EQ meter (LED_EQ_A_00–11), a 12-segment right EQ meter (LED_EQ_B_00–11) and 10 layer/pad indicators (LED_KEY_00–09) — plus three simple status LEDs (LED0–LED2) wired directly to PC1–PC3, outside the I2C matrix entirely.

Encoders

The 8 rotary encoders (U8–U15, PEC12R-4017F-N0024) run directly on GPIO, each quadrature A-channel on its own EXTI line:

Encoders 6 and 7 borrow the pins normally reserved for a 32.768 kHz RTC crystal (PC14-OSC32_IN / PC15-OSC32_OUT) — there's no RTC crystal populated on this board, so CubeMX frees the pair up as plain GPIO.

Storage (microSD) HW

The TF-01A microSD socket runs on SDMMC2's native 4-bit bus, with a dedicated hot-plug detect line feeding the firmware's card-present polling:

CubeMX sets SDMMC2.ClockDiv = 32 against the 240 MHz PLL2-derived kernel clock — the same PLL2 output shared with SDRAM.

MIDI & Sync Circuits HW

MIDI In is opto-isolated; MIDI Out and both Sync ports are direct-drive GPIO/UART:

Both MIDI UARTs run at the fixed MIDI baud rate, configured in CubeMX as half-duplex single-wire mode: USART1.BaudRate = USART6.BaudRate = 31250.

I/O & Connectivity HW

Nine physical interfaces reach the outside world: USB-C for power, a microSD slot for storage, and seven 3.5 mm (1/8") TRS jacks — all seven use the same SJ1-3515-SMT-TR footprint (J4–J10). A separate SWD header (not shown below) is used for programming.

Power System HW

USB-C (J1) is the only power input. CC1/CC2 are pulled through 5.1 kΩ resistors (R1, R2) — a fixed default-current sink, no PD negotiation chip. A 0.75 A resettable poly-fuse (F1) sits in series on +5V_USB before it becomes the board's common +5V_BUS.

Domain isolation

From +5V_BUS, nine ferrite beads (FB1–FB9) split the supply into five separate islands, each with its own local ground net — a star topology, not a shared plane:

The five local grounds reconnect to the common GND only through a handful of 0 Ω links (R33, R34, R35, R50, R51, R52, R54 in the BOM) — a deliberate single-point star-ground scheme, on top of the per-domain ferrite filtering above.

LCD backlight supply

The display backlight runs off its own switching supply, independent of the linear rails above: IC3 (MP3302DJ-LF-Z) as a boost converter, with L1 (4.7 µH, NRS5024T4R7MMGJ) as the switching inductor and D9 (MBR0520LT3G Schottky) as the rectifier — a textbook boost topology producing BL_VCC for the backlight LED string, enabled and dimmed from the MCU via LCD_BL (PG14).

ChargePad accessory

ChargePad is a detachable USB-C battery dongle — its own charge-management PCB, not part of the Drumboy_Main KiCad project, so it isn't covered by the net-level detail above. See the User Manual for its LED indicators and charge behavior.

Key Components / BOM HW

Full BOM is generated from KiCad at production/bom.csv. The table below groups the parts that define the platform's capability — passives (0.1 µF/4.7 µF decoupling, 10 k⁠ Ω pull networks, etc.) are omitted for brevity.

Programming / Debug Header HW

Firmware is flashed and debugged over SWD. Wire an ST-Link V2 to the board's SWDIO (PA13), SWCLK (PA14) and GND pins, then flash from STM32CubeIDE.

Firmware Architecture SW

Firmware is deliberately split into two independently-built projects that share one flash device. The bootloader owns sector 0 and is responsible only for validating and installing updates; the application owns the rest of flash and is where the actual instrument runs. This split means a bad application build can never brick the update path itself.

Memory Map SW

Bootloader SW

Controller::initialize() in the bootloader runs three steps in order: turn on the status LED, run updateFirmware() if an SD card is present, then startApplication().

Firmware update flow

Firmware binary format

[0..23]  Header: "RW_DRUMBOY_PRO_FIRMWARE " (24 bytes)
[24..25] versionMajor (uint16_t)
[26..27] versionMinor (uint16_t)
[28..31] firmwareSize (uint32_t)  — payload byte count, must be > 0
[32..35] crc            (uint32_t)  — CRC-32 (zlib/ISO-3309) of the payload
[36...]  Firmware payload

Total file size must equal firmwareSize + 36. Range checks reject major ≥ 10, minor ≥ 100, or a size outside 0 < size < 917504 bytes before anything is written to flash — a zero-size payload is explicitly rejected so it can't erase the application sector without writing anything back.

Application jump

SysMemBootJump = (void (*)(void))(*((uint32_t *)(0x08020000 + 4)));
__disable_irq();
SysTick->CTRL = 0;
__set_MSP(*(uint32_t *)0x08020000);
SysMemBootJump();

LCD status messages

Flash programming happens in 256-bit (8×32-bit word) chunks — the minimum granularity the H72x/H73x flash controller supports.

Application SW

Startup sequence

__disable_irq();
SCB->VTOR = APPLICATION_ADDRESS;   // relocate vector table
SCB_InvalidateICache();
SCB_InvalidateDCache();
HAL_Init();
SCB->CPACR |= ((3UL << 20) | (3UL << 22));      // enable FPU
__set_FPSCR(__get_FPSCR() | (1 << 24) | (1 << 25)); // FTZ + DN
__enable_irq();
SystemClock_Config();
PeriphCommonClock_Config();
System_Initialize();
Sdram_Initialize();
controller.initialize();
while (true) controller.update();

Project structure

Core/
  Src/main.cpp                      — startup, clock/SDRAM init, all ISR callbacks
  Library/Controller/
    Controller.cpp / Controller.h   — central state machine (~1000+ line header)
  Library/Global/
    Global.h                        — shared constants, types, math helpers
    Lfo.h                           — LFO data types and waveforms
    Metronome.h                     — metronome timing + sample playback
    MCP23017.h                      — I2C I/O expander driver
  Library/Lcd/                      — NT35510 driver + bitmap fonts + icons
  Library/Dac/
    Dac.cpp / Dac.h                 — SGTL5000 register-level driver
    SGTL5000.h                      — register address definitions
FATFS/                              — SD card FAT layer
STM32H723ZGTX_FLASH.ld              — linker script (FLASH @ 0x08020000)

The Controller class

Controller is the single global instance and owns every subsystem:

• Hardware peripherals — Lcd, Dac, Sd, Keyboard, Encoder[8], Led (EQ left, EQ right, layer)
• DSP modules — Lpf[], Eq, Filter[], Effect[], Reverb, Metronome, Lfo[]
• Domain data — Layer[10] (instrument + sequencer data per layer), SampleSector[] (SD card sample index)
• Transport state — playActive, recordActive, playArmed, recordArmed, playInterval, songInterval
• Menu state — menu, preMenu, menuTab, selectedLayerNum, selectedBeatNum

Lifecycle is just two calls: initialize() runs the boot sequence (SD init, LCD logo, preset load); update() is the main-loop body — keyboard_action → encoder_action → led_action → lcd_update.

Subsystem & library sizes

Every fixed-size pool the Controller owns is a compile-time constant in Global.h. Menu logic, preset serialization and DSP loops all index against these rather than magic numbers:

Filter, Effect, Reverb, Eq, Lpf, Layer and Lfo are not defined in Controller.h itself — the class only holds instances of them; the struct definitions live in Global.h alongside every other shared type and constant.

Audio Engine SW

The 10 internal sample layers and the external Line In are summed and run through one serial DSP chain: parametric EQ, two multimode filters, two send effects, then a stereo reverb, before splitting to Line Out and Headphone. Each of the 10 layers is independently modulated by the 10-slot global LFO matrix — the same signal path Randomwaves calls the device's "Sonic Architecture" in the user manual.

I2S DMA pipeline

I2S3 runs ping-pong DMA at 32 samples × 2 channels × 2 halves = 128 words per buffer. The half-transfer callback processes samples 0–31; the complete-transfer callback processes samples 32–63.

Signal routing — not a single strict chain

Fig. 5 shows the chain each source ultimately flows through, but every source — Line In, the metronome click, and each of the 10 layers — carries its own MixerInMode and can be summed in at any stage, not just at the head of the chain. A layer can skip the EQ and inject straight into Effect 2, for instance.

Within the chain itself, Filter 1 and Filter 2 are cascaded (Filter 1's output feeds Filter 2's bus, on top of anything routed directly into MIXER_IN_FILTER_1), and Effect 1 → Effect 2 the same way — so the two filter slots and the two effect slots are always in series with each other, never parallel. This per-layer routing is set from the Layer Instrument menu (eq/filter/effect/reverb engage flags plus mixerInMode).

Clock configuration

HSE (8 MHz) → PLL1: PLLM=1, PLLN=68, PLLP=1 → SYSCLK = 550 MHz (VOS0)
PLL2: PLL2M=1, PLL2N=30, PLL2R=1 → FMC, SDMMC clocks
PLL3: PLL3M=1, PLL3N=25 (fractional, FRACN=3289), PLL3P=2 → SPI3/I2S3 clock
AHB divider = 2 → HCLK = 275 MHz

DSP Modules SW

The four processing stages in the audio chain — Filter, EQ, Reverb, Effect — are each their own struct in Global.h, instantiated by the Controller (two Filters, one EQ, one Reverb, two Effects) and driven per-block from processAudioBlock(). All of them are hand-rolled biquad/delay-line DSP against the STM32 FPU — there's no CMSIS-DSP or external DSP library in the chain.

Filter (2 instances — “FIL-1” / “FIL-2”)

A single biquad per instance, coefficients derived with the standard RBJ Audio EQ Cookbook formulas (cosw0/sinw0/alpha, via the fast sine/cosine lookup tables rather than libm). Drive saturation (softKneeClip) is applied to the input before the biquad, not after.

Parametric EQ (1 global instance)

Six biquads in series, same RBJ cookbook math as the Filter module: Low Shelf → High Shelf → 4× Peak. Each biquad is Direct-Form-I with an anti-denormal offset (1e-18) added every sample to keep the FPU out of subnormal-flush stalls during silence.

Reverb (1 global instance)

A Freeverb/Schroeder–Moorer-style design — the classic tuning constants are unmistakable in the comb and all-pass sizes below. Pre-delay and a stereo “surround” delay line sit around the core: input is mono-summed, and the R channel is derived by tapping the L output through the surround delay rather than running two independent reverb tanks.

Comb feedback is derived from the Size and Decay parameters: combFeedback = 0.70 + size×0.15 + decay×0.13; Damping sets the one-pole low-pass coefficient inside each comb's feedback path.

Effects (2 instances, 9 selectable types each)

Each Effect slot is a union of nine distinct DSP engines — only the selected type runs. Every type shares a generic 6-parameter block (A–F, with per-type min/max/label/units), so the menu UI is data-driven rather than hard-coded per effect.

Delay and Chorus are the only two types that need dedicated sample memory, which is why they're the only ones with named SDRAM buffers (RAM_DELAY_0/1, RAM_CHORUS_0/1) — every other type runs on stack/register state only.

LFO & Modulation SW

The 10-slot LFO pool is not an audio-rate modulation matrix — it's sample-and-hold at note-trigger time. Nothing is modulated continuously mid-note; a value is read from the LFO's waveform table once, when a layer's beat fires, and held until the next trigger.

Waveforms & timing

Rate is a musical division of one measure, not Hz: sampleInc = (3200 × rateMultiplier) / barInterval, recalculated whenever tempo or bar length changes. The LFO's read position (sampleCounter) advances once per sequencer tick under interruptPlay() (TIM15) and is reset to 0 at every measure boundary — LFOs are tempo-locked and can't drift out of phase over a long song.

Modulation destinations

Each Layer has 8 independent, optional LFO assignments — any of the 10 pooled LFOs can feed any number of these, on any layer:

At trigger time the firmware samples the assigned LFO's waveform table at the current sampleCounter, centers it (subtract 0.5), scales by Depth and by the destination's range above, then adds it to the layer's base parameter and clamps to that parameter's normal range. Because this only happens on trigger, a slow LFO can land a different value on every hit of a busy layer, while a layer that plays once per bar effectively samples the LFO once per bar.

Sequencer & Rhythm Data SW

Each Layer owns 5 independent song Banks; each Bank holds up to 64 Beats (one per 1/64th-resolution step slot) plus a shared pool of 32 complex-fill slots that any of those 64 beats can borrow from.

Beat bitfield layout

bit 15     active
bits 14-11 fillType    (0–15)
bits 10-8  fillPattern (0–7)
bits 7-4   fillTime    (0–15)
bits 3-0   fillLevel   (0–15)
— plus separate fillTarget, startInterval, endInterval fields

A plain beat (fillType == 0) just plays once at startInterval. A complex fill claims a free BeatFill slot from the bank's shared pool of 32 and generates its BeatMicro sub-hits algorithmically from a template: 3 timing alignments (Standard / Left-aligned / Right-aligned) × 5 level curves (Flat, Step, Hi–Lo, Lo–Hi, Random).

Step-advance algorithm

Controller::layerSong_calculatePlayBeatNum() runs once per bank per playhead update: it scans beatLibrary[0..lastActiveBeatNum] for the next beat (or, if the active beat has a complex fill, its next BeatMicro) whose start interval is ≥ the current play position, wrapping back to beat 0 if none is found. The result feeds layer_playBeat(), which triggers the sample and — per LFO & Modulation — samples any assigned LFOs at that moment.

Timers & Interrupts SW

MIDI & Sync SW

• MIDI RX — USART1, DMA, one byte at a time (midiRxData). HAL_UART_RxCpltCallback → receiveMidiCommand(), which re-arms the DMA.
• MIDI TX — USART6, DMA. enqueueMidiTx() queues bytes; serviceMidiTx() runs from HAL_UART_TxCpltCallback.
• Clock output — driven by the TIM4 interrupt → interruptMidiTxClock().
• MIDI channel — 1–16, held-key select in the Sync menu.
• Sync PPQN — 1–24, held-key select in the Sync menu.

Multiple Drumboy units (or third-party gear) can be chained master→slave using either MIDI or Sync, per the mode tables in I/O & Connectivity.

SD Card & Storage SW

SD Card/System/
  Preset/    — System.rwp, Encoder.rwp (global device state, autosaved)
  File/      — File_001.rwf … File_100.rwf (100 song slots)
  Drumkit/   — Drumkit_001.rwd … Drumkit_100.rwd (100 kit slots)
  Data/      — Inst.lib + one *.ins per instrument (Kick, Snare, Clap, …)
  Image/     — Icon_*.rwi, Image_*.rwi (indexed-palette UI bitmaps)
  Firmware/  — archived update packages, written by the bootloader

Files and drumkits are separate save slots: a File stores Layer Song, Layer Instrument, LFO, Rhythm, EQ, Filter, Effect and Reverb settings together (a full song); a Drumkit stores the same instrument/sound-shaping settings without the song arrangement, so kits can be swapped independently of songs. Each has a 100-slot library on the SD card, browsed from the File (F) and Drumkit (D) menus.

On-disk formats

Every preset/project file opens with a fixed 26-byte ASCII reference string (a per-format magic value, e.g. kFileRef, kDrumkitRef) at offset 0, then payload from offset 25; File and Drumkit files close with a trailing "EOF" marker.

Autosave — debounced write-behind

System and Encoder presets don't save on every change; they use a one-shot debounce timer (TIM6 for System, TIM7 for Encoder) that any relevant setter restarts. If the user keeps adjusting, the timer keeps getting pushed back and nothing is written; once it's left alone long enough to expire, interruptSystemPreset()/interruptEncoderPreset() just raise a dirty flag. The main loop's saveSystemPreset()/saveEncoderPreset() check that flag, briefly disable keyboard input, serialize the live struct to SD at a fixed offset, then clear the flag — a small write-behind cache that keeps routine knob-nudging from wearing out the card.

End-user firmware update (via SD card)

1. Download the latest firmware from randomwaves.io.
2. Power off the device and remove the SD card.
3. Copy the .bin file to the SD card's root directory.
4. Re-insert the card and power on — the bootloader detects and installs it automatically.

Display & Graphics SW

The NT35510 is driven over a bit-banged, 8080-style parallel bus (LCD_CS/RS/WR/RD/RESET/BL GPIOs, NT35510.h defines the full MIPI-DCS-style command set). Every draw call programs a GRAM window and streams pixels into it: Lcd::setAddressWindow() writes the column/row bounds (commands 0x2A/0x2B, high+low byte each) then issues LCD_WRITE_MEMORY_START (0x2C) before the pixel stream.

Drawing primitives

Lcd exposes pixel/line/rectangle/circle/triangle-fill primitives, indexed-bitmap blits (drawRGB16Image / drawRGB24Image, with alpha variants), fadeRGB16/24Image for the animated menu-transition crossfades, and bitmap text/number drawing.

Fonts & icons

Color is RGB565 (RGB16Color) with a large named palette in Global.h — WHITE/BLACK/GRAY_05…GRAY_95 in 5% steps, plus CYAN for the selection highlight and MAGENTA for the selected beat/step.

Input System SW

The 42 keys, 42 LEDs and 8 encoders all hang off six MCP23017 I2C expanders. MCP23017.h is just the register map (IODIRA/B, GPINTEN, DEFVAL, INTCON, GPPU, INTF, INTCAP, GPIOA/B…) — the six instances and their roles are wired up in Controller.cpp:

Layer pad buttons and layer pad LEDs are physically co-located but electrically separate — reads go through keyLayer (0x25), writes through ledLayer (0x22).

Key layout

A layer pad's meaning is entirely context-sensitive: with no modifier held it fires layer_playBeat() (and writes a sequencer step if recording); held together with MUTE/FILL/STYLE it toggles that state instead; held with LFO/LAYER_INST/LAYER_SONG it opens that layer's menu; held with the bank or knob-bank keys it selects a song bank or encoder bank.

LED priority

led_action() resolves what each LED shows in strict priority order, highest first: (1) layer-selection highlight (bank/encoder-bank picker) overrides everything, (2) real-time beat-playback flash (one bit per layer, set/cleared on the beat start/end flags), (3) the stereo EQ/VU meter, peak-hold with linear decay through a 12-step non-linear dB ladder, alternating which channel (L/R) it services each call to spread the I2C DMA load. Every LED write is non-blocking, gated on the I2C peripheral being idle.

Menu System SW

The UI splits into two operational areas: a fully customizable Global Menu for frequently-used functions, and fixed-parameter Dedicated Menus (Rhythm, Metronome, Sync, EQ, Filter, Effect, Reverb, LFO, Layer Inst, Layer Song, File, Drumkit, Mixer) for precise sound shaping.

Knob control

8 assignable knobs behave differently per context. In dedicated menus their function is fixed. In the Global Menu, each of 5 knob banks (40 mappable functions total) is user-defined — hold Select and turn a knob to map it, hold Knob Bank + a Layer key to switch banks. Holding F while turning a knob doubles the change rate (Fast Mode); holding S halves it (Slow Mode).

Menu key reference

Per-layer signal routing is fixed order: Layer → Eq → Filter 1 → Filter 2 → Effect 1 → Effect 2 → Reverb → Line Out, with each stage independently enabled per layer from the Layer Instrument menu. Full parameter ranges for every menu (Rhythm, Mixer, EQ, Filter, Effect, Reverb, LFO, etc.) are documented in the printed User Manual.

Build, Flash & Debug SW

1. Install STM32CubeIDE and open the Drumboy-Pro-App-H723 (and/or -Boot-H723) project folder.
2. Wire SWDIO, GND and SWCLK from the board to an ST-Link V2, then plug the ST-Link into your computer over USB.
3. Build and flash for target STM32H723ZGTX — use the provided debug launch config (Drumboy-Pro-App-H723 Debug.launch / ...-Boot-H723 Debug.launch).

Coding patterns worth knowing before you touch the DSP or ISR code

• Audio buffers are float internally; int32↔float conversion happens only in processAudioReceive / processAudioSend.
• ALWAYSINLINE forces inlining of hot audio helpers (softClip, softKneeClip, amplitudeTodB, etc.).
• D3 RAM (.RAM_D3) holds BDMA-accessible I2C buffers — declare those with __attribute__((section(".RAM_D3"))).
• FTZ is enabled at startup — don't rely on denormal float behavior in DSP code.
• Every encoder action calls an xxx_set*() method that updates the data model and redraws the relevant LCD region in the same call.