• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 63 subscribers
  • Views 463 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

LP5562: I2C SCL,SDA maximum rise time for 100KHz clock (Standard-mode)

Tal Segev
Prodigy 50 points
Part Number: LP5562

Dear Sir/Madam, hi.

According to the LP5562 specification [1], the maximum SCL/SDA rise-time requirement is 300nS (Table 6.8, page 6), the same as described by the I2C standard [3] (Table 10, page 48) for a Fast-Mode (400kHz clock). But I'm using the Standard mode up to 100kHz (in my case 90kHz), and the standard [3] requirement for the Standard-Mode (100KHz clock) is 1000nS. Does the 300nS requirement still stand for the Standard-Mode (100kHz clock)? Or the rise-time requirement for the Standard-Mode is described at the standard [3].

Please note I'm measuring the rise-time as described in a previous thread [2], 10% to 90%, which differs from the standard [3] described in Fig-38, page 50.

[1] https://www.ti.com/product/LP5562
[2] https://e2e.ti.com/support/power-management-group/power-management/f/power-management-forum/1021633/lp5562-rise-time-and-fall-time-of-i2c
[3] https://www.nxp.com/docs/en/user-guide/UM10204.pdf
[4]

  • 0
    TI__Expert 6440 points

    Hi,

    Sorry but I'm not quite understand your question, do you mean your I2C signal will have 1000ns rise/fall time?

    Maybe you can provide me the waveform of your SDA/SCL signal so we can help you verify if it is available for our device.

    Thanks!

    Ives Li

  • 0 in reply to Ives Li
    Prodigy 50 points

    Hi,

    Yes. According to the I2C standard document, the rise-time requirement is a maximum of 1000uS for the Standard Mode [1] [2].

    I've attached two pictures of the signal (same picture with different rise-time measure methods) [3] measured by 10%-90% and [4] measured by 30%-70%—and Two photos from the I2C standard [1] Figure 38 and [2] Table 10.

    [1] Figure 38 from the I2C standard.







    [2] Table 10 of the I2C standard




    [3] I2C signal with rise-time measured from 10% to 90% (values on the bottom left, SCL rise-time = 841.808nS, SDA rise-time = 935.421nS)



    [3] I2C signal with rise-time measured from 30% to 70% (values on the bottom left, SCL rise-time = 335.364nS, SDA rise-time = 379.677nS)

    [5] high-resolution pictures are attached as a zip archive

    pics.zip

  • 0 in reply to Tal Segev
    TI__Expert 6440 points

    Hi,

    Thanks for your information.

    I noticed that the rise time is about 900ns, which is over our spec. But the 100kHz frequency is available for our device.

    So, I suggest you reduce the pull-up resistor's value, it will be helpful to reduce the rise time.

    Besides, considering this specification is ensured by design and is not tested in production. If you can only provide 1000ns rise-time I2C signal, I suggest you test the condition on EVM to ensure it is OK for operation.

    Thanks!

    Ives Li

  • 0 in reply to Ives Li
    Prodigy 50 points

    Hi,

    The system works as expected (no EVM is required), and I've noticed the issue while performing a DVT (host I2C device is CC1352).

    I've already checked the PU reduction; to reach the 300nS (from 900nS 10%-90%), I need to reduce the PU resistor drastically. The reduction causes the Vol to rise to above 0.5V, which causes the system to fail (already checked this solution); currently, Vol ~= 0.26V (see above pictures).

    So Taking all consideration, we are back to square one and the original questions:

    Does the 300nS requirement still stand for the Standard-Mode (100kHz clock)? Or the rise-time requirement for the Standard-Mode is described in the I2C standard document.

  • 0 in reply to Tal Segev
    TI__Expert 6440 points

    Hi,

    The 300ns requirement still stand for the standard-mode for our device, because that's how our datasheet mentioned.

    We still suggest following the datasheet's requirement even it maybe can work on 1000ns rise time condition. 

    Because we cannot promise you the spec which is over the datasheet.

    Thanks!