• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 46 subscribers
  • Views 328 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.

ADS7924: Software Reset Timing Requirements

Ryan Summers1
Prodigy 50 points
Part Number: ADS7924

What are the timing requirements for the software reset on the ADS7924? It doesn't appear to be mentioned anywhere in the datasheet (similar vein to e2e.ti.com/.../755048).

I've placed a 100uS delay between sending the software reset request and attempting an I2C transaction with the device, but that doesn't seem to be sufficient. Increasing the delay to 500uS does seem sufficient in my test cases so far, but I'd like to know the actual required duration.

Instead of waiting for a fixed duration, I've also tried continuously polling the device over I2C, but when this is employed, the device will never ACK again (even over multiple minutes)

  • 0
    TI__Mastermind 24970 points

    Hello Ryan,

    After the device has been reset, you will need to wait a minimum of 2us before you can communicate with the device again, this is from the ADS833x datasheet that uses similar architecture. 

    Also make sure that the power supplies are stable and at the correct voltages. 

    Polling the device could corrupt the I2C communication, thus I would not suggest this method. 

    It seems to me that 500us may be too long, does only one device respond after this long?

    Regards

    Cynthia

  • 0 in reply to Cynthia
    Prodigy 50 points

    We originally were using a delay of 100uS, but in some cases, I believe it was too short. Here's a capture of the I2C lines during the transfer:

    image

    As shown, we issue a software reset by writing 0xAA to the device and then wait 100uS. We then attempt to communicate with the device again, but get a NAK. If the delay is increased to ~150uS or 200uS, this problem appears to go away.

  • 0 in reply to Ryan Summers1
    Prodigy 50 points

    Note that during hardware review, we also discovered an issue with the AVDD supply:

    The AVDD supply is thus always (very slightly) lower than the DVDD supply - is it possible that this is causing some temporary lock-up condition within the chip?

  • 0 in reply to Ryan Summers1
    TI__Mastermind 24970 points

    Hello,

    This is a meaningful find, the AVDD power supply needs to be equal to or greater than the DVDD. 

    This may be affecting the digital functions of the device. The ESD structure of the device may be turning on when DVDD surpasses AVDD, and this may be causing current consumption issues that are slowing down the device.

    I would suggest addressing the power supply regulation to make sure DVDD does not surpass AVDD. Then we can move forward with the debugging if still not fixed

    Regards

    Cynthia