This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TAS5717 LRCLK error

Other Parts Discussed in Thread: TAS5717

I am trying to play audio files to a TAS5717 using I2S 16bit data. at 32000 Hz.

 

The TAS5717 is reporting a LRCLK error.

 

To play an audio file:

Sample Rate Generator is setup

Frams sync (LRCLK)  and bit clock is enabled

I2S Transfer is started (DMA)

wait for completion

I2S channel is disabled including LRCLK and bit clk

 

 

Would this sequence cause a LRCLK error?

What triggers a LRCLK error?

 

Thanks

 

  • A bit further information for TI.....

    We're trying to figure out a TAS5717 device... 

    Currently we're having issues with an ST STA333W part.  The audio gets scratchy and crackly when the STA333W gets even a faint whiff of heat near it.  We have a TAS5717EVM and we're configuring the TAS5717 via USB and then feeding the I2S that goes to our STA333W into the TAS5717.

    We've connected an analog to I2S box to the PSIA board via toslink and setup the jumpers and were able to get audio out of the setup.  We just used the toslink adapter because it was already setup that way rather than figuring out the analog input of the PSIA....

    Anyway what we did was we took off the jumpers 6,7 and 9 and connected our I2S to the center of these jumper locations. I'm fairly certain that we're getting audio into the system properly because address 0x00 is being set to 0x10 when we send audio.  Our board has an 8.192Mhz MCLK and is generating 32KHz sample rate data.  The TI board has a 12.288Mhz clock and thus a value of 0x10 sets things to 384*fs which would be correct.  I then disconnected the MCLK jumper and plumbed in 8.192Mhz from a function generator and then 0x00 was automagically set to 0x0c upon transmission of I2S data which set things to 256*fs.  So the TAS5717 is seeing our data and its updating the sample rate converter to match but it doesn't play anything. 

    I have verified that I've turned up the volume in the GUI and taken things out of shut down and mute.  I've also loaded the files mentioned in this thread with no success.

    I have noticed that while we're sending audio that if I check the Read On in the PWMLevelMeter I do see data on those. Often its only showing data on one channel but there are times where data is seen on both channels.

    We're doing short duration single tones for testing and the I2S bus sits idle in between these beeps.  Thus the LRCLK sits low....  I'm guessing that this is the reason why we've been getting a 0x10 in address 0x02.  Sometimes the value goes to 30 as well I assume that could also be because the SCLK is also stopping...

    We're using an AM3703 MCBSP to generate the I2S.  If there are any ideas or things to check relating to that let me know.

    Any ideas and or help would be greatly appreciated!

  • Hi Brett,

    Register 0x04 is used to set the serial data interface configuration. Can you confirm that this was updated to I2S 16-bit setting? (The default is I2S 24-bit). 

    The error register read-back is "sticky" i.e. retains error status, even if the error event happened for a short-duration and needs to be cleared (by writing 0x00) before every read-back. If you have not tried it already, read the error status after clearing to confirm a persistant clock error.

    You mentioned "..also loaded the files mentioned in this thread...", I did not see any files attached, can you share this info?


    - Ravi 

  • Sorry I'd originally started replying to this thread:

    http://e2e.ti.com/support/amplifiers/audio_amplifiers/f/6/t/152222.aspx

    I did set register 0x04 to 0x03 which should have configured me for a 16-bit I2S value.

    We have been continually reading the 0x02 register... It seems that it will stay as 00 for a while and after a couple tones it usually goes to 0x10 between tones when the I2S bus is stopped.  Clearing it it will stay 00 forever as long as no I2S is sent... Then after a few tones are sent it will go back to 0x10 or 0x30.  The time when this happens in our several tone test seems to be somewhat random.  Granted our I2S stream is still suspect but at the moment its good enough to get sound out of the STA333W device from ST.

  • Brett,

    Sorry for the delay, Ravi is out in Asia "touring" around...

    To be clear - you NEVER get audio out, regardless of whether or not you are throwing a clock error. Is that correct?

    I just noticed there may be some errors in the files on the thread you referenced.

    To start-up the TAS5717, you need to:

    Initialization Sequence
    Use the following sequence to power-up and initialize the device:
    1. Hold all digital inputs low and ramp up AVDD/DVDD to at least 3V.
    2. Initialize digital inputs and PVCC/AVCC supply as follows:
    • Drive RESET=0, PDN=1, HIZ=1, and other digital inputs to their desired state, observing
    absolute maximum ratings relative to AVDD/DVDD. Provide stable and valid I2S clocks (MCLK,
    LRCLK, and SCLK). Wait at least 100us, drive RESET=1, and wait at least another 13.5ms.
    • Ramp up PVCC/AVCC to at least 10V while ensuring it remains below 7.5V for at least 100us
    after AVDD/DVDD reaches 3V. Then wait at least another 10us.
    3. Trim oscillator (write 0x00 to register 0x1B) and wait at least 50ms.

    4. 0x04 0x03 ! 16 bit I2S format

    5. 0x07 0x00F0 ! sets gain to -6 dB

    6. 0x05 0x00 ! Out of shutdown

    -=-=-=-=-=-=-=-=-=-=-=-

    If you don't have stable clocks during the factory trim routine, it won't work... I wonder if that's the problem?

    -d2

  • Hi, Guys,

    Any update? Did you get this figured out? What was the issue?

    -d2

  • We have found a bit clock issue.  We are now testing a hardware change.

  • Larry,

    OK, let us know if you need any further assistance.

    -d2

  • Apologize its been really busy around here.  Turns out that we're getting much better luck with things after we replaced the level translators with some TI TXS family parts.  The bias transistors we were using were a bit slow and were causing some timing issues that were masked by my scope and my unlucky selection of thresholds while using digital channels.  Thats what I get for being lazy and wanting to leave the analog probes where they were.  

    Thanks gentlemen.