Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

16SoundsUSB open source board debugging records and issues #13

Open
blursj opened this issue Nov 4, 2020 · 19 comments
Open

16SoundsUSB open source board debugging records and issues #13

blursj opened this issue Nov 4, 2020 · 19 comments

Comments

@blursj
Copy link

blursj commented Nov 4, 2020

1、Hardware part
We obtained hardware design information and firmware information from the open source website https://github.com/introlab/16SoundsUSB. The first version produced five development boards that were exactly the same as the open source website (due to a procurement error, the main chip was soldered to XE216-512-TQ128, instead of XEF216-512-TQ128 in the BOM of the open source website), and purchased a piece of xTAG-v3 emulation programmer from Taobao, as shown in Figure 1 below:

Figure 1、16SoundsUSB xTAG-v3
Fixed the error of reverse polarity connection of D21 and D31, the 24MHz main clock U23 was soldered, the dual power strobe MOSFET Q4 was soldered, and the clock source selection resistors R118 and R146 were redundantly soldered. After several hardware errors, the system basically worked normally after power on Except that the entire system does not have QSPI FLASH (there is no inside or outside of the XMOS main control chip), is it possible to try to make the system work by downloading the firmware program inside the XMOS chip?
The system first uses an external 5V constant current source to supply power, and the power-on current of the system is about 0.0784A, as shown in Figure 2.

Figure 2. Voltage and current at first power-up
XMOS supply voltage 3.3V works normally, as shown in Figure 3

Figure 3. 3.3V voltage
XMOS supply voltage 1.0V works normally, as shown in Figure 4

Figure 4. 1.0V voltage
XMOS external 24MHz active crystal is working normally, as shown in Figure 5

