TLV320AIC3111EVM-K: Audio playback issues - device recognized by windows

Note that I tried the process in this thread (even though I don't think that the symptoms align) - however now I get a "Device Descriptor Request Failed" error, and when I try to install the recommended driver (using slac563b.zip), windows says that my current "unknown USB device" driver is the best option.

In other words, it seems like I made the problem worse.

e2e.ti.com/.../faq-tlv320aic-codecs-and-adcs-how-to-restart-revive-a-usb-audio-evm

Thanks. Unfortunately attempting this results in a series of issues. First, if I force the use of the driver in "slac563b.zip", I get this error:

And if I use DFUTEST anyway, I get this error:

Any suggestions to resolve? I am stuck at this point.

-Chris

Did you restart the PC and are you shorting the I2C lines as suggested?

Yes, as far as I can tell, I am working through the process as outlined in the document. There appears to be a problem with the driver as provided in "slac563b.zip". 

I have used that before, but just in case here is a copy.

USBfirmware_V0304_Portable.7z

Any chance you can provide as a .zip file?

Nevermind, I installed 7 zip. I get the same error when I try to use that driver (see image below). Any other ideas?

Note that, my dev board is recognized as a sound card, and I can seem to communicate with the daughterboard via codec control. However I cannot get audio out of the headphone jack, or out of the speaker connections. As I mentioned before, there seems to be something broken in the link between the daughterboard and the USB-MODEVM. Or perhaps there is something wrong in the setup of the daughter board itself. Anything I should pursue on this front instead?

First we need to get the USB-AudioEVM recognized in the device manager, have you tried uninstalling the GUI and drivers and start clean?

The procedure should work as we have often use the flow to change different rate with the EVM.

As to your dev board, I presumed you will be connecting the SAI from your host and not the TAS1020B so make sure you have the right position for SW2 switch.

Thanks, however the USB-AudioEVM is (and always has been) recognized in the device manager IF I don't go through the process of shorting the I2C pins on the EEPROM. I only have issues with recognition in the device manager after I've shorted those pins. If I power cycle the board (without the shorted pins), device manager recognizes the USB-AudioEVM again.

With respect to the DIP switch placement, per my first post, the DIP switches are set to positions 2 and 8 high, the rest low. This is per the user's guide - is this correct? Currently I am just trying to play audio from my PC through the USB-MODEVM, daughterboard and headphone jack, so I believe I still need to use the TAS1020 to process data coming through via USB.

OK since you have the device manager shown as USB-AudioEVM, let's try running the playback script from the GUI:

You should see the EVM connected status and the I2C transaction turns green when running the script.

This script will turn on the HP path as well so you can listen to a music on the headset J14 connector.

I tried on the EVM and using the above steps to reprogram the firmware and was able to get it working.

Here is a screen shot of the SW2 setting also did you run the DFUTEST as an administrator?

Regards.

Greetings, thanks for the ongoing support. SW2 is configured the same. EVM status is connected, and based on the image below, you can see that the USB-AudioEVM is recognized by my PC, and has been selected as the audio source. In my headphones (connected to J14) I can hear some faint white noise - indicating to me that the TLV320AIC Amp is active. Also, when I run the playback script, I can hear some slight popping as the TLV320AIC is reconfigured by the script. However, no audio is making it from my PC to my headphones.

With regards to DFUTEST, yes, I tried running it as an admin after stepping through the shorted EEPROM I2C lines process. I still get the same error (see below). Does SW2 need to be configured differently during firmware update attempts?

As I said above, it seems like there is some form of "broken link" between the TAS1020B and the TLV320AIC3111 - it doesn't seem like the TAS1020B is damaged since it still is recognized by windows, and it doesn't seem like the TLV3230AIC311 is damaged since it still responds to the codec control software. Any other ideas? Obviously a bit frustrating since this dev board system was not cheap.

Two more comments mentioned earlier, but worth repeating.

1. The entire toolchain was working when I first received it - which does indicate that something might be damaged. 
2. The "beep" functionality in the Codec Control software worked when I first received the hardware as well (via headphones), but now it no longer works. This may indicate that the TLV320AIC3111 is damaged.

Is there a way to properly uninstall the Codec Control software? I'm not seeing it as an "uninstallable app" via windows add/remove programs.

This message appears in step 7 and click DFUEE.bin to program. Are you not able to ever successfully program this?

OK, let's try this steps instead to program the sampling from the GUI. Start the rate say 48KHz, close the GUI and reopen and see the rate is now 48KHz then go back and program with 44.1KHz, close GUI and reopen and now load the playback script and run.

I cannot get past the "no DFU devices found" error. I can confirm that, using the "Update Firmware" command via the GUI, I can change the sampling frequency from 44.1 to 48kHz and back again (confirmed by the change in USB Fs reported in the toolbar). Unfortunately I still cannot hear any playback. 

I did also connect the entire setup to a different computer and found the same results.

You have set the windows sound to Line USB-EVM I assume.

Just for testing, can you set SW2 pin 2 also to ON (slide to left) and try the DFU test again?

Can you connect EVM with pin 2 to ON position? If not go back and set SW2 pin to OFF and retry.

Strange that you can't proceed with the DFU test, but with GUI you can program different rates but no sound coming out.

If you switch to PC speaker are you able to hear the sound?

With SW2 pin 2 set to LO, the USB-AudioEVM is not recognized by my PC and I get the same error during a DFU attempt (shorting the i2c EEPROM lines, etc). Any other ideas? Any other options to test the functionality of the independent boards? For example, can I route the headphone line out of my PC in to the mic input in the daughterboard, and configure the the TLV board to route the mic input to its headphone output?

You can bypass the TAS1020B by providing external ASI signals through J14 of the USB-MODEVM and configure SW2 accordingly.

So your host will need to provide the clocks and if it's just playback you can run the playback script and provide the input from PC.

Thanks, but I currently don't have a host set up to provide clocking. Is there anything else I can do to debug this hardware? Or should I assume that this is a $250 paper weight now?

You can use audio instrument like AP-PSIA if you have that, otherwise it seems like something is broken after you first run.

Can you share a link or a specific PN? What I am finding online seems to be a very expensive tool - buying this to debug a dev board certainly is not an option. 

Any other options for debugging, or any ways to access fault information via the GUI? Is it possible to just purchase the daughterboard?

Ya, it's an expansive equipment so not an option there.

It's strange that it is stuck at the "no DFU..." message, you can write/read the codec register and change the sampling rate of TAS1020B. So it seems codec and TAS are ok, maybe the Microchip 24LC64I/SN EEPROM is the issue. 

The GUI I2C and codec clocks are coming from motherboard so you will still need to provide the clock from outside, the GUI maybe you can use other I2C host to write to the registers if you just want the daughterboard.

To me, it seems like the audio amp portion of the TLV320 might be damaged (or is somehow disabled) - or there is something otherwise wrong between the headphone jack (or speakers) and the TLV320. Given the short protection in the TLV320 on both the headphone and speaker drivers, it is a bit hard to believe that this is the root cause, but it is suspect since I cannot get the "beep" functionality to work. Is there anything on the output side of the TLV320 I should check, either in hardware or in terms of its configuration?

Check the registers if you read back what it's written. It's hard to believe both HP and SPKR are damaged.