They should be identical. Whether they are, depends on how well the datasheet was written. I prefer when the manufacturer writes Reserved or something instead of presenting you with duplicate options.
So 11 and 10 are allegedly the same thing, thanks. Data sheet tells absolutely nothing else about, except the table I posted.
Help, I'm stuck!
I'm having two issues with the XMOS controller that are so far resisting to any attempt to address:
1. UAC2 crashing
Needless to say, I didn't touch the UAC2 part in the Reference software (not that there's much to touch, anyway). The only major difference to the Reference Board hardware i that I'm using XUF216 (with internal Flash memory) instead of the XE216 (which uses an external Flash memory chip). PC UAC2 driver is 4.13.0.36007 from Thesycon. Problem is, after starting the software (without any ADC or DAC HW customization, only a digital loop), the PC correctly identifies the board as "XMOS USB Audio 2.0 ST" type, but then crashing after a few minutes, and the PC is reporting "Last Device was not recognized", randomly, sometimes while looping digital (Source is Arta, tried REW as well), sometimes even without doing anything, just sitting on the table. Restarting the software "solves" the problem, then the cycle starts over. It's absolutely random, from 10 seconds after starting the software to over 10 minutes, and it happens on two different XMOS boards I assembled, and on 3 PCs that I tried, directly or through an USB hub.
All my PCs have only USB3 ports, but then I don't think this should make any difference. The USB cable length is not an issue, happens even with a 6" cable. I don't even know where to start looking into this issue...
2. I2C library is faulty.
The I2C library coming with the Reference software (I think it's 2.4.1) doesn't work properly. It appears to have timing issues, since when sending bytes to an I2C address and different registers addresses, I invariably end up with a ****** up configuration. Sending the same I2C data from an FTDI board works like a charm. By looking with a scope, I can see some odd very short spikes after each byte (address, register, data) on SDA, at the very limit of the next SCL clock positive edge, after the ACK. These spikes could be interpreted (if the timing is bad enough) as new START bit, and I suspect this is the root cause of the mess. I read others had timing issues with the old I2C library too, but then the latest version 6.1.1 uses a completely different architecture, needs upgraded dependencies, one to another is a major change to the code (which is already fragile as a **** because of the problem above). It's doable, but not before the UAC issue above is solved. Anybody seen this issue, and short of upgrading the I2C library is there any way to fix it with old I2C library? Needless to say, I didn't touch the library code.
One to another, my worst nightmare about this XMOS clusterfuck became reality. I got a few XE216 chips and SPI Flash chips, will try this too, but then I cannot find in the XMOS datasheets any reasons why the USB behavior would be different...
I'm having two issues with the XMOS controller that are so far resisting to any attempt to address:
1. UAC2 crashing
Needless to say, I didn't touch the UAC2 part in the Reference software (not that there's much to touch, anyway). The only major difference to the Reference Board hardware i that I'm using XUF216 (with internal Flash memory) instead of the XE216 (which uses an external Flash memory chip). PC UAC2 driver is 4.13.0.36007 from Thesycon. Problem is, after starting the software (without any ADC or DAC HW customization, only a digital loop), the PC correctly identifies the board as "XMOS USB Audio 2.0 ST" type, but then crashing after a few minutes, and the PC is reporting "Last Device was not recognized", randomly, sometimes while looping digital (Source is Arta, tried REW as well), sometimes even without doing anything, just sitting on the table. Restarting the software "solves" the problem, then the cycle starts over. It's absolutely random, from 10 seconds after starting the software to over 10 minutes, and it happens on two different XMOS boards I assembled, and on 3 PCs that I tried, directly or through an USB hub.
All my PCs have only USB3 ports, but then I don't think this should make any difference. The USB cable length is not an issue, happens even with a 6" cable. I don't even know where to start looking into this issue...
2. I2C library is faulty.
The I2C library coming with the Reference software (I think it's 2.4.1) doesn't work properly. It appears to have timing issues, since when sending bytes to an I2C address and different registers addresses, I invariably end up with a ****** up configuration. Sending the same I2C data from an FTDI board works like a charm. By looking with a scope, I can see some odd very short spikes after each byte (address, register, data) on SDA, at the very limit of the next SCL clock positive edge, after the ACK. These spikes could be interpreted (if the timing is bad enough) as new START bit, and I suspect this is the root cause of the mess. I read others had timing issues with the old I2C library too, but then the latest version 6.1.1 uses a completely different architecture, needs upgraded dependencies, one to another is a major change to the code (which is already fragile as a **** because of the problem above). It's doable, but not before the UAC issue above is solved. Anybody seen this issue, and short of upgrading the I2C library is there any way to fix it with old I2C library? Needless to say, I didn't touch the library code.
One to another, my worst nightmare about this XMOS clusterfuck became reality. I got a few XE216 chips and SPI Flash chips, will try this too, but then I cannot find in the XMOS datasheets any reasons why the USB behavior would be different...
Last edited:
Í only have boards from DIYINHK here, but there are no UAC2 problems like you describe. Both with the diyinhk software as well as with my own stripped down and modified software. Are you running the 8 channel example software provided by XMOS?
Cannot comment on the I2C stuff, as I don't use it.
Cannot comment on the I2C stuff, as I don't use it.
The DIYNHK board uses XUF216. For both XE216 and XUF216, the same xk-audio-216-mc.xn target file should be used. OTOH, you are using the board only to send I2S to a DAC, so it's not relevant in my case, which is much more complex.
Yes, that's what I call Reference software.
Last edited:
Did you tried USB2 ports?
(through USB Hub, for example).
I've heard of problems with USB3 (but haven't seen it myself).
(through USB Hub, for example).
I've heard of problems with USB3 (but haven't seen it myself).
Just tried through a USB 2.0 hub, same situation.
I'm starting to believe the problem is between the Thesycon driver 4.13 and the latest Win 10 (with all updates). I tried with the Win 10 UAC2 native driver, with the app compiled with the UAC_FORCE_FEEDBACK_EP flag set (otherwise the driver won't start with Error 10, a known issue) and it doesn't crash.
I have to try the XMOS Reference Audio board and see if I can reproduce the issue on the latest Win 10.
I'm starting to believe the problem is between the Thesycon driver 4.13 and the latest Win 10 (with all updates). I tried with the Win 10 UAC2 native driver, with the app compiled with the UAC_FORCE_FEEDBACK_EP flag set (otherwise the driver won't start with Error 10, a known issue) and it doesn't crash.
I have to try the XMOS Reference Audio board and see if I can reproduce the issue on the latest Win 10.
If you have a problem with 4.13 driver, maybe to try with 3.x or 2.x? They works fine under Win10/64.
I tried 3.x, no cigar.
I also tried with MacOS 11.4 + CrossOver and Arta, doesn't work properly (not sure if there is a crash).
I also tried with MacOS 11.4 + CrossOver and Arta, doesn't work properly (not sure if there is a crash).
After 6 hours of farting around the XtimeComposer, I cannot even debug_printf() a string in the console, using xscope. I added the lib_debug to the modules list, added -DDEBUG_PRINT_ENABLE=1 to the XCC_FLAGS list, successfuly compiled my application, configured xscope per AN00239, result: zero, zip, nada, jack ****. Either I'm a total moron and my 40 years of working in software are worth nothing, or this thing was engineered as a torture instrument for those that dare to touch it.
I need a break from this stuff, then reconsider the options (which are likely none...)
I need a break from this stuff, then reconsider the options (which are likely none...)
There are some USB diagnostics and information tools in my dropbox: https://www.dropbox.com/sh/nu1xmmvulcp7zxp/AABipCR6FyjE7xJ7ZKWTUVTja?dl=0
Also, there is a USB packet sniffer: https://desowin.org/usbpcap/
Then there is Arta: For me it always crashes if using ASIO drivers.
Also, there is a USB packet sniffer: https://desowin.org/usbpcap/
Then there is Arta: For me it always crashes if using ASIO drivers.
That forum is as helpful as my kitchen sink when it comes to specific questions about the xmos fírmware. 🙁
True, but I had no expectations. Unfortunately, the only forum dedicated to XMOS is deserted.
Maybe the USB packet sniffer would show events associated with a crash? Haven't tried the one linked above, but have used etherpeek and or wireshark for ethernet troubleshooting now and then.
Last edited:
The first think I tried is the USB sniffer, there's no "crash" (like an XMOS Core0 panic) per se, but, after the host controller executes an URB_FUNCTION_ISOCH_TRANSFER (0x000a) (data from ARTA/PC to the DAC), XMOS randomly signals USBD_STATUS_XACT_ERROR to the host controller, by setting the XactErr bit in the transfer descriptor's status field. The EHCI specification says that this bit is set when a CRC error, a timeout, an invalid PID, or a buffer error (under/overrun) occurs.
As a result, the host controller sends and URB_FUNCTION_ABORT_PIPE (0x0002). XMOS responds with a URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER (0x0009) then immediately with an URB_FUNCTION_ABORT_PIPE (0x0002), for the ADC to ARTA/PC channel. All subsequent URB_FUNCTION_ISOCH_TRANSFER (0x000a) sent by the host are ignored with IRP USBD_STATUS: USBD_STATUS_CANCELED (0xc0010000), while XMOS no longer sends data upstream.
Due to the random nature (no invalid PID), and given that the USB cable length and quality is not an issue (no timeout or CRC errors), I am speculating it's a buffer error (under/overrun).
As useful as petting my dog 🙁.
As a result, the host controller sends and URB_FUNCTION_ABORT_PIPE (0x0002). XMOS responds with a URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER (0x0009) then immediately with an URB_FUNCTION_ABORT_PIPE (0x0002), for the ADC to ARTA/PC channel. All subsequent URB_FUNCTION_ISOCH_TRANSFER (0x000a) sent by the host are ignored with IRP USBD_STATUS: USBD_STATUS_CANCELED (0xc0010000), while XMOS no longer sends data upstream.
Due to the random nature (no invalid PID), and given that the USB cable length and quality is not an issue (no timeout or CRC errors), I am speculating it's a buffer error (under/overrun).
As useful as petting my dog 🙁.
Last edited: