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.

TAS 5760LD after power on : first write I2C command will not deliver a acknowledge

Other Parts Discussed in Thread: TAS5760LD, TAS5760M

 The first wright I2C command will not deliver a acknowledge, only when first there is a 'read device'  executed then the first write I2C command will deliver a acknowledge.

If I use the "pure path console" in combination with "TAS5760EVM" then also there  first a  read device is executed followed with the register write dump.

This is never discribed in the data sheet of the TAS5760LD???????

So I am not able to execute the SW start up as discribed below:

Startup Procedures- Software Control Mode
1. Configure all digital I/O pins as required by the application using PCB connections (that is SPK_GAIN[1:0] =
11, ADR, etc.)
2. Start with SPK_SD Pin = "LOW"
3. Bring up power supplies (it does not matter if PVDD/AVDD or DVDD comes up first, provided the device is
held in shutdown.)
4. Once power supplies are stable, start MCLK, SCLK, LRCK
5. Configure the device via the control port in the manner required by the use case, making sure to mute the
device via the control port
6. Once power supplies and clocks are stable and the control port has been programmed, bring SPK_SD
"HIGH"
7. Unmute the device via the control port
8. The device is now in normal operation
It is important to note that control port register changes should only occur when the device is placed into
shutdown. This can be accomplished either by pulling the SPK_SD pin "LOW" or clearing the SPK_SD bit in the
control port.

 

  • Hi, Paul,

    Very interesting! I have asked my colleague to try and duplicate this here.

    -d2

  • For your information: on the pure path console driver the problem is the same.

    A additional question:

    How I can send: files/ plots scoop-/pictures via this tool communicator. Because this is helpfull to anlyse the problems...

  • Hi Paul,

    "The first wright I2C command will not deliver a acknowledge, only when first there is a 'read device'  executed then the first write I2C command will deliver a acknowledge."

    Do you mean if the first action you do is write, then there is not ack signial?

    I try  to dupicate your issue, here below is my result, you could see each ack as the marked note in blue.

    if any questions, please kindly let me know.

     

    Best Regards,

    RomanWang

  • Dear RomanWang

    I agree with your measurements, But the problem is after a power on: then the first wright action will not deliver a ACK, the next and all tfolowing will deliver a ACK.

    On the EVM tooling the first execute a read action to the classD version and then later on there are the wright action.

    On the EVM tooling the ACK is always present (due to the first read action), as indicated this is not as mentioned in the data sheet on the discription startup in case of SW usecase... then the first action after a power on, is a wright action .... and then the ACK is not present

  • Hi Paul,

    Do you mean if I try to use EVM to dulplicate your ack absent issue, when I click the button "connect", the "read" instructure has been excuted even I don't clik the "read" button, so that even I clik the " write" button "firstly", actully, the write instructure is excuted after read instructure.

    Am I right?

    and you asked  "How I can send: files/ plots scoop-/pictures via this tool communicator. Because this is helpfull to anlyse the problems", what's "files/ plots scoop-/pictures" means?

    Best Regards,

    Roman

  • Yuor statement is correct.

    If you make a logging of all the read and wrigt I2C commands then you will find a read device ater the "connect" and after a time all the wright commands to the classD (6C). Ofcourse after this each wright command will deliver then a ACK as you measured before.

  • Dear,

    The non-acknowledge I²C command...
    The problem occurs when the first writing command on the I²C bus is dedicated to the TAS5760.
    The TAS5760 answers with a non-acknowledge.
    If, however, the first command on the I²C bus is a read access to subaddress 0, the TAS5760 answers with an acknowledge, and all further communication is normal.
    Is this behavior recognized?
    Do we have to start with a read access?

  • Hi Paul,

    I still try to dulplicate your issue, After I connect the EVM, then I reset it(or re-power for TAS5760 but PPCMD still on) ,so all the "read" and "write" have gone, then I give a write command, which shoud be the real first "write" command, it shows the acnknowledge is not absent. as the below waveform shows

    So could you show me your I2C capture of scope, and initial script?

    Best Regards,

    RomanWang

  • I can also confirm this behavior and I'm glad to see that we are not the only ones struggling with this.

    The difference is that we are using the TAS5760M. The amplifier is controlled and initiated via I2C by a processor. When our hardware is powered, the SPK_SD pin is pulled low and after it is initiated via I2C the pin is pulled high by the processor. However, when trying to communicate with the amplifier, the first I2C byte from processor after power on is never acknowledged by amplifier. It is always just the first that is not acknowledged. We have confirmed with oscilloscope that I2C clock and data is signaled as expected.

    From what I understand, some I2C slave devices need a "start byte" to wake up before it can receive any other I2C commands, but I haven't found anything about such byte in TAS5760 documents. This "start byte" is described here http://www.i2c-bus.org/addressing/.

    Here are a screen dump of the I2C bus where you can see that the amplifier is not acknowledging the first command after power on:

    Here are a screen dump of the I2C bus when sending "start byte" and where you can see that the first I2C command afterwords is acknowledged: