Hi everyone
I have developed a custom board using the XU316-1024-QF60B. The design is based/tested on the USB MULTICHANNEL AUDIO EVALUATION KIT which uses a XU316-1024-TQ128 and the firmware is based on the sw_usb_audio example. I used the eval kit to develop the firmware and determine which parts I would like to use.
The kit is configured to work as an Asynchronous USB stereo input/output, 48000 Hz, 32 bit with the I2S Codec as the master for the I2S line. This works great on the evaluation kit. Using the custom created board is where the troubles begin. The board configuration (.xn) files are changed (ONLY CHANGES MADE: Packages >> Package >> Type; DAC (XS1_PORT_1F --> XS1_PORT_1P)/ADC (XS1_PORT_1G --> XS1_PORT_1I) pins). Running the firmware works as expected and shows the prints in the terminal. When connecting the USB to the host machine (Windows) it is recognised but does not respond to any volume changes/mute/unmute. Using the Device Monitoring Studio software I determined that the USB device seems to get stuck in some kind of loop in which the USB host sends an URB FUNCTION SELECT INTERFACE and receives a reply with status code: 0xc0000011. The USB communication stays in this loop. Some research online showed me that this error is defined as: USBD_STATUS_XACT_ERROR . What can cause this issue? The setup of the custom board is almost identical to the evaluation kit.
The schematic-, board files for the custom design and export of data from Device Monitoring Studio are attached to this post.
Thanks for you advice.
Bram
USB stuck in loop, not responding Topic is solved
-
- Member++
- Posts: 19
- Joined: Fri Jan 12, 2024 11:20 am
USB stuck in loop, not responding
You do not have the required permissions to view the files attached to this post.
View Solution
-
Verified
- Experienced Member
- Posts: 86
- Joined: Sun Dec 13, 2009 1:12 am
Hi,
1.) You have no MCLK input on tile0. The USB threads can't measure the MCLK so will basically lock up. Pretty sure this is why your board fails. Your XN defines MCLK_IN_USB on X0D11 but you have that wired to VBUS detect in the schematic. Find a spare 1 bit port and wire MCLK into that.
2.) The I2C bus isn't connected. The software will try to access I2C devices it is expecting on the board (i.e. to set up DACs etc.) and may fail due to this. It's possible it will ignore failed read/writes I'm not 100% on that. This is probably less of an issue.
Cheers,
Joe
1.) You have no MCLK input on tile0. The USB threads can't measure the MCLK so will basically lock up. Pretty sure this is why your board fails. Your XN defines MCLK_IN_USB on X0D11 but you have that wired to VBUS detect in the schematic. Find a spare 1 bit port and wire MCLK into that.
2.) The I2C bus isn't connected. The software will try to access I2C devices it is expecting on the board (i.e. to set up DACs etc.) and may fail due to this. It's possible it will ignore failed read/writes I'm not 100% on that. This is probably less of an issue.
Cheers,
Joe
XMOS hardware grey beard.
-
- Member++
- Posts: 19
- Joined: Fri Jan 12, 2024 11:20 am
Hi @Joe, thank you for your response!Joe wrote: ↑Tue May 21, 2024 10:36 am Hi,
1.) You have no MCLK input on tile0. The USB threads can't measure the MCLK so will basically lock up. Pretty sure this is why your board fails. Your XN defines MCLK_IN_USB on X0D11 but you have that wired to VBUS detect in the schematic. Find a spare 1 bit port and wire MCLK into that.
2.) The I2C bus isn't connected. The software will try to access I2C devices it is expecting on the board (i.e. to set up DACs etc.) and may fail due to this. It's possible it will ignore failed read/writes I'm not 100% on that. This is probably less of an issue.
Cheers,
Joe
I changed the board configuration files so that the MCLK_IN_USB is mapped to X0D00 (pin 6) and connected this pin to the X1D11 (pin 14) which is a clock of around 24.6 MHz. This does not seem to solve the issue. In stead of a continuous loop, the USB device connects, does the URB FUNCTION SELECT INTERFACE with the errors response around 15 times and then just seems to crash. Any suggestion to what else it could be? Or what I am doing wrong?
I'm pretty sure about that the I2C bus connection should not give any issues.
Kind regards.
Bram
-
Verified
- Experienced Member
- Posts: 86
- Joined: Sun Dec 13, 2009 1:12 am
I'm told not having the i2C connected will be an issue. It will likely stall forever as it can't access the i2c devices it is expecting.
I would try removing all the code programming the dac/adcs in audiohw.xc.
Cheers,
Joe
I would try removing all the code programming the dac/adcs in audiohw.xc.
Cheers,
Joe
XMOS hardware grey beard.
-
- Member++
- Posts: 19
- Joined: Fri Jan 12, 2024 11:20 am
Hi Joe
Removing the I2C connection code does indeed resolve my issue. Thank you so much!
Kind regards.
Bram