• State TI Thinks Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 701 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

SRC4382 No Receiver Status Bits

David Glover
Prodigy 85 points

Other Parts Discussed in Thread: SRC4382

Hello,

I've run into a couple of issues with the SRC4382 device.  Firstly, it seems that if the device is taken out of reset and configured as DIR input to the SRC and the SRC as source for port B, and there is no valid AES signal input, port B does not output silence as expected (I have bit RXMALL set to '1' in register 0x0E).

Instead, port B outputs random 'noise' type data, that seems to pulsate every second or so.  Note that if you configure the part with the DIR as the source to port B directly (bypassing the SRC), then this problem does not occur.

To get around this problem, I decided to initially configure port B as muted, then wait for the DIR to lock before unmuting.  I then found that the UNLOCK bit in register 0x14 (Receiver Status Register 2) never indicates an unlocked condition even when the hardware pin LOCK# is de-asserted.

Unfortunately, I cannot use the hardware LOCK# pin in the circuit, as I intended to use the status register for this purpose and do not have access to the LOCK# pin without modifying the PCB.

I read in another post that you must unmask the interrupt for the UNLOCK condition in register 0x16 (Receiver Interrupt Mask Register 1, bit 2) in order to enable the register 0x14's status bit for UNLOCK.  However, after unmasking this interrupt, the UNLOCK bit in register 0x14 is still never asserting.

What am I doing wrong?  Help with either or both issues would be appreciated.

Thanks,

- David G.

  • 0
    TI__Genius 16270 points

    David,

    What is the level of the noise?  The noise that is seen should be the dithering of the SRC.  Regarding the LOCK interrupt in the registers, can you detail how you are trying to read this value?  Essentially are you reading it as a sticky bit, or as an interrupt?

  • 0 in reply to Patrick Galvin
    Prodigy 85 points

    The noise level moves between the entire volume range, from silence to 0dBFS.  I also forgot to mention that if I connect a valid AES input, then remove it, I get silence as expected from there on out.  The noise only happens after the initial configuration when no valid AES input has been applied.

    I am reading the UNLOCK bit in register 0x14 bit 2 via I2C.  I am polling the register, and printing the value out via the host.

    On that note, it could be that I'm not printing every read, and thus may be clearing the status bits before I get a chance to print them.  Do reads from register 0x14 also clear the bits?

    Also, by unmasking the interrupts in register 0x16, I was finally able to get one status bit to change value.  This is bit 0, RBTI.  This bit appears to be low when there is no valid AES input, and high when there is a valid AES input.  All other bits are always 0, but if I'm clearing the status bits on each read, I may just be missing the bits.

    Please advise.

  • 0 in reply to David Glover
    TI__Genius 16270 points

    David,

    Do you mean the noise itself gets up to 0dB?? If that is the case this is not the dithering, and could be an issue with the clocks.  What are the sources for MCLK (internal), BCLK, and LRCLK for port B?  For the unlock bit, it is normally notified as "sticky' if it is indeed a sticky bit.  For interrupt (non-sticky) bits, normally a read does in fact clear the bit. 

  • 0 in reply to Patrick Galvin
    Prodigy 85 points

    Yes the noise level ranges from silence up to 0dBFS (max volume, or very close).  It pulsates from low noise/silence, up to max volume briefly, producing a popping noise on the audio monitor.  The pulsing is periodic with about a 1 second interval.

    The SRC reference clock is set to the MCLK input, which is a stable 12.288MHz clock input.  Port B is setup as a slave with BCLK and LRCK derived from MCLK externally, which are 3.072MHz and 48kHz respectively.

    So are the status bits in register 0x14 interrupt only (non-sticky)?  If so, it would mean that I have no choice but to use the LOCK# pin for determining the lock state of the DIR, correct?

    All this would be OK if the data output of port B was low when there was no DIR lock.  Note that this is true (data output is low when no DIR lock) if I set the DIR as the port B source directly.  However, if I use the SRC between them (DIR -> SRC -> port B), I get this noise if there is no valid AES input.  But of course, after applying a valid AES input, then removing it, port B does output low data as desired.

  • 0 in reply to David Glover
    Prodigy 85 points

    I have been wondering if there is a recommended startup configuration sequence for the SRC4382.  Perhaps the noisy SRC output is an order of operations issue?

  • 0 in reply to David Glover
    Prodigy 85 points

    OK, I have found the solution.  If I keep all the internal modules in power-down (set register 0x01 to 0x00) while configuring the part, and then power everything up, it seems to come up with the expected behavior.

    It seems like this is an undocumented requirement for the SRC to function correctly, at least in my particular setup.

    Perhaps you could elaborate some on the next revision of the datasheet, unless it is in there already and I just missed it.

    Anyway, thanks for trying to help.

    - David G.

  • 0 in reply to David Glover
    Prodigy 85 points

    There is a caveat to this solution.  The SRC must be MUTE'ed originally when brought out of power-up, then unmuted afterwards.  I'm not sure if there is a minimum amount of time after powering up before it can be unmuted, but in my case it is several seconds.

    - David G.

  • 0 in reply to David Glover
    Prodigy 85 points

    Further caveats:

    1. The SRC source must originally be configured to DIR.  If it is set to port A, then switched to DIR after configuration and power-up, the noise returns (assuming I still have no valid AES input).

    2. Any time the SRC source is changed from any other source besides DIR, then change back to DIR, a full reconfigure of the device is necessary (may be able to simply power down, do the SRC source change, then power back up, not sure yet).  Otherwise, the noise on the port B output will return.

    If you happen to discover another, better solution, please let me know.

  • 0 in reply to David Glover
    Prodigy 85 points

    For completeness I thought I'd make one final update.  For my caveat #2 on the previous post, you can indeed simply power down the SRC4382 (write 0x00 to register 0x01) when changing the SRC source, then power back up and the noise on port B does not recur.

    If this behavior is inherent to the device, and not just to my particular setup, I expect that others have and will come across this issue.  I think it would be a shame if others had to switch to an alternate part due to this issue, it is a great part overall!

    Perhaps TI could confirm this behavior along with the fix and maybe include some brief information on this issue on a future datasheet or app note for the SRC4382 device.

    Thanks again for your support.

    - David G.