• State TI Thinks Resolved
  • Locked Locked
  • Replies 2 replies
  • Answers 1 answer
  • Subscribers 33 subscribers
  • Views 450 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.

TPS65982: Three condition to exit SLEEP mode

Tamio Yokokura
Expert 3960 points
Part Number: TPS65982

I have some question about three condition to exit from SLEEP mode.

As for "Any Reset Event", ...

I think that this "Reset Event" means that HRESET pin and MRESET pin is toggled by EC.

Are there any other Reset Event?

As for "I2CBus Activity", ...

According to my evaluation, the rising edge of SCL three times at least is to exit from SLEEP mode. SDA doesn't relate.

Why is the rising edge needed three time?

As for "Any Enabled Interrupt Event", ...

The Firmware Users Guide is mentioned that "the interrupt event is I2C interrupt reuest, supervisor events, CC attach or detach events, and so forth."

Now, "Plug Insert or Removal" in Interrupt Event Mask 1 / 2 is enabled. In that case, is I2C 1 / 2 IRQ asserted when the cable is attached in SLEEP mode?

What is the waiting time until I2Cx IRQ is asserted after a valid interrupt event occur?

As for System Power State (0x20), ...

Basically, "System Power State" (0x20) is set to Sx by EC and as default value.

Does 982 never reset "System Power State" even if power state is changed to S0?

When I evaluated, I observed the phenomen that SDA was LOW for 100ms when 982 exited from SLEEP mode

Why did SDA become LOW?

Regards,

Tamio

  • 0
    TI__Expert 3960 points
    TPS65982 support team,

    Please give me your comments. Our customer is waiting for your comments.

    Best Regards,
    T.Yokokura
  • 0 in reply to Tamio Yokokura
    TI__Genius 16370 points
    Yokokura-san,

    Ans-1: Yes - These events will cause 982 to exit sleep state.
    Ans-2/1: Why three cycles exactly is something that I need to check, but in general, the device shall account for unwarranted transitions on the line (that could result in false triggers) before treating it as a valid transaction, and therefore the additional cycles. Can I understand the customer's concern here?
    Ans-2/2: Is your question related to the latency b/w the occurrence of the event and assertion of the I2C_IRQ? If yes, then this depends on the event and cannot be generalized. For example, 982 does some internal processing on a plug-event before triggering an event on the I2C_IRQ line.
    Ans-3: I'll check internally on why the SDA is held low, but 100ms is the activity timeout, and if no activity is seen for this time, the device will return to sleep state.

    -/Praneet