• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 30 subscribers
  • Views 1018 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.

TAS5727 I2S not working, please help!

James Moscola
Prodigy 50 points
Other Parts Discussed in Thread: TAS5727, TAS5727EVM

We’re working on a project that uses a Bluegiga WT32 Bluetooth module as an A2DP SINK and sends the audio data out of the WT32’s I2S interface to a TI TAS5727 amplifier chip. To assist with development we’re using a WT32 Dev Kit along with a TI TAS5727EVM Dev Kit.

- Currently, the I2S header pins on the WT32 dev kit are connected directly to the I2S header pins of our amplifier’s dev kit. The WT32 will act as a master and send data to the amplifier.

- Both dev kits share a common ground.

- We can configure the amplifier chip on the TAS5727EVM and play I2S audio that the amplifier receives from another component on the TAS5727EVM dev kit. That component is a TI PCM1808PW. However, when we try to send I2S audio to the amplifier from the WT32, we get no sound.

- We can successfully pair with, and connect to the WT32 Bluetooth module using a mobile phone.

- We can successfully play Bluetooth audio from the WT32 dev kit using a line out on the dev kit.

- We’re fairly certain that the reason we can’t get the amplifier to play I2S audio from the WT32 has to do with the configuration of the I2S interface. Currently, that is the only link in the chain that we can’t seem to get working. The TAS5727 amplifier chip reports various clock errors (register 0x02) when we try to send I2S audio from the WT32 to the amplifier. We’re reading the clock errors over I2C and see values of 0xB0 and occasionally 0xC0 depending on how the WT32 is configured. 0xB0 indicates a error on MCLK, SCLK, and LRCLK. 0xC0 indicates an error on MCLK and a PLL autolock error.


Here are some of our configuration settings on the WT32:

WT32 is freshly flashed with iWRAP 5.0.2 build 764 (Generic).
Over a serial connection, we set the following:

SET BT CLASS 240428
SET PROFILE A2DP SINK
SET PROFILE AVRCP CONTROLLER
SET CONTROL CODEC SBC JOINT_STEREO 44100 0
SET CONTROL AUDIO INTERNAL I2S
RESET

From here, we can pair and connect with the WT32 and begin sending audio from a mobile phone. We can clearly observe the digital audio signals on the amplifiers SCLK, LRCLK, and SDIN pins using an oscilloscope.

- LRCLK runs at the expected 44.1 KHz as reported by our o-scope (f_s = 44.1 KHz).

- The TAS5727 requires both an MCLK and SCLK. Since the WT32 doesn’t provide an MCLK, we are feeding both the MCLK and the SCLK inputs of the TAS5727 with the PCM_CLK output of the WT32. For the TAS5727, this means that both the MCLK and the SCLK inputs need to be running at 64 * f_s (or 2.822 MHz). This is because the maximum rate for SCLK on the TAS5727 is 64 * f_s and the minimum rate of MCLK on the TAS5727 is 64 * f_s. The frequency 64 * f_s is the only overlapping value that is valid for both MCLK and SCLK.


- QUESTIONS:
=============

Given our current configuration, is there anything that jumps out as obviously wrong?


What might cause the TAS5727 to continually report clock errors even though we can see the clocks are behaving as expected via our o-scope?

Does anyone have any experience debugging I2S interfaces and con maybe provide some tips, suggestions, debugging ideas, or even long-shot guesses at what the problem might be?


Any comments would be greatly appreciated. I feel like we’ve tried just about everything with no luck.


Thanks for reading, and hopefully for your comments.

  • 0
    TI__Genius 9175 points

    Hello,

    It sounds like and I2S timing issue.  Have you configured the TAS part for the right number of bits? It is configurable for 24, 20, and 16 bits. This would need to match the bit depth of the I2S source.

    Since you are setting your clocks at 64*Fs you are setting the bit depth as 32 bits for a 44.1KHz sample rate.

    Also run through the I2S timing diagrams and compare.

    Regards,

    Matt

  • 0 in reply to Matthew Beardsworth
    Prodigy 50 points

    Matthew, I agree that it seems like a timing issue.  I just can't seem to figure out where I've gone wrong.

    Our Bluetooth module (the WT32) can be configured run at 16, 20, or 24 bits.  However, regardless of the configuration, I believe it only sends 16-bits per left channel and a second 16-bits for the right channel.  If running in 24-bit mode, the documentation for the WT32 states that it will send 16-bits of data and then zero out the remaining 8 bits.

    We have tried configuring the WT32 for all three modes, and also tried configuring the TAS5727 to match the WT32 config.  However, we haven't had any luck.  On the TAS5727, we've configured register 4 to 0x05 (I2S 24-bit word length) -- we've also tried setting reg 4 to 0x04 and 0x03 (I2S 20-bit words / 16-bit words).  However, no matter what settings we try, we cannot seem to get audio to play over I2S.

    In an attempt to make sense of everything that was going on and to verify our settings, we've been using an o-scope to view the signals coming out of the WT32 Bluetooth module.  

    - I can confirm that LRCLK is 44.1 KHz as reported by my scope.
    - I can confirm that SCLK and MCLK are both 2.8224 MHz (64 * f_s) on my scope.
    - I can confirm that there are 32 MCLK/SCLK edges for each left channel word and another 32 MCLK/SCLK edges for each right channel word.
    - I can confirm that the first bit of data doesn't occur until the second clock edge of each sample
    - I can confirm that there are 16-bits of data for each word coming from the WT32. Data bits are available on the 2nd - 17th edges during each sample.  SDIN remains 0 during edges 18-32 of each sample.

    Any thoughts?

    James

  • 0 in reply to James Moscola
    TI__Genius 9175 points

    Hi James,

    One thing that jumps out at me is you keep mentioning 64 *Fs. Remember to change the bit clock rate as you change the world length.

    If you want to run 16 bit words, (16 bits per channel that is) you need to make sure you change the clocks to the correct bit timing to 32 * Fs. If you run it faster, at 64 * Fs, it will latch twice as many bits within the same channel (repeating each bit in a 16 bit word twice) and not work.

    Also, regardless if WT32 adds zeroes, make sure its world length always matches the TAS5727. The zeroes just allow the WT32 part to work with a larger fixed word length destination source easily.

    Fs* 64 only will work with 32 bits words.

    In simpler terms, if you are running 16 bits per channel word, then the clocks should also run 16 bits per channel word. It sounds like right now it is always running 32 cycles for each channel world.

    Regards,

    Matt