Hi. It is a bit disturbing not seeing a solid resolution to the same USB enumeration issue posted by assorted developers. Hope there is a concise procedure or fix to get everyone operational soon.
Not an audio developer and do not have your same target PCB but consider to:
Download the application note that relates to using USB HID or USB CDC on the Xcore-200 series which is present on your PCB. The example is supplied with full source code that you should be able to import -> compile as-is and then flash onto your target board. Will be interesting to see if the other USB IP works as-is.
USB Application note for XCORE-200 testing:
https://www.xmos.com/support/appnotes
AN00182: USB HID Class - Extended on xCORE-200 Explorer
AN00184: USB CDC Class as Virtual Serial Port - Extended on xCORE-200 Explorer
Both of the above USB code examples should be able to fire up your board and at least present as a USB unknown device inside of Windows Device Manager. Then, interested to receive your feedback on which USB Vendor and PIDs are shown. Do they match what is inside the XMOS source code? Hope that they do.
If these other USB IPs do not work, then move onto a very simple LED blink code for your target CPU. The focus is to see if the compiled code can perform any of these tasks. Ideally would like to hear that the USB IP enumerates inside of your device manager which it is not at this time. This could be because the QSPI flash is not properly enabled yet the PB is blinking your LEDs so most likely is fine. Concerned about the in-rush current issue linked to the USB Vbus pins. Recently a network of passive parts have been recommended to limit the in-rush current. Scout around this forum for posting from other developers who scoped the Vbus pin. If Vbus overshoots, it can nuke the CPU. We highly recommend an USB load switch which does this and much more to prevent such potential damage.
Our understanding is that the QSPI external flash on your target board is required to be programmed with the QE bit enabled. This is because the XMOS factory OTP ROM code is demanding to load using QSPI mode. Suspecting this is ok since you have noted the LEDs do something with the pushbutton presses.
Summary,
1) start with pre-canned USB IP to morph your board to being a USB HID device. Test again. Does it work? If not...move on
2) If above fails, test a simple LED blinker. Does it work using the XTAG tool (ie. from RAM loading)? If yes, flash onto your target external QSPI flash -> power cycle the board -> does the board continue to blink the LED as you have coded ? If yes, then the warnings can be ignored. If not, the QSPI flash is not being properly flashed.
3) If the code for led blink works then some USB related issue is at play. Again, not sure if the target board features the in-rush current protection or not. Hope this is not the issue but the CPU could have been potentially damaged from a USB cable insertion into the PC - a number of developers have reported this quirk already.
https://www.xcore.com/viewtopic.php?t=5808
http://www.xcore.com/viewtopic.php?t=5936