• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 31 subscribers
  • Views 1874 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TAS5704 dropouts when MCLK not aligned to SCLK/LRCLK

Bjoern Fruehsorge
Prodigy 35 points
Other Parts Discussed in Thread: TAS5704, CDCVF310

Hello community,

our application uses several TAS5704 in bridged mode with the following parameters:

MCLK: 12.288 MHz

LRCLK: 48.000 kHz

SCLK = 64 x LRCLK

Interface format: I2S

The application runs well at room temperature, but below ~15degC we observed perodical droputs (period ~1Hz, width: ~13.5ms) on the output signal.

The phase between the rising edges of MCLK and LRCLK was ~10ns. After we shifted the LRCLK phase-aligned to MCLK, the error probability got lower. After exactly aligning both clks to each other, we see no errors anymore.

We have checked all setup/hold requirements for the serial interface, they are well within the specifications and fully compliant to the datasheet.

Whats going on here? I cannot find any statement in the datasheet that requires MCLK and LRCLK zero-phase-aligned to each other.


I would appreciate feedback as soon as possible.

Thanks and regards,

Bjoern

  • 0
    TI__Guru**** 189399 points

    Hi, Bjoern,

    This is a pretty old part - the I2S receiver may not be as robust across temp as we'd like wrt mis-aligned clocks... Let me have someone look into it, but I expect it is what it is.

    What's generating your clocks?

    -d2

  • 0 in reply to Don Dapkus
    Prodigy 35 points

    Hi Don,

    our development and product lifecycles are rather long, so this part was "new" as we started the design.

    We have a standard 50ppm crystal oscillator generating the MCLK with 12.288 MHz. The clock is buffered with a TI CDCVF310 clock driver towards six TAS5704 and to a Xilinx Spartan-3A FPGA, which generates the I2S protocol.

    It is very important for our customer to get an evidence _why_ our solution works, so please provide some details about the mentioned (missing?) robustness across temp.

    Regards,

    Björn

  • 0 in reply to Bjoern Fruehsorge
    TI__Mastermind 22965 points

    Hi Bjorn,

    I am looking into this for you, meanwhile, can you please address the follow-up questions below?

    1.) You mentioned the system has been in use for a while, so has the issue shown up now with a new test procedure / test-conditions?

    2.) How many devices or systems show this behavior?

    3.) When the issue is resolved using zero-phase clocks, are the clocks provided with zero-phase during temperature ramp-down (from 25C to 15C) or are they provided after the system shows the issue at 15C?

    4.) How does phase difference between SCLK & LRCLK look in the system? Can you please post a screen-shot of the I2S clock & data lines in the two cases (i.e. when issue is seen and when it is resolved)?

    Regards,

    Ravi Singh

    Audio Applications Engineer.

  • 0 in reply to Ravi Singh
    Prodigy 35 points

    Hi Ravi,

    here are answers to your questions:

    1) We use only one production batch with components procured in Q3/2009.

    2) All (six) TAS5704 within the affected systems show this behaviour.

    3) The clock configuration can only be changed by means of FPGA updating, so the zero-phase configuration is present since power-on (tested ramp-down and after "cold" start below 15C).

    4) Unfortunately I have not a screenshot, but the phase difference between SCLK and LRCLK is exactly what the data sheet requires (LR clock switching on the falling edge of SCLK) in both test conditions. I only changed the phase difference between MCLK and the I2C signals.

    Regards,

    Björn