How do both HCI Commands and Audio Data go over a Single UART on a Bluetooth HCI Audio Module?

Vela IF310

Answer

On a Bluetooth HCI audio module, HCI commands, events, and audio data can and often do go over the same physical UART interface, although separate interfaces are frequently used for higher-quality audio. The Bluetooth specification defines how different packet types are multiplexed over a single serial link. 


Here is a breakdown of how they share the interface or use separate ones. 

1. Same UART Interface (Multiplexing) 

In many embedded systems (dual-chip configurations), a single UART with hardware flow control (RTS/CTS) connects the Host (MCU) and the Controller (Bluetooth Module). 

  • HCI Packet Types: The UART transport layer (e.g., H4 or 3-Wire) supports5 types of packets: Command, Event, ACL Data, Synchronous Data (SCO/eSCO), and ISO Data.
  • Multiplexing Mechanism: Each packet starts with a 1-byte indicator that defines its type, allowing the receiver to distinguish between a command from the host and audio data (Synchronous Data packet) coming over the same TX/RX lines.
  • Packet Types on UART:
    • HCI Commands/Events: Control data.
    • ACL Data: Standard data (e.g., A2DP music streaming).
    • Synchronous Data: Voice/audio (e.g., HFP call).
  • Requirement: To work reliably, especially for audio, Hardware Flow Control (RTS/CTS) is usually required to ensure audio packets don't overflow the UART buffer. 

2. Multiple Interfaces (UART + PCM/I2S) 

For higher-fidelity audio or when the UART bandwidth is constrained, the module will use separate interfaces. 

  • UART: Dedicated to control commands and events (HCI protocol).
  • PCM or I2S: Dedicated to synchronous voice data (SCO/eSCO).
  • How it Works: The Bluetooth chip is configured via UART to send/receive audio through the I2S/PCM pins directly to a codec (e.g., microphone/speaker) rather than passing the audio data back over the UART to the host MCU. 

Summary of How They Share 

If using one UART, the transport layer places framing octets around each packet, converting the stream into distinct packets, which allows the Host/Controller to prioritize commands while managing the steady flow of audio data.