• State TI Thinks Resolved
  • Locked Locked
  • Replies 10 replies
  • Answers 2 answers
  • Subscribers 48 subscribers
  • Views 1349 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.

DAC101C081Q: I2C address question and broadcast address question

Oliver Lin
Expert 4435 points
Part Number: DAC101C081Q
Other Parts Discussed in Thread: DAC101C085, DAC101C081, DAC121C085

Hi team,

Our customer is seeing question with I2C for 2 questions.

1. From table1, why are we seeing 2 address for slave(red framed), is that one for DAC101C085 another for DAC101C081/Q?

2. About broadcast address, the address had already used by the other I2C device in customer system. Is there anyway to disable broadcast or change the other device address into non-broadcast address?

Thank you,

Oliver

  • 0
    TI__Genius 14220 points
    Hi Oliver,

    Thank you for your query. Please find my comments below:

    1. You an use either of the slave addresses specified in the table
    2. The broadcast address is common for all the parts in this DAC family. Unfortunately, this cannot be disabled. If possible, change the other devices to have an address that doesn't coincide with the broadcast address.

    Hope that answers your question.

    Regards,
    Uttam Sahu
    Applications Engineer, Precision DACs
  • 0 in reply to Uttam Sahu
    TI__Expert 4435 points
    Hi Uttam,
    Thank you for your quick reply. I have several following questions for address table. In the case, Our customer is using DAC101C081.

    1. From the slave address slot, we are seeing two "1000110" address. does it mean ADR0 pin is floating or GND sharing the same address?
    2. From table1, only top 3 slave address are defined, the others can be considered as no definition?

    BR,
    Oliver
  • 0 in reply to Uttam Sahu
    Prodigy 180 points
    I am sorry but I have the same questions as Oliver supplemented below, would you please explain them in more details for us?
    Thanks in advance.
  • 0 in reply to RICHARD CHANG2
    TI__Genius 14220 points
    Hi Richard, Oliver,

    Let me check this on the EVM and get back. I will get back with my results next week. Hope that works for you.

    Regards,
    Uttam
  • 0 in reply to Uttam Sahu
    TI__Genius 14220 points
    Hi Richard/Oliver,

    I checked it on the EVM of the device of the same family. Realized later that this device (DAC121C085) doesn't support the second set of I2C addresses. I am planning to replace the DAC on EVM by DAC101C085 (DAC101C081 is not pin to pin with that on the EVM). However, there is no stock in TI store at the moment. Is it possible for you to use the primary set of I2C addresses at the moment?

    Regards,
    Uttam
  • 0 in reply to Uttam Sahu
    Prodigy 180 points

    Hi Uttam,

    Yes, now we use the primary set of I2C addresses in our application,
    and we do not use the second set of I2C addresses at this moment.

    But we really have to modify the circuit to avoid to coincide with the broadcast address,
    so we want to take this chance to clarify why and how the second set of I2C addresses is used,
    and also we want to make sure if there won't be the 3rd I2C slave address that we have to avoid to coincide with,
    in addition to the primary set of I2C addresses and the broadcast address.

    May I say that, after you tested DAC121C085 and you will test DAC101C085 later,
    if the second set of I2C addresses is not supported in both of these two devices,
    we can take it for granted that DAC101C081 (of the same family) does not support the second set of I2C addresses, neither?

    If so, I just wonder why the second set of I2C addresses was noted in the table?
    Please advise.
    Thanks in advance.

    Best Regards,
    Richard C.

  • 0 in reply to RICHARD CHANG2
    TI__Genius 14220 points
    Hi Richard,

    I managed to order some samples of both DAC101C085 and DAC101C081. I should be be able to test both of them and confirm on the I2C addressing. Unfortunately, these devices being a bit old, I am not able to get design level support from internal teams. I can understand your concern and hope to resolve that through experimental data.

    I will receive the devices in a week or so. So, I should be able to get back with the results from my experiments in another 2 weeks. Please bear with me for the time being.

    Regards,
    Uttam
  • 0 in reply to Uttam Sahu
    Prodigy 180 points

    Hi Uttam,

    Thanks for your effort.
    I'll wait for your update on the other two devices.

    Best Regards,
    Richard C.

  • 0 in reply to RICHARD CHANG2
    TI__Guru 53773 points
    Hi Richard,

    As Uttam is on holiday, I thought I would clarify this issue. There are few other e2e threads about this issue:
    e2e.ti.com/.../2271141
    e2e.ti.com/.../540142

    Essentially, there is a typo/ambiguity in regards to the second set of addresses. The second column of address are just addresses that need to be avoided in the system as the DAC may acknowledge commands to that address under certain conditions, but not all conditions.

    For example, if you are using the address 0001100, then 1000110 will need to avoided on the bus.

    I have notified our systems team about this confusion.

    Thanks,
    Paul
  • 0 in reply to Paul_Frost
    Prodigy 180 points

    Hi Paul,

    Thanks for your clarification.

    After I read your explanation and the other two e2e threads,
    now I am clear about this issue and have no more question.

    Our application is under integration and test now,
    and we have avoided using the broadcast address (1001000, and its counterpart, 1100100) and the 2nd address of DAC101C081 with ADR0 grounded (1000110) on the same bus.
    And now, we'll have more confidence in the usage of DAC101C081 in our other applications.

    Thank you very much and wish you a merry Christmas and happy new year.

    Best Regards,
    Richard C.