Figure 5, 24MHz active crystal oscillator
2、Software part
Download the firmware 16SoundsUSB_Firmware_REV_1_0.xe from the open source website https://github.com/introlab/16SoundsUSB/releases/tag/rev1.0, and from https://github.com/introlab/16SoundsUSB/tree/master/Firmware Download the configuration file 16SoundsUSB.xn in the project.
On the lubuntu16.04.6 system, configure the xTIMEcomposer 14.4.1 of the XMOS development software (from the official website
https://www.xmos.ai/software-tool)xTIMEcomposer-Community_14-Linux64-Installer_Community_14.4.1.tgz, after solving the problem of square characters and xTAG-v3 access rights. The project can be compiled, simulated and downloaded firmware through XMOS development software.
The first step is to test our own engineering project. The startup procedure is as follows:

Import the project app_usb_aud_xk_216_mc, as shown in the figure

Change the configuration file in the XMOS official website reference board project app_usb_aud_xk_216_mc
/home/skd/workspace/app_usb_aud_xk_216_mc/src/core/xk-audio-216-mc.xn and open source
https://github.com/introlab/16SoundsUSB/tree/master/Firmware to download the configuration file 16SoundsUSB in the project. xn for comparison, because the XS2-UnA-512-FB236 configuration is used in the XMOS official website configuration file, and our development board uses XE216-512-TQ128 (without FLASH). So replace the left side of the figure below with the content on the right

becomes

Also modified
/home/skd/workspace/app_usb_aud_xk_216_mc/src/core/customdefines.h

/* Enable/Disable SPDIF output - Default is S/PDIF on /
#ifndef SPDIF_TX
#define SPDIF_TX 1
#endif
becomes
/
Enable/Disable SPDIF output - Default is S/PDIF on /
#ifndef SPDIF_TX
#define SPDIF_TX 0
#endif
and
/
Number of IS2 chans to DAC..*/
#ifndef I2S_CHANS_DAC
#define I2S_CHANS_DAC (8)
#endif

/* Number of I2S chans from ADC /
#ifndef I2S_CHANS_ADC
#define I2S_CHANS_ADC (8)
#endif
becomes
/
Number of IS2 chans to DAC..*/
#ifndef I2S_CHANS_DAC
#define I2S_CHANS_DAC (4)
#endif

/* Number of I2S chans from ADC */
#ifndef I2S_CHANS_ADC
#define I2S_CHANS_ADC (8)
#endif
The compilation result is as shown in the figure below, and the binary executable file is obtained: app_usb_aud_xk_216_mc_1i2o2xxxxxx.xe

Ability to perform online simulation and operation in the IDE development environment

Online simulation selection simulator

The program is running normally, as shown in the figure below, where the second light from right to left on xTAG-v3 keeps flickering.

At this time, the system current increases to 0.411A, as shown in the figure below.

The ADC_RST_N level changes to 3.3V high level, and the quantity TP13 is shown in the figure below. It should be the ADC starting to work.

MCLK_AUDIO becomes 1.152MHz, and the right side of R146 is shown in the figure below, that is, the clock signal to ADC works normally.

Measured the 4 data ports ADC2_SDOUT4 of the second ADC chip, that is, R83 pin has data as shown below.

The 4 data pins related to the first ADC chip have no signals.
Insert the USB cable at this time, the current drops to about 0.10A, but after a while it returns to about 0.42A.
lsusb Check the newly added device and show Bus 001 Device 009: ID 20b1:0009 XMOS Ltd

Open the Audacity recording software, the xCORE USB Audio 2.0 device can be recognized, as shown below

But the multi-channel option is only 2, and 10 does not appear. As shown below:

The two channels seem to be able to record, but the front MIC is not connected for test verification.
The second step is to test the open source firmware --
16SoundsUSB_Firmware_REV_1_0.xe. First unplug the USB cable. Configure the open source firmware in the operating options of xTIMEcomposer, as shown in the figure below:

Then click the Run button in the lower right corner, the open source firmware is downloaded to the board through xTAG-v3 and starts to run, the xTAG light flashes, and the system current becomes 0.355A, as shown in the figure below.

At this time, ADC_RST_N is high, MCLK_AUDIO has a signal of 1.152MHz, and at this time, each of the four data lines of ADC1 and ADC2 has data signals.
But unlike the compiled firmware, after plugging in the USB, the current drops to 0.1044A, ADC_RST_N becomes low level, MCLK_AUDIO clock signal disappears, and the 4 data lines of ADC1 and ADC2 become low level.

When the USB is plugged in, the two pins TP4 (SCL) and TP3 (SDA) of the I2C bus have signals, as shown in the figure below
TP3(SDA)

TP4(SCL)

At this time, lsusb checks the newly added device and shows Bus 001 Device 015: ID 20b1:0008 XMOS Ltd, as shown in the figure below

Open the Audacity recording software, the 16SoundsUSB Audio 2.0 device can be recognized, as shown below

And there are 16 channels in multi-channel selection,

But when I started recording, I couldn't turn on the device, as shown in the figure below.

At this time, unplug the USB line and plug in the USB line, lsusb will not appear new XMOS USB Audio devices.

3、summary of issues
a. How to correctly modify the rest of the files except .xn in the project app_usb_aud_xk_216_mc to drive ADC1, ADC2 and DAC1 correctly? Can open source projects provide complete source code? Including how to modify files such as customdefines.h and audiohw.xc.
b. Are there other problems with the hardware? In the absence of external QSPI-FLASH and the internal FLASH of the chip, can the firmware be downloaded to the XMOS on-chip RAM through xTAG to run normally, and at the same time, it can support repeated USB cable plugging and unplugging and correctly identify the USB Audio Device, and it can be used Does Audacity record 16 channels?

@doumdi
Copy link
Member

doumdi commented Nov 6, 2020

Have a look here for firmware modifications : https://github.com/introlab/16SoundsUSB/tree/master/Firmware

@doumdi
Copy link
Member

doumdi commented Nov 6, 2020

Also, try testing the device on Linux or Mac. Windows is not fully supported. Have a look at this, this might help : https://www.xcore.com/viewtopic.php?t=6806

@blursj
Copy link
Author

blursj commented Nov 10, 2020 via email

@doumdi
Copy link
Member

doumdi commented Nov 10, 2020

@blursj Add/change the following defines L105+:

#if I2S_WIRES_ADC > 7
                PORT_I2S_ADC7,
#endif
#if I2S_WIRES_ADC > 8
#error I2S_WIRES_ADC value is too large!
#endif

@blursj
Copy link
Author

blursj commented Nov 10, 2020 via email

@doumdi
Copy link
Member

doumdi commented Nov 10, 2020

FYI MCLK should be around 12.288 MHz when the board starts. All leds should be on.

@blursj
Copy link
Author

blursj commented Nov 11, 2020 via email

@blursj
Copy link
Author

blursj commented Nov 11, 2020 via email

@blursj
Copy link
Author

blursj commented Nov 11, 2020 via email

@doumdi
Copy link
Member

doumdi commented Nov 11, 2020

@vrheaume do you have an idea what could be the problem?

@blursj
Copy link
Author

blursj commented Nov 11, 2020 via email

@vrheaume
Copy link
Collaborator

Hello,

For some reason I can't see the figures in your post, so forgive me if I ask questions that seem redundant.

How do you measure the power consumption? Is it done with the XTAG somehow, or with an external power supply connected to the DC input barrel connector (5V)?

I don't think the LEDs should blink like you describe, so even before looking closely at the PLL chip, I would tend to take a step back.

If I understand correctly, the 16SoundsUSB card is powered by the XTAG, until you initially plug in the USB, and then goes back by itself to being supplied by the XTAG? Perhaps there is a glitch occuring when the power switches over? @doumdi have we done this before?

The 16SoundsUSB can draw quite a bit of power from the USB port, in some cases more than the USB 2.0 typical max of 500mA (depending on ADC frequencies, USB cable losses). It may be farfetched and we haven't actually experienced this, but I could see a computer failing to deliver this much power properly over the USB, which could generate dips in the power supplies, which could lead to initialization problems on the board...

In order to set this hypothesis aside, I would tend to suggest that you try powering the board from a lab power supply or a wall wart power supply (5V, >1A) connected to the DC input barrel connector, before we investigate further.

If you have a good oscilloscope I would also recommend to measure the 3,3V supply before-and-after connecting the USB port to see if there is a short transient there.

We could verify the output of the CS2100 on R117 or R65 after initialization on our boards, like you said, to verify if we obtain the same frequency as you do. It might take a few days.

Vincent

@blursj
Copy link
Author

blursj commented Nov 12, 2020 via email

@doumdi
Copy link
Member

doumdi commented Nov 12, 2020

@blursj can you verify the clock signal (generated by the XMOS chip) you get at PLL_SYNC? It should be 1MHz. Also, try to start the firmware with the XTAG attached. You might see some errors that could be useful for debugging.

@doumdi
Copy link
Member

doumdi commented Nov 12, 2020

Also make sure R118 is NI.

@blursj
Copy link
Author

blursj commented Nov 15, 2020 via email

@blursj
Copy link
Author

blursj commented Nov 15, 2020 via email

@SCWhite
Copy link

SCWhite commented Dec 30, 2020

HI @doumdi
I'm a little confused, having the same problem
where should we do this change, in the "customdefines.h" file?

@blursj Add/change the following defines L105+:

#if I2S_WIRES_ADC > 7
                PORT_I2S_ADC7,
#endif
#if I2S_WIRES_ADC > 8
#error I2S_WIRES_ADC value is too large!
#endif

add those line, but still getting "#error I2S_WIRES_ADC value is too large!" when compile

Thanks for your help

@doumdi
Copy link
Member

doumdi commented Dec 30, 2020

@SCWhite Make the change to the file : module_usb_audio/main.xc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants