SAI for Kinetis K Series MCUs: Serial Audio Interface and I2S Training

Introduction

Hello, and welcome to this presentation of the Serial Audio Interface (SAI) module for Kinetis K series MCUs. You may also have heard SAI referenced as Integrated Interchip Sound (I2S). These terms are all used interchangeably. In this session, you'll learn about the SAI, its main features, and the application benefits of leveraging this function.

Agenda

This session will cover:

• An overview of the SAI module itself
• The on-chip interconnections and inter-module dependencies
• Hardware and software configurations
• An example use case
• Frequently asked questions

1. Module Overview

First, let's start with an overview of the module.

SAI Features and Application Benefits

Features:

• A transmitter and receiver supporting up to two data channels with independent clocks. For the exact number of data lines, please refer to the device reference manual.
• The word size, also known as sample size, is variable and can range from 8 to 32 bits.
• The word size for the first word can be configured separately from the remaining words in a frame.
• The SAI module supports an 8-word first-in, first-out (FIFO) buffer, which reduces the number of interrupts or module DMA requests. Please refer to the device reference manual for the exact FIFO size.

Application Benefits:

• Asynchronous transmitter and receiver, useful for applications like a headset implementation requiring audio playback at 48KHz and recording audio at 16KHz.
• Synchronous transmitter and receiver reduces pinout for applications with playback and recording at the same sampling frequency.
• The SAI module can handle up to 32 words, allowing for multi-channel audio implementation.

SAI Module Block Diagram

The SAI module has independent clocks for the transmitter and receiver, allowing both synchronous or asynchronous operation.

Diagram Description: The block diagram shows the SAI module connected to the MCG (Microcontroller Clock Generator) and DMA MUX (Direct Memory Access Multiplexer). The SAI module itself is divided into Transmitter (TX) and Receiver (RX) paths. Each path includes Control Registers, a FIFO buffer, Bit Clock Generation, and a Shift Register. The Transmitter receives data from the FIFO, synchronizes it with the Bit Clock and Frame Sync, and outputs it via SAI_TX_DATA. The Receiver takes incoming data (SAI_RX_DATA), synchronizes it, and stores it in the FIFO. The diagram also shows various interrupt signals originating from the SAI module, such as FIFO warnings, FIFO requests, word start signals, and sync/FIFO errors. These interrupts are routed to the NVIC (Nested Vectored Interrupt Controller) via the DMA MUX. The module operates using Bus Clock and Audio Clock inputs, and generates or receives MCLK, BCLK, and Frame Sync signals.

• When transmitting data using the SAI module, the FIFO holds the words that need to be sent. The words are sent whenever a new frame starts. At the start of a new frame, the shift register takes words from the FIFO and starts sending them based on the bit clock.
• When receiving data using the SAI module, at the start of a new frame, the receiver samples the data received based on the bit clock. The sampled data is then stored in the FIFO.

I2S is not the only audio protocol that can be used with the SAI; there are variants such as left justified, right justified, PCM, TDM, and others.

SAI Clocking

The master clock (MCLK) to the SAI can be internal or external.

For an external clock source, a master clock in (MCLK_IN) signal is used. In this case, a dedicated oscillator with a frequency multiple of the audio sampling frequency is expected.

Diagram Description: The clocking diagram illustrates clock generation and distribution for the I2S/SAI interface. On the left, the Clock Generation block takes inputs like MCGPLLCLK, OSCOERCLK, and SYSCLK, processes them through a Fractional Clock Divider, and outputs MCLK. MCLK_OUT can be used externally. On the right, the I2S/SAI block receives MCLK (or MCLK_IN) and BUSCLK. It generates BCLK_OUT and uses Frame Sync (FS). The diagram shows connections for TCR2/RCR2, MCR, and MDR registers, which control various clocking aspects like bit clock division, master/slave mode, and multiplexer selections.

