Skip to content

A316 Series Product Firmware Development FAQ

Note

  1. The solutions provided in this document are based on the A316-HF-DAC development board. Other A316 series products may have different communication issues and solutions.
  2. The following solutions use the A316-HF-DAC as an example. Other A316 series products may require adjustments based on actual circumstances.

Communication Issues

Q1: XU316 cannot send or receive data when connected to PC or MCU via serial port, and logic analyzer cannot capture data

  • XU316 cannot send or receive data when connected to PC via serial port
  • Logic analyzer cannot capture communication data
  • Messages sent by XU316 are not received
  1. Insufficient MCU response speed
    • MCU is processing other initialization tasks when XU316 has already completed initialization
  2. Power supply issues
    • MCU does not provide power to XU316
  1. Initialization timing issues
    • XU316 sends power-on command (0x00) 4 times after power-up
    • 300ms interval between each command
    • Communication fails if initialization is not completed or no reply is received before the 4 commands finish
  2. Power supply issues
    • Insufficient power supply to XU316 will cause startup failure
  1. Optimize initialization process
    • Prioritize XU316 configuration
    • Ensure initialization is completed before XU316 sends power-on commands
  2. Check power supply design
    • Inspect hardware design
    • Perform hardware modifications if necessary (wire jumpers, short circuits, etc.)

Q2: XMOS-A316 module occasionally sends command 0x00

  • The module occasionally sends command 0x00 via UART
  1. Unstable power supply
    • Power issues may cause the module to reboot
  2. Abnormal reboot mechanism
    • The module only sends 0x00 in two situations:
      • During power-on startup (sent 4 times)
      • After reboot triggered by switching to an unsupported input/output mode
  • Check the stability of the power rails supplied to the module on the baseboard

Device Recognition Issues

Q1: Device is recognized and plays normally on PC, but mobile phone cannot recognize device

  1. Device can be recognized and plays normally on PC
  2. Device cannot be recognized after connecting to mobile phone
  1. Power supply mode issues
    • When mobile phone acts as output device, it should supply power to the device
  1. Power supply mode conflict
    • Mobile phone shows charging status when connected to device
    • Causes mobile phone to fail to output audio normally
  1. Modify device power supply design
    • Check and optimize device power supply section
    • Adjust discharge section design
    • Ensure device can correctly receive power when connected to mobile phone

Protocol and Command Interaction

Q1: Notes for initialization commands 0x00~0x05

  • Follow the principle of “every receive must have a response”.
  • After the module actively sends a command, it must receive a reply from the MCU before it continues sending subsequent commands.
  • Trigger: Sent after module power-up
  • Frequency: Sent 4 times continuously, with a 300ms interval
  • MCU Response: The MCU must reply before the 4 transmissions complete; otherwise the module treats startup as failed and enters default mode

Q2: How to modify device information (command 0x01)

  • Send the command strictly according to the protocol document format.
  • It is recommended to use the official UART protocol test script to test and generate commands.
  • The script includes a device information input function and can be used as a reference.

Q3: Why command 0x20 is not received after startup

  • Command 0x20 is not used in the current firmware, so it will not be sent.

Q4: Why command 0x22 is sent automatically

  • Purpose: Returns current audio stream format
  • Trigger mechanism:
    • Auto-sent within 1 second after a successful startup when there is no operation
    • Auto-sent within 1 second after switching input/output modes

Mode Switching and Audio Control

Q1: Notes for switching input/output mode (command 0x23)

  1. Confirm firmware support
    • Confirm the firmware supports the target mode before sending (refer to firmware description or test script)
    • Sending an unsupported mode may reboot the module
  2. Handshake flow
    • MCU sends 0x23 (switch mode) to module
    • Module returns 0x23 and then sends 0x04 (request confirmation)
    • MCU replies with 0x04 (confirm mode) -> The mode value must match
    • Module sends 0x05 (mode switch completed)

Q2: No sound or no data output after switching mode

  1. Check communication
    • Confirm the module returns the expected commands and the switch succeeds
  2. Check hardware
    • Refer to firmware description and verify pin connections for the selected input/output mode (e.g., I2S/DSD pins)

Q3: Muting or intermittent output during mode switching

  • The MCU repeatedly sends switching commands because it does not receive replies
  • Signal instability during switching
  • Pull Mute pin low before switching (mute)
  • Pull Mute pin high after confirming switch success (resume output)

