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.

SN74AXC4T774: leakage current

Part Number: SN74AXC4T774
Other Parts Discussed in Thread: SN74AVC4T774, SN74AXC1T45

According to the datasheet, the input should not leak more than 4 µA. My TI SN74AXC4T774 samples have about 20uA of leakage to ground.
When SN74AVC4T774 is mounted on the same board, the leakage is less than 1µA.
Power supply is 3.3V. PCB is clean. 20°C

What is the difference between AXC series and AVC in terms of input current leakage?
Did I miss something?

  • Hey Konstantin, 

    Just for verification purposes, would it be possible to measure the impedance of the input pin without any external resistors connected to it? Also how many samples has this impacted? Could you also confirm that the /OE pin was tied to GND at the time of testing? 

    Regards,

    Jack 

  • 3 mounted boards samples with chips from from 2 sources. One of source is TI samples.
    At the time of testing /OE pin was tied to GND.
    All 3 board works fine with SN74AVC4T774.

    One of board with leakage issue was swapped to AVC chip. problem disappear.
    In a way to eliminate potential mounting issue or flux conductivity AXC was mounted back. 20µA was appeared.
    AVC mounted again - no leak.
    New AXC chip from different source (TI samples) - about 20µA leak.

    Would you like to measure the impedance of a powered chip? At what voltage?
    My setup consists of two 4.7 kΩ resistors in series used as a voltage divider. The middle point (half of 3.3V) connected to the input pin pulls the voltage down.

    Sorry to repeat - there are no such problems observed with AVC logic.

    I would be grateful if someone reproduces and confirms (or refutes) the problem.

  • Hey Konstantin,

    The AXC family devices has glitch suppression circuitry and could be a possibility for the larger amount of leakage current seen. Seems to me like your case is similar issue as linked here

    Would you like to measure the impedance of a powered chip? At what voltage?

    Yes, if possible, could you measure the impedance of the input pins (w/3.3V power supply) without the two 4.7kohm resistors? 

  • Sounds similar.

    I may expect that behavior from bus-holder logic. My case is power stable without power supply transitions.
    Where may I see details about glitch suppression implementation used in AXC?

    Let me measure it differently later.
    BTW, what is the point to measure impedance without resistors (taking into account fact that it works with AVC)? 

  • Kim

    Please see this apps note for AXC glitch suppression details.


    Thanks,

    Yuan

  • Thank you. Excellent apps note.

    On which page of this article can I find "glitch suppression implementation used in AXC" ?

    I would appreciate it if someone reproduces and confirms the issue.

  • Hey Konstantin,

    This app note focuses only on measuring the power sequencing performance of the SN74AXC1T45 under different conditions thorough lab testing. However page 3 gives a top-level view of the implementation. 

    The goal of measuring the impedance of the input without any external resistors gives us a better understanding of the device (we expect the impedance input to be ~825kOhms). Could you verify the impedance value? 

    Regards,

    Jack 

  • What I see is 20µA leak down from the middle of Vcc. Which roughly gives 82.5kΩ (surprisingly 10x of expectations).

    variations between chips and pins is in range of 20..25µA (20%)

    Sorry. I have no idea how to measure impedance without any external connections... no connections - no current - no leaks
    I can do it with an external capacitor if that makes sense.

  • Hey Konstantin,

    Does the behavior show when VCC is not halved (VCC= 3.3 instead of VCC= 1.65)? Note that this "middle of VCC" means that the device is operating in the threshold region and can explain the large amount of power consumption. Do you also have a schematic that you can share? 

    Regards,

    Jack 

  • Hello Jack,

    I worked with Konstantin on this issue. Let me share some details and thoughts.

    First, for your understanding, here is a simplified schematic reimplementation of the circuitry we have:

    Then comes mass production testing. We tried to minimize the test fixture complexity, so we ended up with something similar to this, meant to be connected on IOs:

    Main idea was to use the two input connected to ADC pins of the MCU to validate various patterns on 774 IOs in a way we could assert measured voltages. For instance, setting [Vio=3.3V, IO0=Z, IO1=1, IO2=Z, IO3=0, Vtarget not driven] should give us ADC0=Vio, ADC1=Vio/2 (+/- some tolerance range).

    Note we do all testing with VCCA = VCCB = 3.3V, steady. We are not in VCC ramp-up conditions here.

    At the time of prototyping this design and testing it, AXC was out of stock at usual distributors, so we validated this design with SN74AVC4T774. Prototyping stage, including test fixture validation, was successful. We went to mass production.

    For mass production, BOM used AXC, it was available and sourced by OEM. That's where we get unhappy: it failed.

    After some investigation and delays, we found AXC and AVC were not behaving the same, in a manner we could not specify properly (i.e. we could not extract a general rule about how the chip behaved, and whether it was acceptable to us). For some time, we suspected our OEM sourced some defective/counterfeit chips, which was not the case: We ordered AXC and AVC samples directly from Ti and confirmed the issue on production PCBA samples.

    Overall, when doing back-calculation from voltages measured on ADC pins to equivalent resistor network, we had an unexpected 10-20 kΩ pull down on IOs. Actual pull down value was unstable depending on IO and configuration of other outputs (i.e. [IO0=Z, IO1=1, IO2=Z, IO3=0] was not giving the same results as [IO0=Z, IO1=0, IO2=Z, IO3=1] on IO2, by far).

    After some discussion here, we understand this is most probably from glitch filter. Nice. Now I wonder, could we have guessed this "statically" from datasheets ? Not quite. Here is why:

    • This glitch filter is advertised as an output driver feature on ramping of VCC. "Glitch Free Power Sequencing With AXC Level Translators" (SCEA058A) focuses on unstable VCC conditions. In our setup, we only use steady VCC conditions, we let voltages stabilize for hundreds of milliseconds before performing measurements. Moreover, in figure 2 of SCEA058A, glitch filter is drawn on the output line (sure enough, glitch filter block is not output-enabled, so it is always active, but this is misleading). Overall, there is no clear warning about the glitch filter polluting HI-Z inputs in a stable VCC condition there.
    • SN74AXC4T774 datasheet (SCES898B) does not define clearly that there is an always-active glitch filter on inputs whether when pin is Hi-Z or not. Note (2) of Table 8-1 that says "Pins configured as inputs should not be left floating", but again, this does not apply in our case: we are driving the pins. Table 6.3 links to "Implications of Slow or Floating CMOS Inputs" (SCBA004E), but this document does not contain anything about AXC.
    • Electrical characteristics in SN74AXC4T774 (SCES898B) 6.5 / SN74AVC4T774 (SCES693G) 7.5 are not so much different and does not allow to suspect this.

    At some point, main question was to tell whether this behaviour is totally synthetic and only visible in our test conditions, or if it was a potential problem to main equipment functionality. We could not assert this because of lack of details in datasheets. In the end, we rolled back production to AVC, loosing 0.65-1.1V range. We were not amused.

    What I would suggest is:

    • define glitch filter as a pin feature, not as an output stage feature,
    • tell glitch filter is also active when both VCCs are stable,
    • tell glitch filter is also active if pin is Hi-Z because of direction pins (an maybe when /OE is high as well ?),
    • add a mention AXC input stage does not cope well with V_IL < pin < V_IH at all, even in Hi-Z conditions,
    • update SCBA004E to add AXC,
    • redraw figure 2 of SCEA058A to have one line connecting "Port", "In", "Out" and "Glitch suppression" blocks, without arrows.

    Regards

  • The input buffers are always active, so the voltages at all I/O pins must always have valid logic levels (< VIL or > VIH). No CMOS device copes well with invalid voltages; both the AXC and AVC devices have high shoot-through currents (to be able to notice this, you would need to measure the supply current). The glitch filter is at the outputs, but it is intended to help the inputs of both the AXC itself and of other connected devices.

    The input leakage current is specified only for valid input logic levels. Furthermore, an invalid input voltage at one pin could affect other output pins (see this example).

    The problem comes from forcing the pins to invalid voltages. Assuming that you do not do this in your actual application, the AXC will work fine.

    SCEA058 does not tell how it detects a glitch. Apparently, it detects invalid voltages with a window comparator(?), assumes the pin is floating, and activates the pull-down.

  • I agree with you.

    I would be OK with excess consumption during test. That is not the point here.

    The only problems to me are the underspecification of "glitch filter" and the misleading focus around VCC ramping and output-only.

    Looking at forums, it appears we are not the first to get bitten by this, and it seems documentation did not improve yet.

  • Please take a look at the measurements I got. 30KΩ pulldown active under half power supply threshold.

    It explains why sometimes we don't have leaks. this seems to happen when the divider produces an middle voltage with a tolerance of components above the average.

    I hope I didn't confuse anything..

  • 3 measurements show little difference.
    It lies in the fact that the first two refer to double inputs connection (with double leakage), and the third is single.
    i.e. the pull-down impedance is estimated to be roughly 60 KΩ per input in my case.

  • Hey Nicolas, Konstantin, 

    We are aware of this issue with the dynamic pulldown resistors in AXC devices that its causing and currently looking into it- previously we created this FAQ for this case, but more visibility is needed as you mentioned. 

    Thanks for bringing this to our attention. 

    Regards,

    Jack 

  • Thank you! This is exactly what I was looking for 30 days ago ;).

    To me, the de-glitching implementation looks like open-drain busholder/keeper logic.

    FAQ: "If there is a need to have pull-ups connected to the I/O of an AXC translator, it is recommended to keep the value below 30 kΩ." may pretend to be part of datasheet.