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.

TPS65986: Max Wake-up time from SLEEP after first I2C attempt, until next I2C attempt can be recognized

Part Number: TPS65986

I understand there is some time in transition from 100kHz sleep clock, over to 48MHz oscillator starting and stabilizing when transitioning to ACTIVE mode, so that the digital core is ready to process I2C commands.  Can we quantify the max time we could see from the "dummy" I2C command to wake-up the device, and when it is ready to process I2C commands?  

  • Hi Eric,

    I will double check with our team about this issue and then reply to you, thanks for your patience!

    Best Regards,
    Hao
  • Hi Eric,

    There is some delay for our device to come out of a sleep mode which is variable based on both hardware and firmware interaction that we have not quantified. Too long of a delay between sending I2C commands will have negative effects on the wake-up process as the TPS65986 could fall asleep again before the second I2C message is sent. Instead of adding a delay into the I2C master code, it would probably be safer to implement a retry mechanism so that the I2C master will keep retrying to send its messages until the TPS65986 acknowledges them. For example, if you see a NAK from the TPS65986, resend the last I2C message.

    This has not been reported as an issue by any other customer in the past. If the problem persists with the retry mechanism implemented, could you reproduce it on an EVM and advise us on the test setup?

    If this answers your question, PLEASE select  This resolved my issue

    Thank you,

    Eric