From c9ed314ea140d08d1bcfe2f0f21e6371890d55d2 Mon Sep 17 00:00:00 2001
From: PhatenIoT-yan <168261949+PhatenIoT@users.noreply.github.com>
Date: Mon, 8 Jun 2026 10:00:58 +0800
Subject: [PATCH] docs: sync A316 firmware FAQ (en)
---
.../technical_faq/a316_firmware_dev_faq.md | 485 +++++++++++++++++-
.../technical_faq/a316_firmware_dev_faq.md | 2 +-
2 files changed, 482 insertions(+), 5 deletions(-)
diff --git a/en/docs/dev_doc/faq/technical_faq/a316_firmware_dev_faq.md b/en/docs/dev_doc/faq/technical_faq/a316_firmware_dev_faq.md
index 5a0e345..25ad8e8 100644
--- a/en/docs/dev_doc/faq/technical_faq/a316_firmware_dev_faq.md
+++ b/en/docs/dev_doc/faq/technical_faq/a316_firmware_dev_faq.md
@@ -1,7 +1,7 @@
---
title: A316 Series Product Firmware Development FAQ
-description: This document provides common questions and solutions encountered during A316 series product firmware development, including XU316 communication issues, device power supply problems, etc., helping developers quickly resolve development challenges.
-keywords: A316 firmware development, XU316 communication issues, USB device power supply, firmware development FAQ, device recognition issues
+description: This document summarizes frequently asked questions and solutions for A316 series firmware development and integration, including XU316 serial communication, device recognition, protocol commands, mode switching, audio output debugging, and driver-related issues.
+keywords: A316 firmware development, XU316, serial communication, protocol commands, mode switching, audio output, driver issues, device recognition, XMOS
---
--8<-- "common/phaten_xmos_support_img.md"
@@ -47,6 +47,26 @@ keywords: A316 firmware development, XU316 communication issues, USB device powe
+### Q2: XMOS-A316 module occasionally sends command 0x00
+
+
+
+=== "Problem Symptoms"
+ - The module occasionally sends command 0x00 via UART
+
+=== "Problem Analysis"
+ 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
+
+=== "Solutions"
+ - 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
@@ -74,13 +94,470 @@ keywords: A316 firmware development, XU316 communication issues, USB device powe
-## Contact and Feedback
+## Protocol and Command Interaction
+
+### Q1: Notes for initialization commands 0x00~0x05
+
+
+
+=== "Communication Principles"
+ - 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.
+
+=== "Command 0x00 Details"
+ - **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)
+
+
+
+=== "Instructions"
+ - 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
+
+
+
+=== "Explanation"
+ - Command 0x20 is not used in the current firmware, so it will not be sent.
+
+
+
+### Q4: Why command 0x22 is sent automatically
+
+
+
+=== "Description"
+ - **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)
+
+
+
+=== "Notes"
+ 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
+
+
+
+=== "Troubleshooting Steps"
+ 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
+
+
+
+=== "Root Causes"
+ - The MCU repeatedly sends switching commands because it does not receive replies
+ - Signal instability during switching
+
+=== "Recommended Solution"
+ - Pull Mute pin low before switching (mute)
+ - Pull Mute pin high after confirming switch success (resume output)
+
+
+
+### Q4: Volume control command 0x21 is ineffective
+
+
+
+=== "Control Logic"
+ - **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
+
+
+
+=== "Description"
+ - **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
+
+
+
+=== "Description"
+ - **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
+
+
+
+=== "Troubleshooting Steps"
+ 1. **Confirm pin definitions**
+ - Pin locations for DATA0/1/2, 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)
+
+
+
+=== "Troubleshooting Steps"
+ 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
+
+
+
+=== "Solutions"
+ 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
+
+
+
+=== "Key Points"
+ 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
+
+
+
+=== "Solutions"
+ 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
+
+
+
+=== "Checklist"
+ 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
+
+
+
+=== "Notes"
+ 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
+
+
+
+=== "Troubleshooting Steps"
+ 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
+
+
+
+=== "Instructions"
+ 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
+
+
+
+=== "Instructions"
+ 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
+
+
+
+=== "Usage"
+ - Used to display USB connection status on a screen
+ - Improves user experience
+
+
+
+### Q4: How to configure and use recording (Microphone) feature
+
+
+
+=== "Configuration"
+ - 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
+
+
+
+=== "Problem Symptoms"
+ - During development/debugging, after flashing firmware with different configuration/channel counts
+ - The device cannot correctly recognize the current configuration
+
+=== "Cause"
+ - After changing recording channel count, the Windows cache becomes inconsistent with actual configuration
+
+=== "Solution"
+ 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)?
+
+
+
+=== "Answer"
+ - **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?
+
+
+
+=== "Answer"
+ - 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?
+
+
+
+=== "Answer"
+ - **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?
+
+
+
+=== "Answer"
+ - 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?
+
+
+
+=== "Answer"
+ - 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?
+
+
+
+=== "Answer"
+ - **No**
+ - It must be 3.3V with a low-noise LDO
+ - Otherwise it will affect THD+N
+
+
+
+## 咨询反馈
+
-Click to expand contact and feedback form
+点击展开咨询反馈表单
--8<-- "common/customer_form.md"
+