blursj commented 4 years ago

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 commented 4 years ago

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

doumdi commented 4 years ago

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 commented 4 years ago

Thank you very much for your help!!! After patching these files from your git server, we still get compile errors, follow instructions below:

blursj@blursj-PICO-BT01:~/workspace/app_usb_aud_xk_216_mc$ patch --normal Makefile ~/work/XMOS/firmware/16SoundsUSB/Firmware/app_usb_aud_xk_216_mc/Makefile.diff

patching file Makefile blursj@blursj-PICO-BT01:~/workspace/app_usb_aud_xk_216_mc$ cd src/core/ blursj@blursj-PICO-BT01:~/workspace/app_usb_aud_xk_216_mc/src/core$ patch --normal customdefines.h ~/work/XMOS/firmware/16SoundsUSB/Firmware/app_usb_aud_xk_216_mc/src/core/customdefines.h.diff

patching file customdefines.h blursj@blursj-PICO-BT01:~/workspace/app_usb_aud_xk_216_mc/src/core$ cp -a ~/work/XMOS/firmware/16SoundsUSB/Firmware/app_usb_aud_xk_216_mc/src/core/16SoundsUSB.xn . blursj@blursj-PICO-BT01:~/workspace/app_usb_aud_xk_216_mc/src/core$ rm -rf xk-audio-216-mc.xn blursj@blursj-PICO-BT01:~/workspace/app_usb_aud_xk_216_mc/src/core$ cd ../extensions/ blursj@blursj-PICO-BT01:~/workspace/app_usb_aud_xk_216_mc/src/extensions$ patch --normal audiohw.xc ~/work/XMOS/firmware/16SoundsUSB/Firmware/app_usb_aud_xk_216_mc/src/extensions/audiohw.xc.diff

patching file audiohw.xc blursj@blursj-PICO-BT01:~/workspace/app_usb_aud_xk_216_mc/src/extensions$ patch cs5368.h ~/work/XMOS/firmware/16SoundsUSB/Firmware/app_usb_aud_xk_216_mc/src/extensions/cs5368.h.diff

patching file cs5368.h blursj@blursj-PICO-BT01:~/workspace/app_usb_aud_xk_216_mc/src/extensions$ patch --normal gpio_access.c ~/work/XMOS/firmware/16SoundsUSB/Firmware/app_usb_aud_xk_216_mc/src/extensions/gpio_access.c.diff

patching file gpio_access.c

Compile errors are below:

In file included from /home/blursj/workspace/module_usb_audio/main.xc:17: In file included from /home/blursj/workspace/module_usb_audio/devicedefines.h:9: .././src/core/customdefines.h:123:9: warning: 'AUDIO_CLASS' macro redefined

define AUDIO_CLASS 2 //Default class 2

:9:9: note: previous definition is here

define AUDIO_CLASS 1

/home/blursj/workspace/module_usb_audio/main.xc:106:2: error: I2S_WIRES_ADC value is too large!

error I2S_WIRES_ADC value is too large!

^ warning: subword-select option is deprecated and has no effect In file included from /home/blursj/workspace/module_usb_audio/main.xc:17: In file included from /home/blursj/workspace/module_usb_audio/devicedefines.h:9: .././src/core/customdefines.h:123:9: warning: 'AUDIO_CLASS' macro redefined

define AUDIO_CLASS 2 //Default class 2

:9:9: note: previous definition is here

define AUDIO_CLASS 1

/home/blursj/workspace/module_usb_audio/main.xc:106:2: error: I2S_WIRES_ADC value is too large!

error I2S_WIRES_ADC value is too large!

