USB stuck in loop, not responding Topic is solved

[PVS_Bram]

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

[Joe]

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

[PVS_Bram]

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

Hi @Joe, thank you for your response!

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

[Joe]

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

[PVS_Bram]

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

Hi Joe

Removing the I2C connection code does indeed resolve my issue. Thank you so much!

Kind regards.

Bram