• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Answers 1 answer
  • Subscribers 30 subscribers
  • Views 638 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.

TAS5720A-Q1: I²C not ready fast enough

Thomas Müller
Prodigy 10 points
Part Number: TAS5720A-Q1
Other Parts Discussed in Thread: TAS5720L, TAS5720M

Hello community,

we currently have some issues with the TAS5720A-Q1. According to the datasheet, I²C should be active after 12 ms. In our case we power the TAS5720A-Q1 for over 100 ms with 12V (PVDD & AVDD) and with 3V3 (SPK_SD & DVDD) and still get a NAK for the first byte that is send by our controller.

If we do a soft reboot of our controller (12V keeps beeing alive) the TAS5720A-Q1 is then working as expected and sends his ACK for the first byte and for the rest of the communication.

Here are some screenshots:

Here a zommed out view. 12V on PVDD & AVDD for at least 100ms. DVDD and SPK_SD even longer on 3V3:

Same picture here, but zoomed in to see the communication:

Now, when the 12V are active for over 10 seconds (after soft reboot of our controller) the communications succeeds and is ongoing:

Here a zoomed in view as well:

Can you help us understand, what the problem could be? Any tips are welcomed. Let us know if you need more data.

Thank you all in advance!

Best regards,

Thomas

  • 0
    TI__Mastermind 45085 points

    Thomas,

    It seems that the device address is not being set.  Please follow section 9.2.1.2 in the datasheet.

  • 0 in reply to Gregg Scott
    Prodigy 10 points

    Hello Greg,

    in our layout, the SPK_SLEEP/ADR is connected to GND, the SCL and SDA of I²C is pulled up to 3V3. Here is a schematic of the TAS:

    Do you have any hint or idea, what could be responsible for the successful communication after soft reboot of our controller? Any tips on what signals we should check?

    Thank you very much!

  • 0 in reply to Thomas Müller
    TI__Mastermind 45085 points

    Thomas,

    When you first try it, do you have the I2S clocks present?  This must be present for the internal state machine to function.

    Regards,
    Gregg Scott

  • 0 in reply to Gregg Scott
    Prodigy 10 points

    Hello Gregg,

    With I2S clocks, do you mean MCLK, SCLK and LRCK? If so we encountered some issues with this. When we add measurement equipement to MCLK, SCLK and LRCK the TAS is working fine. If our measurement equipement is plugged out, the TAS is not working as expected.

    Here is a screenshot where we added measurement equipement for MCLK, SCLK and LRCK. These signals are low until audio data is transmitted. The TAS is working fine. Must these clocks be working for a stable boot? Is it just luck, that it boots as in the screenshot below?

    We recognized one more thing: According to the datasheet extract below, the whole time (from step 2 until step 6) the SPK_SD should be kept LOW to keep the TAS in shutdown. As you can also see in the screenshot above, our SPK_SD is high before all the power supplies are active. Is this a possibility for the malfunction?

    Thank you very much for your expertise! We appreciate every hint on what is wrong with our application.

    Regards,
    Thomas

  • +1 in reply to Thomas Müller
    TI__Mastermind 45085 points

    Thomas,

    It appears that the speaker fault is in an undetermined state until there is an SCLK, LRCLK, and SDIN signal available.  You should have them available.  When you have the test equipment unplugged are the I2S inputs to the TAS5720A-Q1 floating?  This is not good practice as these are high impedance inputs. 

    You have a solution as long as you ignore the Speaker Fault signal until you have proper clocks.  

    Regards,
    Gregg Scott 

  • 0 in reply to Gregg Scott
    Prodigy 10 points

    Hello Gregg,

    thank you for the information! The I2S clocks are currently floating at that point. We will try to initialize these pins earlier as we discovered, that this might help (we tried to pulldown these signals before and the TAS booted fine).

    One question from our software team:
    For the TAS5720L and TAS5720M, there are linux drivers available. Why is there no linux driver for the TAS5720A-Q1? We currently use a linux driver of one of the other TAS' which is slightly edited.
    If we solve this problem with non floating I2S clocks, are there other issues that could cause problems with the TAS5720A-Q1 when using linux?

    Thank you very much!

    Regards,
    Thomas

  • 0 in reply to Thomas Müller
    TI__Mastermind 45085 points

    Thomas,

    It is good that you found the floating I2S clocks to be the issue for I2C.

    We do not have linux drivers for the TAS5720A-Q1 device. The Linux drivers for the TAS5720L or M can be used, but may need to be slightly edited.

    We do not see any other issues using the TAS5720A-Q1 with Linux.

    Regards,
    Gregg Scott

  • 0 in reply to Gregg Scott
    Prodigy 10 points

    Hello Gregg,

    thank you for your quick response!
    can you tell me why there is no linux driver for the TAS5720A-Q1?
    Is there an overview of what needs to be edited in the linux driver to properly work with the TAS5720A-Q1?

    Thank you in advance!

    Regards,
    Thomas

  • 0 in reply to Thomas Müller
    TI__Mastermind 45085 points

    We do not provide linux drivers for automotive devices, as the software is developed by the customer and is proprietary to their systems.  All one needs is a basic I2C driver to talk to the device.

  • 0 in reply to Gregg Scott
    Prodigy 10 points

    Thank you very much for your answers! This helped us a lot!

    Regards,
    Thomas