Platform index / Digital mixing console
Allen & Heath Qu-16 / Qu-24 / Qu-32 (+ Qu-Pac / Qu-SB)
The original Qu is a 2014 multi-chip embedded design — an NXP Cortex-M control MCU, an Analog Devices Blackfin audio DSP and an FPGA — with every processing block included and no paid-add-on lock. It shares nothing but a brand with the SQ-derived 2nd-gen Qu.
The load-bearing finding. The 5.8 MB .QUU update is a bare-metal Cortex-M image — its crash handler dumps CFSR/HFSR/BFAR — with A/B host sections and BCC checksums, no Zynq and no paid add-ons. This is the machine the new Qu replaced, not a relative of it.
Verdict. A period-typical 2014 embedded mixer — Cortex-M control, Blackfin audio, an FPGA, bare-metal, unsigned, everything included. Its only real relationship to the SQ-lineage 2nd-gen Qu is the badge; nothing carries across. A poor and largely pointless rehosting target, and now EOL at V1.99.
Method
Static analysis of the Qu-32 V1.99 (build 4583) .QUU update and the V1.99 release notes. No hardware inspected. V1.99 (Nov 2025) is the final maintenance release; one firmware per model (Qu-16/24/32/Pac/SB).
Artifacts examined
Qu32UpdtV1_99_4583.QUU— 5.8 MB, a sectioned flash image (BCC-checked Host Section A/B), FAT-basedRelease Notes Qu firmware V1.99.pdf— V1.99 covers Qu-16, Qu-24, Qu-32, Qu-Pac, Qu-SBHow to Update Qu Firmware.pdf
No manufacturer firmware, binaries or documentation are redistributed here. Artifacts are referenced by name and version only. See the method and legal statement for the basis on which this analysis was performed and the boundaries it observes.
Hardware architecture
| Item | Finding | Confidence |
|---|---|---|
| Control MCU | An ARM Cortex-M (ARMv7-M) — the crash handler dumps CFSR/HFSR/BFAR/MMFAR/DFSR, the Cortex-M fault registers, and lwiplpc points to an NXP LPC part. Bare-metal, no RTOS or Linux | Verified |
| Audio DSP | Analog Devices Blackfin (ABF5T → ADSP-BF5xx) as a separate audio processor — CPU ID, Audio ID and Surface ID are distinct devices | Inferred |
| FPGA | An FPGA is present (FPGA not Initialised); vendor and part not identified from the image | Verified |
| Topology | A multi-chip board — distinct CPU, Audio and Surface processors, each with its own ID and firmware version — not a single SoC. The opposite of the 2nd-gen Qu's Zynq | Verified |
Software architecture
| Item | Finding | Confidence |
|---|---|---|
| Operating system | None — bare-metal (a Cortex-M hard-fault handler, no RTOS/Linux strings) | Verified |
| This build | Qu-32 firmware V1.99 build 4583 (2025-10-02) — the final maintenance release for the range | Verified |
| Range | V1.99 covers Qu-16, Qu-24, Qu-32, Qu-Pac and Qu-SB, as five per-model firmware files | Verified |
Update path & security model
| Item | Finding | Confidence |
|---|---|---|
| Update validation | CRC/BCC integrity only, no signature. The sectioned .QUU carries a BCC per section (BCC Matches for Host Section A/B, BCC Fails … restarting) with CRC checks on scenes and libraries (Bad CRC from external Library …). No RSA/SHA/signing — the AES strings are audio | Verified |
| Recovery | A/B host sections provide a failed-update fallback (BootUpdateCheckHostBCCSectionA, restart-on-BCC-fail) | Verified |
| Add-ons | None. There is no paid add-on or entitlement system — every effect and processing block ships enabled. The only Unlock is the front-panel screen lock. A sharp break from the SQ-derived 2nd-gen Qu | Verified |
These rows describe how a platform validates a firmware image, because that is a structural fact about its architecture. They are not a vulnerability disclosure and no exploit, bypass or circumvention technique is published here. Licensing and entitlement mechanisms are out of scope throughout — seescope boundaries.
What is programmable
- 1Interoperability, not rehosting
The Qu speaks MIDI/TCP control and the Qu-Pad/Qu-You apps and takes dSNAKE I/O. Anything that motivates looking at the firmware is better served here.
- 2Rehosting is a poor fit
A multi-chip 2014 embedded design with no single SoC to replace, and the audio living in Blackfin + FPGA behind opaque interfaces. There is no equivalent of the SQ's one-Zynq target.
- 3The .QUU container
Simple and unsigned — sections guarded by a BCC — so trivially repackable for integrity. There is little reason to, and it buys no access to the audio path.
Traps
Mistakes this analysis actually made, or came close to making. They are recorded because each one produces a plausible-looking wrong answer rather than an obvious failure.
- Do not conflate with the 2nd-gen Qu (Qu-5/6/7): that is a Xilinx-Zynq, SQ-derived platform; this shares only the name.
- The
Unlockstring is the front-panel screen lock, not a paid add-on — the classic Qu has no entitlement system at all. BCCis a block-check integrity value, not a signature; the A/B sections are for update resilience, not authentication.
Open questions
- The exact parts — the NXP LPC control MCU, the Blackfin variant and the FPGA vendor — are not pinned from strings alone.
- How the three processors (CPU / Audio / Surface) partition work and communicate is unmapped.
- Whether the surface-less Qu-Pac / Qu-SB differ internally beyond the surface MCU.
Status of this entry. A written teardown exists and its claims carry evidence citations. Nothing on this page has been verified against physical hardware — no unit of this platform has been opened, connected to or modified.