-
Notifications
You must be signed in to change notification settings - Fork 20
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
Comments
Have a look here for firmware modifications : https://github.com/introlab/16SoundsUSB/tree/master/Firmware |
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 |
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
^
<command line>: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
^
<command line>: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
<#13 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADUHQ3JKI22PF77ZSXYTXUTSORMQNANCNFSM4TJ2MMOA>
.
|
@blursj Add/change the following defines L105+:
|
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
<#13 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADUHQ3IQPRWJ5T2764WWFK3SPFDDPANCNFSM4TJ2MMOA>
.
|
FYI MCLK should be around 12.288 MHz when the board starts. All leds should be on. |
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
<#13 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADUHQ3KKVI365XOZAHEOLVLSPG2XVANCNFSM4TJ2MMOA>
.
|
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
<#13 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADUHQ3KKVI365XOZAHEOLVLSPG2XVANCNFSM4TJ2MMOA>
.
|
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
<#13 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADUHQ3KKVI365XOZAHEOLVLSPG2XVANCNFSM4TJ2MMOA>
.
|
@vrheaume do you have an idea what could be the problem? |
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
<#13 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADUHQ3KLZCBVFYZUGG7TBMTSPKETPANCNFSM4TJ2MMOA>
.
|
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 |
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
<#13 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADUHQ3LUYGN32RSUHD5MKJDSPNQZRANCNFSM4TJ2MMOA>
.
|
@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. |
Also make sure R118 is NI. |
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
<#13 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADUHQ3KLWZRETRM52DV72FTSPQJETANCNFSM4TJ2MMOA>
.
|
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
<#13 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADUHQ3KLWZRETRM52DV72FTSPQJETANCNFSM4TJ2MMOA>
.
|
HI @doumdi
add those line, but still getting "#error I2S_WIRES_ADC value is too large!" when compile Thanks for your help |
@SCWhite Make the change to the file : module_usb_audio/main.xc. |
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?
The text was updated successfully, but these errors were encountered: