ftyyda/phaten-audio
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: sync A316 firmware FAQ (en)

Browse Source
This commit is contained in:
PhatenIoT-yan
2026-06-08 10:00:58 +08:00
parent a0ab92bad6
commit c9ed314ea1
2 changed files with 482 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files

485
en/docs/dev_doc/faq/technical_faq/a316_firmware_dev_faq.md
View File

@@ -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
</div>
### Q2: XMOS-A316 module occasionally sends command 0x00
<div class="grid" markdown>
=== "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
</div>
## 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
</div>
## Contact and Feedback
## Protocol and Command Interaction
### Q1: Notes for initialization commands 0x00~0x05
<div class="grid" markdown>
=== "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
</div>
### Q2: How to modify device information (command 0x01)
<div class="grid" markdown>
=== "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.
</div>
### Q3: Why command 0x20 is not received after startup
<div class="grid" markdown>
=== "Explanation"
- Command 0x20 is not used in the current firmware, so it will not be sent.
</div>
### Q4: Why command 0x22 is sent automatically
<div class="grid" markdown>
=== "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
</div>
## Mode Switching and Audio Control
### Q1: Notes for switching input/output mode (command 0x23)
<div class="grid" markdown>
=== "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)
</div>
### Q2: No sound or no data output after switching mode
<div class="grid" markdown>
=== "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)
</div>
### Q3: Muting or intermittent output during mode switching
<div class="grid" markdown>
=== "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)
</div>
### Q4: Volume control command 0x21 is ineffective
<div class="grid" markdown>
=== "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.
</div>
## Other Feature Inquiries
### Q1: Does the firmware support MQA
<div class="grid" markdown>
=== "Description"
- **Supported**: Firmware with suffix "Q" (e.g., `xxxx_Q.bin`)
- **Not supported**: Firmware without suffix "Q"
</div>
### Q2: Does the module use internal clock or external clock
<div class="grid" markdown>
=== "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
</div>
## Audio Output Issues
### Q1: No audio output after connecting I2S/DSD data pins
<div class="grid" markdown>
=== "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
</div>
### Q2: No audio or intermittent audio for SPDIF input (optical/coaxial)
<div class="grid" markdown>
=== "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
</div>
### Q3: POP noise during mode switching
<div class="grid" markdown>
=== "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
</div>
### Q4: How to connect and switch external clock (MCLK) correctly
<div class="grid" markdown>
=== "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
</div>
### Q5: Stuttering or POP noise when switching sampling rates
<div class="grid" markdown>
=== "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
</div>
### Q6: Noise / high noise floor output — how to troubleshoot EMC/EMI issues
<div class="grid" markdown>
=== "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
</div>
## Audio Format Support
### Q1: What to note when playing MQA audio
<div class="grid" markdown>
=== "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
</div>
### Q2: No sound or noise when playing DSD audio
<div class="grid" markdown>
=== "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
</div>
## Protocol Command Details
### Q1: How to parse and use command 0x22 audio stream format report
<div class="grid" markdown>
=== "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
</div>
### Q2: Value range of command 0x24 volume and DAC mapping
<div class="grid" markdown>
=== "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)
</div>
### Q3: What is command 0x29 USB connection status detection used for
<div class="grid" markdown>
=== "Usage"
- Used to display USB connection status on a screen
- Improves user experience
</div>
### Q4: How to configure and use recording (Microphone) feature
<div class="grid" markdown>
=== "Configuration"
- Not all firmware supports microphone recording
- Check firmware description to confirm whether it is supported
</div>
## Driver Issues
### Q1: Device cannot be correctly recognized after flashing different configuration firmware
<div class="grid" markdown>
=== "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
</div>
## 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)?
<div class="grid" markdown>
=== "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
</div>
#### Q2: How to switch between S/PDIF input 1 and 2?
<div class="grid" markdown>
=== "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
</div>
### Clock and Sample Rate Conversion
#### Q1: With 768kHz / DSD512 support, can macOS/Windows run it directly?
<div class="grid" markdown>
=== "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
</div>
#### Q2: How many channels can multichannel output support?
<div class="grid" markdown>
=== "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
</div>
### Hardware Integration
#### Q1: The module size is 19.5×26×0.8mm. Is it through-pin or SMD?
<div class="grid" markdown>
=== "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
</div>
#### Q2: Power supply is 3.0–3.6V (typ. 3.3V). Can it be powered directly by 5V?
<div class="grid" markdown>
=== "Answer"
- **No**
- It must be 3.3V with a low-noise LDO
- Otherwise it will affect THD+N
</div>
## 咨询反馈
<details>
<summary>Click to expand contact and feedback form</summary>
<summary>点击展开咨询反馈表单</summary>
--8<-- "common/customer_form.md"
</details>
<!-- Structured Data Markup -->
<script type="application/ld+json">
{

2
zh/docs/dev_doc/faq/technical_faq/a316_firmware_dev_faq.md
View File

@@ -47,7 +47,7 @@ keywords: A316固件开发, XU316通信问题, USB设备供电, 固件开发FAQ,
</div>
### Q4: XMOS-A316模组偶尔发送 0x00 命令
### Q2: XMOS-A316模组偶尔发送 0x00 命令
<div class="grid" markdown>