16SoundsUSB open source board debugging records and issues

[introlab]

16SoundsUSB open source board debugging records and issues

[doumdi]

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]

Dear dominic, I deeply appreciate it. After following your instructions, I successfully compiled it. best regards, shijian Dominic Létourneau <[email protected]> 于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> .

[doumdi]

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

[doumdi]

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

[blursj]

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 <[email protected]> 于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> .

[doumdi]

@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

[doumdi]

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

[blursj]

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 <[email protected]> 于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> .

[blursj]

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 <[email protected]> 于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> .

[blursj]

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 <[email protected]> 于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> .

[doumdi]

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

[blursj]

CS2100 chipset, but I don't know why? Dominic Létourneau <[email protected]> 于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> .

[vrheaume]

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]

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 <[email protected]> 于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> .

[doumdi]

@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]

Also make sure R118 is NI.

[blursj]

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 <[email protected]> 于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> .

[blursj]

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 <[email protected]> 于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> .

[SCWhite]

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