Q4: Volume control command 0x21 is ineffective

  • 0x21 purpose: Controls the system volume on the PC side (via HID)
  • Flow:
    1. MCU sends 0x21 -> module
    2. Module -> PC (HID volume adjustment)
    3. PC volume change -> module
    4. Module sends 0x24 -> MCU
    5. MCU adjusts the actual DAC/amp volume after receiving 0x24 callback
  • Conclusion: You cannot directly use 0x21 to control DAC volume; you must handle the 0x24 callback.

Other Feature Inquiries

Q1: Does the firmware support MQA

  • Supported: Firmware with suffix "Q" (e.g., xxxx_Q.bin)
  • Not supported: Firmware without suffix "Q"

Q2: Does the module use internal clock or external clock

  • Default: Uses internal clock
  • Switch: Can switch to external clock via command 0x26
  • Limitation: Under SPDIF-IN mode, only internal clock can be used

Audio Output Issues

Q1: No audio output after connecting I2S/DSD data pins

  1. Confirm pin definitions
    • Pin locations for DATA0/½, BCLK, LRCLK may differ across modes (USB-I2S, SPDIF-IN, ADAT, etc.)
    • Refer to the firmware description on the website to confirm pin mapping
  2. Check I2S format
    • Confirm I2S format (I2S, left-justified, or right-justified)
    • Verify it matches the DAC chip requirements
  3. Confirm MCLK connection
    • Some DACs require MCLK to work properly
    • Check whether MCLK signal is connected
  4. Measure waveforms
    • Use an oscilloscope to check if BCLK/LRCLK/DATA lines have valid output

Q2: No audio or intermittent audio for SPDIF input (optical/coaxial)

  1. Clock limitation
    • SPDIF-IN mode can only use internal clock
    • Do not send 0x26 to switch to external clock
  2. Check receiver circuit
    • Verify optical receiver head or coaxial receiver circuit is working
    • Check signal quality
  3. Confirm mode matching
    • The mode value in 0x23 must match a SPDIF mode supported by the firmware
  4. Check signal quality
    • Poor SPDIF signal quality may cause decode failure
    • Try different cables or check connector contacts

Q3: POP noise during mode switching

  1. Use MUTE pin control
    • Pull MUTE pin low before switching
    • Pull it high after switching is completed and confirmed
  2. Configure power-on mute time
    • Use command 0x02 to configure an appropriate mute time (0-65535ms)
    • Give the DAC enough time to stabilize
  3. DAC-side mute coordination
    • MCU also controls DAC mute pin
    • Provides dual mute protection
  4. Check power sequencing
    • Ensure DAC power is stable before unmuting

Q4: How to connect and switch external clock (MCLK) correctly

  1. Confirm clock frequency
    • 22.5792MHz for 44.1kHz family
    • 24.576MHz for 48kHz family
  2. Switch timing
    • Complete clock switching before audio streaming starts
    • Use command 0x26 to switch
  3. SPDIF-IN limitation
    • SPDIF input mode can only use internal clock
    • External clock switching is not allowed
  4. Clock quality
    • External clock jitter directly affects sound quality
    • Use a low-jitter oscillator

Q5: Stuttering or POP noise when switching sampling rates

  1. Use ASRC
    • Some firmware supports ASRC (Asynchronous Sample Rate Conversion)
    • It can smooth transitions between sampling rates
  2. PLL lock time
    • PLL needs time to lock after sampling rate changes
    • The XU316 will mute automatically during this period, which is normal
  3. DAC reset
    • Some DACs require reset when the sampling rate changes
    • Re-initialize the DAC after switching
  4. Buffer settings
    • Increasing audio buffer can reduce stuttering
    • But it also increases latency

Q6: Noise / high noise floor output — how to troubleshoot EMC/EMI issues

  1. Power isolation
    • Separate digital and analog power supplies
    • Use LDOs for audio circuits
  2. Grounding design
    • Use single-point grounding to avoid ground loops
    • Connect digital ground and analog ground at one point
  3. I2S routing
    • Route I2S signals with length matching
    • Keep away from high-speed digital signals (USB, SPI)
    • Add ground shielding if needed
  4. Shielding
    • Shield sensitive analog signals
    • Add shielding can and ground for optical receiver when needed
  5. Oscillator placement
    • Place MCLK oscillator close to XU316 and DAC
    • Reduce clock trace length

Audio Format Support

