• State
  • Locked Locked
  • Replies 12 replies
  • Subscribers 29 subscribers
  • Views 2568 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.

SRC4392: DIR locks on 48 kHz and 96 kHz inputs, not 44.1 kHz or 88.2 kHz

Andy Peters
Genius 3945 points
Part Number: SRC4392

(I hope there are still people around at TI who can answer this question!)

I have a converter board built up and I am testing it. DIT side works fine.

On the receive side, the device is configured to use any of the RX inputs into the DIR, which feeds the SRC, which feeds audio port A. Audio port A is a master which feeds a DAC as a slave.

The DIR, SRC and Audio Port A all use RXCKI as their reference clock. RXCKI is driven by a 24.576 MHz oscillator (which also drives the DAC's MCLK input).

When connected to an S/PDIF or TOSLINK source with a sample rate of 48 kHz or 96 kHz, the DIR locks, RXCKO (enabled for monitor purposes but otherwise not used) toggles at a solid 12.2880 MHz and I get audio.

When the source sample rate is changed to 44.1 kHz or 88.2 kHz, the DIR does not lock (LOCK goes high). RXCKO outputs an ~11.43 MHz clock that is not very stable.

Nothing in the documentation indicates that this configuration should not work.

At initialization, I set register 0x0D is set to 0x00; bit 3 sets the reference clock to RXCKI, and during operation I will reload this register if the user selects another input source. Bit 3 is always 0, though.

Register 0x0E is set to 0x11, to let the PLL2 output clock drive RXCKO and to not stop it when the receiver is not locked. (If set to 0x01,  RXCKO stops shortly after switching to the 44.1/88.2 rates.)

Register 0x0F is set to 0x21, registers 0x10 and 0x11 are set to zero, which set the receiver PLL1 P, J and D constants to 2, 8 and 0, respectively, per table 4 in the data sheet.

What am I doing wrong? Where should I look?

  • 0
    TI__Expert 5645 points

    Hi Andy,

    I did review the config details provided in the thread and do not see any issues w the same. I will run some tests on the EVM to test the same and look into what the disconnect is wrt 44.1kHz sampling rate.

    I will have an update on the test results once I evaluate the same on the EVM. Thanks.

    Best regards,
    Ravi

  • 0 in reply to Ravi Patil
    Genius 3945 points
    Thanks -- hope to hear back soon.
  • 0 in reply to Ravi Patil
    Genius 3945 points
    Any ideas on this? I would start playing with registers, or even possibly making wiring changes on the board, if I had an idea about what way to go. This should "just work," right?
  • 0 in reply to Ravi Patil
    Genius 3945 points
    Ping, again -- I'm stuck and not sure what to do next.
  • 0 in reply to Ravi Patil
    Genius 3945 points

    WEEKLY PING. Is anyone home? I have no confidence in TI's support for these parts.

    It seems like there's a simple reason why this isn't working. I've gone over register settings and cannot see anything I'm doing that looks incorrect. I've even looked for other eval boards and whatnot that use this part, hoping that code would be available. For example, the TAS3251EVM uses the SRC4392, and looking at the schematic for this EVM, I see that the SRC4392 is configured over I2C from the XMOS part. I have the XMOS tools and I would look at the code for that part, but there is no link to it anywhere.

    The SRC4392EVM looks like it requires the user to set all of the register settings from a host computer program, so it's no help in determining what registers and values need to be loaded.

    This design should have been up and running a month ago, but without any hints I'm about to scrap it. XMOS has an SRC core that should work well enough.

    Again, the problem is simple: the DIR locks on inputs which have a sample rate that is a multiple of 48 kHz, but it does not lock on inputs which have a sample rate that is a multiple of 44.1 kHz. The reference clock is 24.576 MHz. Nothing in the data sheets indicate that I need to switch the reference clock to 22.5792 MHz (or 11.2986 MHz) and doing so requires some white wires and another oscillator.

  • 0 in reply to Andy Peters
    TI__Expert 5645 points

    Hi Andy,

    apologies for not being able to resolve the issue w. the data rate. I was trying some experiments on my end but was not able to draw the conclusion either. Part of the reason I was having issue with the part is that we do not have the design team which worked on this part to consult. Hence I could not help you in timely manner.

    Once again my apologies. I will continue looking at the internal details of the SRC family and will look at resolving the disconnect in DS revision once confirmed.

    Thanks and Best regards,
    Ravi

  • 0 in reply to Ravi Patil
    Genius 3945 points

    I've done some more inconclusive testing. I'd really prefer to not spend the money on the eval board if I've already got hardware built up.

    Did you do a test with a 44.1 kHz input and the 24.576 MHz reference clock? Either it locks, or it doesn't. In my case it never does. I can possibly gin up my board to do a 22.5792 MHz reference clock but that's not easy.

  • 0 in reply to Andy Peters
    Genius 3945 points
    Still not resolved. I'm going to have another board built up -- maybe there's something broken with the SRC4392 on my first article? I'll report back.
  • 0 in reply to Andy Peters
    TI__Expert 5645 points
    Hi Andy,
    i will test the same on my end w. the EVM and will report back as well. Sorry about the issue as we do not have design support for this device at the moment and will have to support based on bench evaluation.

    Best regards,
    Ravi
  • 0 in reply to Ravi Patil
    Genius 3945 points

    I'd buy the eval platform but it seems redundant, especially considering that it needs to connect to a host computer for register download.

  • 0 in reply to Ravi Patil
    Genius 3945 points
    I had a chance to work on this today.

    At first, I thought it was possible that the RXCLKI input was a poor choice for use as the DIR reference clock, despite it being the default. I came across a few designs that use the SRC4392 and had it, for whatever reason, configured to use the MCLK input instead of the RXCLKI input.

    Please note that my initial design uses RXCLKI driven by a 24.576 MHz oscillator. The DIR PLL1 configuration registers are set for the data-sheet specified values of P = 2, J = 8 and D = 0.

    It is easy enough for me to configure the design to use MCLK instead of RXCLKI as the reference clock. An added bonus of my design is that MCLK has two possible input clock frequencies, 22.5792 MHz and 24.576 MHz. I did a quick spin of code and ran some tests. With MCLK set to 24.576 MHz, the DIR locked only the sample rates that are a multiple of 48 kHz, just like my tests using RXCLKI for the reference. With MCLK set to 22.5792 MHz the DIR never locked, which was expected, given the PLL configuration.

    I next thought that I should test using MCLK at 22.5792 MHz for the DIR reference, with the PLL1 configuration set for that frequency per the data sheet. That means D = 7075 instead of 0. In this mode, the DIR was able to reliably lock on all sample rates 32 kHz, 44.1 kHz, 48 kHz and 88.2 kHz but it was not reliable for 96 kHz.

    Without changing the PLL1 configuration, I set MCLK to 24.576 MHz. I expected this to be completely unreliable, but! it was completely stable and it locked on all sample rates. This was a surprise.

    As a final test, I reconfigured the DIR to use RXCLKI at 24.576 MHz as the DIR PLL1 reference, but I left the PLL configuration to the value indicated for 22.5792 MHz. That is D = 7075 and not zero. And here we have a winner -- the DIR locked onto all sample rates from 32 kHz up to 96 kHz.

    I don't get it.
  • 0 in reply to Ravi Patil
    Genius 3945 points

    One final test. It doesn't lock on 192 kHz with the PLL1 settings for a 22.5792 MHz RXCLKI. As I noted, the lower frequencies lock.

    Time to build up another board to see if it's the chip itself that is to blame.