[sdiy] Teensy 3.6 180MHz ARM Cortex M4F with 6 in, 8 out audio CODEC

Robin Whittle rw at firstpr.com.au
Thu Jan 4 11:08:47 CET 2018

Here is a description of something I plan to do, but it may be later in
the year before I have time to get it going, even at the most basic
level.  It involves a 180MHz NXP Cortex M4F MCU in a Teensy 3.6
devboard, coupled to a 6 in, 8 out CODEC from Cirrus Logic - the CS42438
(USD$12 Q1 Mouser):


This can be expanded to 8 ADC channels in total by way of a separate
stereo ADC chip.

Since the MCU, hereafter the "K66":


has two input data lines and two output data lines on its I2S module, it
would be possible to run two of the CS42438 chips for 12 in, 16 out, and
with another two stereo ADC chips, make it 16 in.

The CS42438 would run with +5V for its audio circuitry and 3.3V for its
I2S data and SPI control interfaces.  I probably don't need the control
interface.  The Teensy 3.6 with its K66 runs from 3.3V too.

The DACs have differential output pins.  The ADCs have differential
inputs, and I think it is necessary to drive them that way.  If only one
is driven, and the other connected to a substantial capacitor to ground,
then the ACD can produce a full scale output, when so configured, but
overloading the one pin causes wraparound - disastrously loud distortion
from the top of the signal range to the bottom.  This shows that in this
mode, output is merely being bit-shifted by one.  If the two pins are
driven differentially, then overloading results simply in clipping.

I haven't read the datasheet in detail, but the CODEC can handle 24 or
16 bit data, and the DACs can handle data at 192ksps, 96ksps, 48ksps or
slower.  The ADCs have two modes for up to 48ksps and 96ksps output, but
I think the sigma-delta modulator runs at the same speed, with the
difference being in the decimation filter.  (BTW, I have made several
attempts to fully understand how it is possible to get such
extraordinary signal-to-noise performance from these sigma-delta ADCs,
and I never really understood it to my satisfaction.  I don't believe
they can cope perfectly with arbitrary waveforms, such as full-scale
square waves or full scale narrow rectangular pulses, but they clearly
work well with most music and acoustic signals.)

The CS42438 is in a 52 pin MQFP (Metric Quad Flat Pack) with 0.65mm pin
centres.  This is nice and compact, and I guess I will be able to
hand-solder these.  I ordered a MQFP-52 adapter board:


There is also a kit with two of these, a stencil and some solder paste,
for DIY reflow:


If I was hand-assembling small quantities of PCBs with these chips, I
would probably use the stencil approach and improvise some kind of
mini-reflow oven using an inverted old solder pot or similar, with a hot
air gun under that part of the PCB.

AKM make multichannel CODECs too, including one with 6 in and 12 out:


However, these and the 6 in, 8 out CODECs use a larger 80 pin LQFP
package, with 0.5mm pin spacing, and I think these would be more
difficult to solder and service in the long-term.  Also, their audio
section only runs on 3.3 volts.

TI's biggest multi-channel CODEC is 6 in, 8 out:


but its package is equally fussy - a 0.5mm pin spacing 64HTQFP.

The Teensy 3.6 has a second 32 bit microcontroller (16 pin 3mm square
package) which can cause (via the debug pins and loading a program into
it RAM) the main MCU to auto-load firmware via USB, via an easy-to-use
Teensy loader program anyone can run - with versions for Windows Linux
and Mac.  The file programs the K66's entire Flash memory.  USB firmware
loading can be initiated by pressing a small tact switch on the Teensy,
or, by something done by the K66's firmware to ground the PROG pin,
which is in parallel with the tact switch.  This Teensy can be purchased
from Mouser (USD$32.50) or from the manufacturers.  The second link is
to the schematic and the third to a description of the USB loading process.


This USB user-operated firmware update capability is something I really
want and which I would not like to have to develop myself.  As far as I
know, no other set of small ARM boards has any such capability.

The Teensies seem to be unparalleled in their teensiness - most other
development boards are much bigger.  I don't want to be responsible for
soldering or desoldering 144 pin BGAs, which is what the K66 is packaged
in, and the Teensy has this already done for me, with crystals, USB
connector and, as far as I know, all pins made available via large pads,
most of which are in a 48 pin DIP arrangement.

The Teensy, or anything like it, would give my future product the
ability to be serviceable even if the K66, or more likely its lead-free
solder ball joints, fail - by installing a new Teensy 3.6, pressing the
tact switch to loading in the firmware from a PC, Linux machine or Mac.