• When using an internal clock source, the clock must be divided down to generate the MCLK. To achieve this, the SAI implements a fractional divider that takes the clock from one of the clock sources connected to the multiplexer. The MCLK can be shared through a pin if necessary on MCLK_OUT.
• MCLK is used to generate the bit clock and the frame sync.
• When using SAI as a slave, there is usually no need to select an MCLK, because the bit clock and frame sync are generated externally. The exception would be if the MCU is an SAI slave and the codec is an SAI master that share a reference clock; in this case, the reference clock can be routed through the MCU and out the MCLK pin to the codec.

I2S Requirements

In order to implement the I2S protocol, the following signals are required:

• Frame Sync (FS): This signal is required to specify when a new frame of data will start. The frame sync signal is a clock at the audio sampling frequency. Data is sent on the falling edge of the frame sync. This signal might also be referenced as frame clock, word select, or word clock by other vendors.
• Bit Clock (BCLK): The second signal on the I2S is the bit clock, or sometimes referred to as the serial clock. This clock is used to send or receive the serial data. The speed depends on the sample size. Assuming a 32-bit sample, the serial clock must be 64x the frame sync. Both the frame sync and the bit clock are continuous signals.
• Data Lines: The I2S also requires data lines: TX (Transmit) or RX (Receive).
• Master Clock (MCLK): Finally, all the clocks must use a reference called a master clock. This clock can be 256, 384, or 512 times the frame sync.

I2S Communication Model

The I2S communication protocol needs two devices: a master and a slave. The master device provides frame sync and serial clock to the slave.

Diagram Description: The diagram shows two interconnected blocks: "Kinetis MCU" and "Audio Codec". Arrows indicate the flow of signals. MCLK originates from the Kinetis MCU and goes to the Audio Codec. BCLK and FS also originate from the Kinetis MCU and go to the Audio Codec. TX data flows from the Kinetis MCU to the Audio Codec. The labels indicate that the Kinetis MCU is the Master (provides clocks) and the Audio Codec is the Slave (receives clocks).

In this example, the Kinetis MCU is the I2S master and the audio codec is the slave. Note that there is no MCLK going from the master to the slave. The reason is that the MCLK is used to generate the other clocks. This means the master is the only device with MCLK.

I2S Communication Model – Continued

There are some cases where the MCLK must be fed to the slave, but this depends on the overall system configuration.

Diagram Description: This diagram is identical to the previous one, illustrating the Kinetis MCU as Master and the Audio Codec as Slave, with MCLK, BCLK, FS, and TX signals. It serves to reinforce the master/slave concept.

In this situation (referring to a potential alternative configuration not explicitly diagrammed here but implied by the text), the Kinetis MCU would be the slave since it's receiving clocks from the audio codec.

2. On-chip Interconnections and Inter-module Dependencies

Now, let's talk about on-chip interconnections and inter-module dependencies.

SAI Interconnect Diagram

The diagram displays the SAI module and its relation to other peripherals. As previously discussed, the SAI can be connected to different clock options, from internal and external clocks.

Diagram Description: This diagram shows the SAI module as a central component connected to other system blocks. The MCG (Microcontroller Clock Generator) provides clock sources (MCGPLLCLK, SYSCLK, OSCOERCLK) to the SAI CLOCK block, which generates MCLK. MCLK is then supplied to the SAI module. The SAI module has Transmitter (TX) and Receiver (RX) interfaces. The TX interface connects to a DMA MUX (Direct Memory Access Multiplexer) and outputs data. The RX interface receives data and connects to the DMA MUX. The diagram lists various interrupt sources from the SAI module, such as Tx/Rx FIFO Warnings, Tx/Rx FIFO Requests, Tx/Rx Word Start, Tx/Rx Sync Errors, and Tx/Rx FIFO Errors. These interrupts are routed through the DMA MUX to the NVIC (Nested Vectored Interrupt Controller). The diagram also shows the external clock input (MCLK In) and output (MCLK Out) for the SAI CLOCK block.

The module has several interrupt sources for:

• A FIFO watermark reached
• A FIFO empty or full
• The instance when the FIFO has underrun or overrun
• The instance there's an error with the externally generated frame sync

Transmitter and receiver have independent interrupt vectors.

FIFO watermark and FIFO full or empty can generate a DMA request to offload the CPU and fill or empty the FIFO in the background.

3. Hardware Configuration