Q1: What to note when playing MQA audio

  1. Select correct firmware
    • MQA requires Q-suffixed firmware (e.g., XXX_Q.bin)
    • Non-Q firmware does not support MQA decoding
  2. MQA renderer
    • XU316 acts as an MQA Renderer
    • Use with an MQA Core Decoder (e.g., Tidal software decoding)
  3. Software support
    • Player software must support MQA (Tidal, Audirvana, etc.)
  4. Licensing
    • MQA firmware involves licensing; use authorized firmware
    • Unlicensed builds may reboot automatically

Q2: No sound or noise when playing DSD audio

  1. Confirm firmware support
    • Check if the firmware name includes DSD support indicators
  2. Check DSD mode
    • Confirm whether it is Native DSD or DoP (DSD over PCM)
    • Transmission differs between the two
  3. Check I2S data wiring
    • DSD usually uses DATA0 or DATA1
    • Pins may differ from PCM mode
  4. Confirm DAC support
    • Ensure DAC chip supports DSD decoding
    • Ensure DAC is configured to DSD mode properly

Protocol Command Details

Q1: How to parse and use command 0x22 audio stream format report

  1. Trigger
    • Auto-sent 1 second after successful startup
    • Also auto-sent 1 second after switching input/output modes
  2. Parsing
    • Parse sample rate, bit depth, and audio format (PCM/DSD/DoP) according to firmware specification
  3. Display usage
    • Used for UI display, e.g., "PCM 96kHz/24bit" or "DSD64"
  4. Related command
    • After obtaining audio format, you can use 0x28 to set audio delay time

Q2: Value range of command 0x24 volume and DAC mapping

  1. Volume range
    • Typically 0-100 or 0-255
    • Refer to firmware specification for exact range
  2. Log mapping
    • Human loudness perception is logarithmic
    • Map linear values to a log curve before controlling the DAC
  3. Left/right channel handling
    • Ensure left/right volume consistency
    • Some DACs require separate channel volume settings
  4. Difference from 0x21
    • 0x21: MCU -> XU316 -> PC (send direction)
    • 0x24: PC -> XU316 -> MCU (receive direction)

Q3: What is command 0x29 USB connection status detection used for

  • Used to display USB connection status on a screen
  • Improves user experience

Q4: How to configure and use recording (Microphone) feature

  • Not all firmware supports microphone recording
  • Check firmware description to confirm whether it is supported

Driver Issues

Q1: Device cannot be correctly recognized after flashing different configuration firmware

  • During development/debugging, after flashing firmware with different configuration/channel counts
  • The device cannot correctly recognize the current configuration
  • After changing recording channel count, the Windows cache becomes inconsistent with actual configuration
  1. Open Device Manager
  2. Under audio devices, uninstall the recognized audio device
  3. Also remove the driver, then reinstall the driver
  4. Replug the device and confirm it is recognized correctly

Secondary Development Common Questions

The following content is summarized from common XMOS FAQs and is organized from the perspective of secondary development and hardware integration developers.

Interfaces and Modes

Q1: Can I2S input be Master and output be Slave (reverse)?

  • No
  • Input: I2S Slave
  • Output: I2S Master
  • Mode 6 is also: I2S(slave) in -> I2S(master) out
  • Secondary development must follow this clock relationship, otherwise there will be no audio

Q2: How to switch between S/PDIF input 1 and 2?

  • Distinguished by mode number:
    • Mode 3 = SPDIF1 input
    • Mode 4 = SPDIF2 input
  • Switching is done via UART configuration or host tools, not automatic detection

Clock and Sample Rate Conversion

Q1: With 768kHz / DSD512 support, can macOS/Windows run it directly?

  • Windows: Requires official USB driver + UAC2.0
  • macOS: Native driver-free UAC2.0, can run up to 768kHz directly
  • DSD512: Requires player support for DoP or Native DSD
  • The limitation is usually in OS and player, not the module itself

Q2: How many channels can multichannel output support?

  • Standard multichannel USB Audio 2.0 architecture
  • Typically within 2–8 channels (refer to module manual)
  • Secondary development can follow UAC2.0 channel mapping

Hardware Integration

Q1: The module size is 19.5×26×0.8mm. Is it through-pin or SMD?

  • It is an ultra-thin module
  • Board-to-board or pad-solder integration, not a pin-header module
  • Secondary development requires matching PCB footprint

Q2: Power supply is 3.0–3.6V (typ. 3.3V). Can it be powered directly by 5V?

  • No
  • It must be 3.3V with a low-noise LDO
  • Otherwise it will affect THD+N

咨询反馈

点击展开咨询反馈表单
×

Notice

Company Name:

Email Address:

Subject:

Message: