TAS5709 I2C Communication Problems

Matt,

The TAS5709 typically uses 4.7k pullups to 3.3V for the I2C SLK and SDA lines. 

Thanks,
Brian

Hi Brian,

Ok, that's what I am using. However I seem to be seeing some weird behaviour.  We have written a custom driver (linux kernel module) for the TAS5709 and have it connected to an Atmel ARM9 processor running Ubuntu.  The module loads without any errors we are able to find the chip on the I2C bus at address 0x1b and initialize it properly.  We can then play sounds through our alsa driver perfectly.  However, after many repeated play backs (in the hundreds), the chip suddently become un-responsive to I2C commands (i.e. no ACK's).  From this point on we cannot communicate chip and thus cannot play any sound.  Even after a reboot of the cpu the chip remains unresponsive.  It seemd the only way to fix the problem is to cycle the power to the board.  I'm really at a loss as to why the chip would all of a sudden stop responding to I2C after working properly for ~500 playbacks.

Here is the processes we perform

Module initialization (after linux has booted):
-----------------------------------------------------------

o Write 0 to register 0x1b
o Read register 0x01 to verify device id
o Write 0 to register 0x02 (error clean up)

Module unloading (shut down):
-------------------------------------------
o Write 0x03 to register 0x06 (soft mute)
o mdelay(50)
o Write 0x40 to register 0x05
o mdelay(165)
o Read register 0x02 to catch any reported errors
   (We usually get 0x6c here).

Before playing a sound stream
--------------------------------------------
o start MCLK
o Write 0x03 to register 0x04 (I2S 16-bit audio)
o mdelay(50)
o Write 0 to register 0x05 (exit shutdown)
o mdelay(165)
o Write 0 to register 0x06 (soft unmute)

Note: the current version of the driver may repeat the sequence in the
last three steps above several times as dictated by the ALSA driver
opening simultaneous audio streams.

After the sound stream is played
-----------------------------------------------
o Same as module unloading

Let me know what you think. Thanks for your help.
Matt

Matt,

If you haven't been able to reproduce the error in the same number of playbacks, then my initial thought would be the line capacitance is incorrect and you may be driving too many devices.  Incorrect capacitance can cause glitches on the line, causing unknown errors.  Also make sure the bus voltage level is compatable for all devices. 

If you could, give me a little more description about the bus settings? Voltage, number of devices, etc.

Thanks,
Brian 

Hi Brian,

The TAS chip is the only device on the I2C bus and I have monitored the voltage on the line and it appears to be stable at +3.3V.   

Matt

Brian,

We're now very close to satisfying the 300 ns rise and fall time requirements, however the issue is still occuring.  In my testing, the most recent failure happened after only ~60 playbacks.

Matt