Next, let's go over the hardware configurations of the SAI module.

Master Clock Hardware Configuration | Scenario One

The master clock is used to generate the different clocks for I2S communication. The source and values of this clock vary based on the use case.

Let's assume we have a system that plays back sound, which represents the example shown here. A Kinetis MCU and an audio codec are connected through the I2S bus, and there's an 8MHz crystal connected to the Kinetis MCU.

We'll review four different clock connection scenarios.

Diagram Description: This diagram shows a Kinetis MCU connected to an Audio Codec. An 8MHz clock source is connected to the Kinetis MCU. The Kinetis MCU acts as the I2S master, outputting FS (Frame Sync), BCLK (Bit Clock), and TX (Transmit Data) signals to the Audio Codec. There is no explicit MCLK line shown going to the codec in this scenario.

In the first scenario, the Kinetis MCU is the I2S master and generates the master clock internally. In this use case, just the bit clock and frame sync are connected to the audio codec. The advantage for this scenario is that there's no dedicated crystal, which reduces the bill of materials (BOM) cost. The disadvantage is that the jitter generated by the internal fractional dividers might not be suitable for applications where high audio quality is required.

Master Clock Hardware Configuration | Scenario Two

Diagram Description: This diagram shows a Kinetis MCU connected to an Audio Codec. An external clock source of 12.288MHz is connected to the Kinetis MCU. The Kinetis MCU acts as the I2S master, outputting MCLK, FS (Frame Sync), BCLK (Bit Clock), and TX (Transmit Data) signals to the Audio Codec.

In the second scenario displayed here, the Kinetis MCU is the I2S master, and the master clock is sourced from an external oscillator with a specific frequency, say, 12.288MHz. For this scenario, the advantage is that the jitter noise is reduced, which is suitable for applications where audio quality is key. The disadvantage is a more expensive BOM due to the addition of an external crystal.

Master Clock Hardware Configuration | Scenario Three

Diagram Description: This diagram shows a Kinetis MCU connected to an Audio Codec. An 8MHz clock source is connected to the Kinetis MCU. The Audio Codec acts as the I2S master, outputting MCLK to the Kinetis MCU. The Kinetis MCU outputs FS (Frame Sync), BCLK (Bit Clock), and TX (Transmit Data) signals to the Audio Codec.

Scenario three is similar to scenario two, except the Kinetis MCU is the I2S slave and the audio codec is the I2S master.

Master Clock Hardware Configuration | Scenario Four

Diagram Description: This diagram shows a Kinetis MCU connected to an Audio Codec. An 8MHz clock source is connected to the Kinetis MCU. The Kinetis MCU outputs an 8MHz_MCLK signal to the Audio Codec. The Kinetis MCU also outputs FS (Frame Sync), BCLK (Bit Clock), and TX (Transmit Data) signals to the Audio Codec. The Audio Codec is the I2S master.

Lastly, in scenario four displayed here, some audio codecs implement a phase-locked loop (PLL), tuned for audio applications and capable of generating more accurate I2S clock frequencies. If this feature is available on the audio codec, then the 8MHz clock from the Kinetis MCU can be used to provide a master clock to the audio codec. In this scenario, the Kinetis MCU remains as the I2S slave, and the audio codec is the master. The advantages for this scenario are a lower BOM cost and reduced jitter because the audio codec PLL is created for this type of use case.

4. Software Configuration

In this next section, we'll discuss software configuration.

SAI Kinetis SDK Initialization Example

The Kinetis SDK integrates an SAI peripheral driver that can be used to output I2S data.

First, a configuration structure must be filled with:

• The SAI bus configuration (protocol type, channel, master/slave mode, sync mode, clock sources, watermark).
• Whether it will be a master or slave.
• The references that will be used for the clocks and FIFO watermark.

After that, an audio format structure is filled with the actual audio requirements. In the example displayed here, we use 16-bits per sample, with a 44.1 KHz sampling rate. The master clock generated by SAI will be 256 times the sampling frequency, and we want a stereo output.

Once the structures are filled, call the API to initialize the module, register a callback for receiving notifications, and finally, send data as required.

