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

MMWAVE-L-SDK: AWRL6432: 30ms delay in I2C_probe

Chris Meng
Mastermind 37846 points
Part Number: MMWAVE-L-SDK

Tool/software:

Hi,

Customer want to reduce the device bootup time. They used I2C in their system and found there is a 30ms delay in I2C_probe. How can customer reduce it?

Below code seems to check if I2C status is correct or not, right? The NACK bit will set then clear, right? Any other way to implement this faster?

/* try to write one byte */
I2CControllerDataPut(object->baseAddr, (uint8_t) 0U);
I2CSetDataCount(object->baseAddr, (uint32_t) 1U);

/* stop bit needed here */
I2CControllerControl(object->baseAddr,I2C_CFG_MASK_STOP,(
I2C_CFG_CMD_TX | I2C_CFG_CMD_START | I2C_CFG_CMD_STOP));

/* enough delay for the NACK bit set */
ClockP_usleep(I2C_DELAY_BIG);

if (0U == I2CControllerIntStatusEx(object->baseAddr, I2C_INT_NO_ACK))
{
retVal = I2C_STS_SUCCESS; /* success case */
}
else
{
/* Clear sources*/
I2CControllerIntClearEx(object->baseAddr, I2C_ALL_INTS);

/* finish up xfer */
I2CControllerStop(object->baseAddr);
(void)I2C_waitForBb(object->baseAddr, I2C_DELAY_MED);

retVal = I2C_STS_ERR; /* Error case */
}

Thanks,

Chris

  • 0
    TI__Intellectual 2900 points

    Hi Chris,
          I have looped in our SW expert. Please allow us a day or so to provide the response.

    Thanks and Regards,
    Sivaprasad

  • 0 in reply to Sivaprasad K L
    TI__Mastermind 37846 points

    Sivaprasad,

    Any update?

    Thanks,

    Chris

  • 0 in reply to Chris Meng
    TI__Genius 13376 points

    Hey Chris,

    The customer can attempt to swap the I2C_DELAY_BIG with I2C_DELAY_MED (10 ms). Ideally, I2C acknowledgement should occur within the SCL cycle immediately following the last data bit, but clock stretching may delay this acknowledgement. Since there is no standard clock stretching timeout, it is up to the final user to designate a timeout period which is what the I2C_DELAY_BIG provides.  

    Decreasing the delay may lead to increased failures depending on the I2C slave device. If speed is the priority and the customer acknowledges these risks, then they can reduce the delay time.

    Cheers,

    Kristien