At first I assumed that I would solder pins to the Teensy 3.6 and plug
it into a 0.6" wide 48 pin DIP socket.  However, I think this would bend
the Teensy board in a way which unacceptably threatens the BGA joints.
So I would solder the pin strips to the main PCB and so avoid with the
socket cost and reliability problems, with the only cost being that the
service technician in the future may occasionally need to desolder and
resolder the Teensy, rather than unplug it.  Also, I suspect that some
signals are on pads underneath the Teensy 3.6 (the debug pads certainly
are), so there are going to be some soldered flexible wires anyway, even
if a socket was used.

I think the K66 will use about 400mW or so at most, and the CS42438
600mW.  400mW of the CODEC's power comes from the 5V rail.  600mW from
the 3.3V rail means 0.91W from 5V with a linear 3.3V regulator, so the
total power dissipation, not counting op-amps for CODEC inputs and
outputs, would consume about 1.4W.  I might be tempted to add a heatsink
to the CODEC, since such the junction to ambient thermal impedance is 47
C/W for 2 layer PCBs, meaning the chip itself would go to about 30C
higher than the PCB, which itself could easily be running at 50C or more.

Maybe, to ensure a long life of its BGA balls, the K66 should have a
small heatsink too, but that would need to be done so as not to place
any strain on the balls.

There are no-doubt development boards for much faster multicore ARM CPUs
which are not so much for embedded designs, and which are Von Neumann
architecture (shared data and instruction memory) and would typically
run Linux.  However, if such ARM chips have an I2S interface, I think it
would be tricky to write a device driver with sufficient flexibility to
deal with these fancy multi-channel CODECs.  Such chips would work with
external RAM and Flash memory, chew more power and not come in as small
an adaptor board as the Teensy.

I am not aware of anything comparable size to the Teensy 3.6 which is
more powerful.  Of potential interest is this $30 devboard CORE746I:


with a STM32F746IGT6 216MHz Cortex M7 CPU, 240kb RAM, 3 "simplex I2S
ports" (I have not investigated) with an external 64MB SDRAM.  This is
USD$30.  Without the SDRAM, something similar with the same MCU, for


According to the Teensy comparison table:


it can be overclocked to 240MHz.  The datasheet for its MK66FX1M0VMD18:


states on page 17 that 180MHz is the maximum.  This MCU has a Cortex M4F
CPU with floating point and DSP functions, 1.25MB Flash and 256kB RAM.
I would need to write some substantial code to configure the I2S port
and the DMA controller to deal with the data smoothly, and to have some
code which runs reliably to process the and generate the audio samples.

The big deal to me is that this has significant RAM and floating point
capabilities, so audio processing could be done with 32 bit floating point.

The next questions involve compiler, debug probe and IDE.  I want to use
GCC and GDB, for full standard C/C++ and potentially some assembler.  I
do not want anything less than C++, or to rely on GPL libraries - for
both reasons Arduino is not suitable.  Also, Arduino does not support
full-scale debugging.

It looks like I will be able to use NXP's free (beer) MCUXpresso IDE,
which comes with examples and libraries suitable for this specific K66
MCU.  It is Eclipse-based, for Windows, Linux and Mac.  I assume the
library licenses are OK for the closed source firmware I would develop
for a commercial product.

For AUD$36 (element14) I have ordered a highly capable debug probe, the


Although the particular MK66FX1M0VMD18 MCU is not listed as being
supported by the LPC-Link2 (I guess it comes from the Philips part of
the recent merger, while this MCU comes from the Freescale part), it
does in fact work with the MK66FX1M0VMD18.

To get it to work with the Teensy 3.6, some simple modifications are
required.  With a little more work, a third pin for "Serial Wire Viewer"
AKA "SWO Trace" could be connected to the debug probe.  I understand
enables the MCU to continually export large volumes of data which the
debug probe and suitable software in the IDE can record and display in
various ways, including real-time display of the target firmware's
operation, the MCUs registers, and whatever data is specifically
streamed to this port by printf() statements and the like in the
firmware itself.

The MK66FX1M0VMD18 itself is a Harvard architecture chip (separate
instruction and data memory systems) and has 6 hardware breakpoints,
plus some other features I don't yet understand.

This thread at NXP.com links to the modification instructions, a report
of the Teensy 3.6 working with the LPC-Link2, and some further
discussion of "Serial Wire Viewer".


 - Robin

More information about the Synth-diy mailing list