Once the application is done sending data, the SAI transmitter can be stopped, and if required, the peripheral driver can be de-initialized.

Example code snippet (conceptual):

// Example configuration structure
sai_user_config_t tx_config;
tx_config.protocol = kSaiBusI2SType;
tx_config.channel = 0;
tx_config.slave_master = kSaiMaster;
tx_config.sync_mode = kSaiModeAsync;
// ... other configuration parameters

// Example data format structure
sai_data_format_t format;
format.bits = 16;
format.sample_rate = 44100;
format.mclk = 256 * format.sample_rate;
format.mono_stereo = kSaiStereo;
// ... other format parameters

// Initialize SAI Tx
SAI_DRV_TxInit(SAI_INSTANCE, &tx_config, &tx_state);

// Configure data format
SAI_DRV_TxConfigDataFormat(SAI_INSTANCE, &format);

// Register callback (optional)
SAI_DRV_TxRegisterCallback(SAI_INSTANCE, callback, callback_param);

// Start sending data
SAI_DRV_SendDataInt(SAI_INSTANCE, addr, len);

// Stop Tx
SAI_DRV_TxStopModule(SAI_INSTANCE);

// De-initialize Tx
SAI_DRV_TxDeinit(SAI_INSTANCE);
        

SAI Operation In Low-Power Modes

For battery-powered applications, the SAI can be used in different low-power modes in slave or master mode using an external source for the master clock. For low leakage stop modes, the SAI module is static.

5. Example Use Case

Now, let's review an example use case.

USB Audio Streaming Example

Here, we have a USB audio streaming example, and let's say we want to develop a USB speaker using Kinetis MCUs.

Diagram Description: The diagram shows a laptop/PC connected via USB to a Kinetis MCU. The Kinetis MCU is connected to an Audio Codec via I2C and I2S interfaces. The Audio Codec is connected to headphones.

• For this application, we'll need a Kinetis MCU with USB support to communicate to a PC.
• An audio codec is required to translate the audio data into sound on your speaker.
• The Kinetis MCU will need to configure the audio codec, and let's assume the communication between these devices is I2C.
• Finally, for transferring audio data from the MCU to the audio codec, I2S is used.

USB Audio Streaming Implementation

Diagram Description: This diagram illustrates the data flow for USB audio streaming. Audio data comes from USB into a USB Buffer. A DMA Channel 1 (Ch1) with a Software (SW) trigger moves this data to an Audio Buffer. From the Audio Buffer, a DMA Channel 0 (Ch0) with a TX FIFO Watermark trigger moves the data to the SAI TX FIFO. Finally, the SAI TX interface transmits the audio data.

In this example, the audio data is received from USB into a buffer. We can use a DMA channel to take this data and move it to a buffer dedicated for the audio samples.

A second DMA channel can be used to move the data from the audio buffer to the SAI TX FIFO. This DMA will be triggered by the SAI TX FIFO watermark signal.

With this use case, the CPU can handle other tasks such as audio synchronization. There is no need to send audio data to the audio codec, since everything is done in the background.

6. SAI Frequently Asked Questions (FAQs)

Finally, some frequently asked questions about the SAI module:

FAQ: My audio codec has WS, SCK and TX data; how can I connect it to a Kinetis device?

There are different names for the I2S lines, which might be confusing when trying to interface an audio codec with a Kinetis device. The table below shows a few examples of the different line names and how they relate to Kinetis devices.

FAQ: Is the SAI capable of multichannel audio?

Yes, the SAI module is capable of multichannel communication either by using time division multiplexing, which is a method that sends all channel data on the same data line, or by assigning different transmit or receive lines to different channels. Time division multiplexing may also be referred to as "network mode."

References

This concludes our presentation on the SAI Module for Kinetis K series MCUs.

More information about the SAI module can be found in the application notes listed here:

• App notes:
  • AN4800: An I2S (Integrated Interchip Sound Bus) Application on Kinetis
  • AN4369: Audio Output Options for Kinetis
• Website: Freescale.com/Kinetis
• Community: community.freescale.com/community/Kinetis

We also invite you to visit us on the web at Freescale.com/Kinetis and check out our Kinetis community page.