^ /home/blursj/workspace/module_usb_audio/main.xc:85:17: error: array of ports is not fully initialized {PORT_I2S_ADC0, ^~~~~~~ xmake[1]: [.build_1i2o2xxxxxx/_m_usb_audio/main.xc.pca.xml.decouple] Error 1 xmake: [analyze] Error 2

17:52:39 Build Finished (took 2s.764ms)

best regards, shijian

Dominic Létourneau notifications@github.com 于2020年11月7日周六上午4:33写道：

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

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/introlab/16SoundsUSB/issues/13#issuecomment-723287028, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADUHQ3JKI22PF77ZSXYTXUTSORMQNANCNFSM4TJ2MMOA .

doumdi commented 4 years ago

@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 commented 4 years ago

Dear dominic, I deeply appreciate it. After following your instructions, I successfully compiled it.

best regards, shijian

Dominic Létourneau notifications@github.com 于2020年11月10日周二下午10:14写道：

@blursj https://github.com/blursj Add/change the following defines :

if I2S_WIRES_ADC > 7
            PORT_I2S_ADC7,
endif

if I2S_WIRES_ADC > 8

error I2S_WIRES_ADC value is too large!

endif

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/introlab/16SoundsUSB/issues/13#issuecomment-724728068, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADUHQ3IQPRWJ5T2764WWFK3SPFDDPANCNFSM4TJ2MMOA .

doumdi commented 4 years ago

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

blursj commented 4 years ago

I tried the newly compiled firmware and it has the same running effect as 16SoundsUSB_Firmware_REV_1_0.xe on my board. Under the ubuntu16.04 system, when the usb power supply is plugged in, LEDs 1~3 blink 4 times and then go out. lsusb can find the "20b1:0008 XMOS Ltd" device, but the audacity program can also find 16-channel XMOS devices, but When recording, it shows that the device cannot be turned on. At this time, the current of the board is only about 0.1A. I suspect there is a problem with my CS2100 or 24MHz clock? But I measured 24MHz and it feels quite stable. After the CS2100 is configured through the I2C bus, the output clock is 1.152MHz. Is this frequency correct? Is this on your board?

Dominic Létourneau notifications@github.com 于2020年11月11日周三上午6:08写道：

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

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/introlab/16SoundsUSB/issues/13#issuecomment-724996824, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADUHQ3KKVI365XOZAHEOLVLSPG2XVANCNFSM4TJ2MMOA .

blursj commented 4 years ago

Something wrong with my MCLK which is only 1.152MHz, not 12.288MHz needed by audio device. I don't know why and how to fix it?-

Dominic Létourneau notifications@github.com 于2020年11月11日周三上午6:08写道：

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

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/introlab/16SoundsUSB/issues/13#issuecomment-724996824, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADUHQ3KKVI365XOZAHEOLVLSPG2XVANCNFSM4TJ2MMOA .

blursj commented 4 years ago

Very strange. I changed code as below: 1. void AudioHwInit(chanend ?c_codec) {

if !(defined(SPDIF_RX) || defined(ADAT_RX)) && defined(USE_FRACTIONAL_N)

/* Output a fixed sync clock to the pll */

// configure_clock_rate(clk_pll_sync,100,100/(PLL_SYNC_FREQ/1000000)); configure_clock_rate(clk_pll_sync, 100, 100);//100000000/PLL_SYNC_FREQ); configure_port_clock_output(p_pll_clk, clk_pll_sync); start_clock(clk_pll_sync);

endif

2.

if !(defined(SPDIF_RX) || defined(ADAT_RX))

/ Choose a frequency the xcore can easily generate internally / //#define PLL_SYNC_FREQ 1000000

define PLL_SYNC_FREQ 94000//1000000 //94000 for no driver,86000 no use

else

define PLL_SYNC_FREQ 300

endif

Then I get a frequency approximately 12.288MHz which is hardly measured by an oscilloscope. But I don't know if it is correct? I can listen music from line out(DAC), There seems to be a little noise, I don’t know if the drive capacity of MCLK is not enough or the frequency is not accurate enough.

I don’t know if the CS2100-CP-CZZ I bought is correct. I think all the problems with my board are on the CS2100 chip. It seems that the I2C configuration is not working properly?

Dominic Létourneau notifications@github.com 于2020年11月11日周三上午6:08写道：

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

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/introlab/16SoundsUSB/issues/13#issuecomment-724996824, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADUHQ3KKVI365XOZAHEOLVLSPG2XVANCNFSM4TJ2MMOA .

doumdi commented 3 years ago

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

blursj commented 3 years ago

CS2100 chipset, but I don't know why?

Dominic Létourneau notifications@github.com 于2020年11月11日周三下午9:12写道：

@vrheaume https://github.com/vrheaume do you have an idea what could be the problem?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/introlab/16SoundsUSB/issues/13#issuecomment-725415135, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADUHQ3KLZCBVFYZUGG7TBMTSPKETPANCNFSM4TJ2MMOA .

vrheaume commented 3 years ago

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 commented 3 years ago

Hi vrheaume, Sorry that I don't know how to post figures in forum, I just attached my debug document with figures in email. You can check it and help me. My question focuses on the output frequency of the CS2100 which is MCLK_AUDIO, the very important frequency. It is 1.152MHz running 16SoundsUSB_Firmware_REV_1_0.xe which is you provided. After I modified some code unconventionally, it became close to 12.288MHz. I want to know why?

Thank you all guys, best regards, shijian

vrheaume notifications@github.com 于2020年11月12日周四下午12:35写道：

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 https://github.com/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

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/introlab/16SoundsUSB/issues/13#issuecomment-725830621, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADUHQ3LUYGN32RSUHD5MKJDSPNQZRANCNFSM4TJ2MMOA .

doumdi commented 3 years ago

@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 commented 3 years ago

Also make sure R118 is NI.

blursj commented 3 years ago

sorry too late to reply, make sure that R118 and R146 is NI. and get PLL_SYNC is 1MHz. But still fail to open device using opensource firmware. shijian

Dominic Létourneau notifications@github.com 于2020年11月13日周五上午1:09写道：

Also make sure R118 is NI.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/introlab/16SoundsUSB/issues/13#issuecomment-726211755, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADUHQ3KLWZRETRM52DV72FTSPQJETANCNFSM4TJ2MMOA .

blursj commented 3 years ago

I will test new design hardware a few days later. I redesigned clock circuit refer to XMOS original design and check what is the problem.

Dominic Létourneau notifications@github.com 于2020年11月13日周五上午1:09写道：

Also make sure R118 is NI.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/introlab/16SoundsUSB/issues/13#issuecomment-726211755, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADUHQ3KLWZRETRM52DV72FTSPQJETANCNFSM4TJ2MMOA .

SCWhite commented 3 years ago

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 commented 3 years ago

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

introlab / 16SoundsUSB

16SoundsUSB open source board debugging records and issues #13

ifndef SPDIF_TX

define SPDIF_TX 1

endif

ifndef SPDIF_TX

define SPDIF_TX 0

endif

ifndef I2S_CHANS_DAC

define I2S_CHANS_DAC (8)

endif

ifndef I2S_CHANS_ADC

define I2S_CHANS_ADC (8)

endif

ifndef I2S_CHANS_DAC

define I2S_CHANS_DAC (4)

endif

ifndef I2S_CHANS_ADC

define I2S_CHANS_ADC (8)

endif

Thank you very much for your help!!! After patching these files from your git server, we still get compile errors, follow instructions below:

patching file gpio_access.c

define AUDIO_CLASS 2 //Default class 2

define AUDIO_CLASS 1

error I2S_WIRES_ADC value is too large!

define AUDIO_CLASS 2 //Default class 2

define AUDIO_CLASS 1

error I2S_WIRES_ADC value is too large!

if I2S_WIRES_ADC > 7

endif

if I2S_WIRES_ADC > 8

error I2S_WIRES_ADC value is too large!

endif

if !(defined(SPDIF_RX) || defined(ADAT_RX)) && defined(USE_FRACTIONAL_N)

endif

if !(defined(SPDIF_RX) || defined(ADAT_RX))

define PLL_SYNC_FREQ 94000//1000000 //94000 for no driver,86000 no use

else

define PLL_SYNC_FREQ 300

endif