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.

TCA6424A: Quiescent current with VCCI powered and VCCP unpowered

Part Number: TCA6424A

I plan on using this IO expander for a battery application that needs to have very low quiescent current when not operating.

VCCI will be perpetually powered by 3V3, however VCCP will be powered by a 5V auxiliary reg that can be turned off whenever the device needs to enter a low power state.

What quiescent current can I expect through VCCI while VCCP is at 0V?

Are there any other considerations I should take with the P-terminals for a low power state? I figure since everything on the P-side will be powered by the 5V auxiliary rail I shouldn't have much to worry about for leakage currents there. I also don't expect that the VCCI side should misbehave at all while VCCP is at 0v.

  • Joshua,

    Our applications team is looking into this and will get back to you as soon as possible.

    Regards,

  • Thanks for the update Eric.

  • Joshua,

    When you keep VCCP unpowered, you are effectively holding the device in a power-on reset condition (see datasheet section 8.4.1). When unpowered, the P-ports of the device are in a high-impedance state. I understand that you’re asking about supply current, however. I have a few clarifying questions:

    Will all of the P-ports be held at 0 V as well while VCCP = 0?

    Do you plan on trying to interface with the TCA6424A while VCCP = 0? Keep in mind that the device is not functional in this state.

    Best,

    Danny

  • Danny,

    Good questions. I was expecting the device to be in a POR state while VCCP = 0. Some P-ports would have resistor pulldowns as they are just being use to turn on NMOS gates. Others will directly power LEDs so they will have a resistor and LED to VSS on each of those. I assume the unused P-ports would need something like a 10k pulldown to keep them from floating.

    Your question about interfacing brings up an important question though. While I do not plan on interfacing with specifically this device over I2C while the 5V auxiliary is not being powered, however I still need to be able to communicate  with other devices on the bus. A possible workaround is to just use a second I2C port on the micro that I am using. Would the device prevent other I2C communication while in a POR state?

  • Joshua,

    Sounds like VSS will remain powered, unless you mean that it will also fall to VSS = VCCP = 0? Maybe I misunderstand your LED setup. Are you using this kind of architecture below? Just trying to clarify your theoretical placement of the 10k pull-down.

    Regarding I2C communication: the TCA6424A will not interfere with I2C communication with other devices on the bus while in POR or when unpowered. It does not pull down on SCL/SDA unless communicating. I was only mentioning this to indicate that you would not be able to control the TCA6424A itself when VCCP = 0.

    Best,

    Danny

  • Danny,

    These were the three use cases I was planning for on the Px ports. Directly powering an LED, manipulating a FET gate, and pulldowns for unused ports.

    Thanks for the info on how it will affect I2C during POR. I plan on always powering Vcci as shown in the picture. If I gate or turn off 5V to Vccp there should be no power to the peripheral side however I am just concerned about the quiescent current through Vcci in this state as it was not defined in the datasheet.

    Also please let me know if the use cases for the peripherals are acceptable or need some changes. Any input is much appreciated.

  • Joshua,

    I'm still looking around to see if we have any information regarding the current consumption during a reset condition. Sorry for the delay on this particular info - I know it was your first question! :)

    As far as the peripherals go, thanks so much for the diagram. The second implementation looks fine to me. The third looks fine as well, given what I can see on it.

    For the LED, this implementation is operational, so if it's already in design, then there is no worry. If not, I'd like to recommend connecting in the configuration shown in Figure 30 above and reproduced here:

    I/Os are frequently used to control LEDs by connecting to VCC through a resistor. One issue that could arise from normal series I/O implementations is current consumption through the I/O device. Let me give you an example. Let’s say the I/O port is set as an input (e.g. during startup). Even though the LED is off, the I/O pin would be floating by some amount somewhere between GND and VCC due to the diode characteristic. This causes increased current consumption across the I/O stage of this P-port. You can solve this by adding a high-value pull-up resistor in parallel with the LED/resistor, shown as a 100 kΩ resistor above. This will make it such that the pin is pulled up to VCC­ whenever the LED is off.

    Obviously, changing your design to connect as shown in Figure 30 would indicate opposite logic for the LED compared to your current implementation.

    I see no functional reason why you could not connect a parallel resistor from Px to GND if you prefer. Just note that the Px port of the TCA6424A is a stronger current sink than it is a source:

    In Figure 7 we see approximately 27 mA sink current at VOL = 0.3 V, while in Figure 12 we see approximately 21 mA source current at VCC – VOH = 0.3 V.

    Still working to see if we have any info on the quiescent characteristic during reset.

    Best,

    Danny

  • Danny,

    Thanks for all this info. Also thanks for still looking into the original question!

    The third implementation in my picture was just a pulldown for the unused IO. I doubt it matters whether it is a pullup or pulldown for keeping the Vcci quiescent current low, especially when I am only concerned about current when Vccp is unpowered.

    I did notice from the datasheet that it looks preferable to sink current for driving LEDs but your explanation helps me grasp the implications much better. I’m glad that I don’t need to change my design because some decisions have been made already preventing me from using the sink method to drive the LEDs.

    On a side note, why do the graphs spec currents greater than 25mA for source and sink when that violates the absolute maximum ratings for P ports?

    I’m excited to find out more on what the team discovers. Thanks!

  • Joshua,

    Thanks so much for your questions! Apologies for the delay - I was out of office for the holiday.

    The good news is that I have answers to both your recent question and your original question. First:

    JOSHUA ANDERSON said:

    What quiescent current can I expect through VCCI while VCCP is at 0V?

    I have spoken with a few of my colleagues. This device is set up such that VCCI just powers the SCL/SDA input buffers (plus some level shifters). Thus, this means that you should not see an impact on the operating source current draw when VCCP is altered (even to 0 V). In the TCA6424A datasheet, you may have noticed that the source current characteristic ICC is defined as the sum ICCP + ICCI. Given that the P-ports are configured as unloaded inputs for this characteristic, I'd say the majority of that sum likely comes from ICCI, however we do not have test data at hand to confirm this 100%.

    What I can say is that there should not be a concern of increased current consumption into VCCI while you have VCCP = 0 V. Since these are separate sources, leaving VCCP unpowered will not cause an increase in current consumption for the VCCI pin. This current consumption is mainly driven by the activity of the SCL/SDA pins (see Electrical Characteristics). Just make sure that SCL and SDA are always at either VCCI or GND (not left floating). This will prevent any extra current flowing through the I2C input buffers, resulting in increased ICCI.

    Secondly:

    JOSHUA ANDERSON said:

    On a side note, why do the graphs spec currents greater than 25mA for source and sink when that violates the absolute maximum ratings for P ports?

    I'll point out the first note "(1)" under the Absolute Maximum Ratings section. The performance of the device is not guaranteed when brought outside the absolute maximum ratings, but these Typical Characteristics graphs still show how the ports are expected to behave under these conditions. Your question is a little more philosophical than technical, but your intuition is correct: you still should not exceed the absolute maximum ratings, as this could cause device damage.

    I hope my answers are clear and helpful!

    Best,

    Danny

  • Danny,

    No apology necessary. I partook in the holiday as well.

    Your answer to my first question is about as thorough as I could wish for. It makes sense and provides a broad context on everything that is going on inside the package.

    Your second answer I have very much enjoyed. Such are the dilemmas when trying to specify the empirical behavior of a device while upholding boundaries with which reliable performance can be guaranteed.

    Thanks again for all the help!