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.

TXU0104: Outputs not enabled

Part Number: TXU0104
Other Parts Discussed in Thread: TXB0104

I'm using several TXU0104 devices to interface between 5V logic and 3.3V FPGA IO.  In all cases the OE input is tied directly to VCCB.  Shifting up, where VCCA == 3.3V and VCCB == 5V works as expected. However, shifting down, where VCCA == 5V and VCCB == 3.3V does not. In the latter case inputs with acceptable logic "1" levels do not generate suitable "1" levels on the B side. I have verified that the part is properly grounded, and that VCCA, VCCB, and OE are connected as expected. I have also verified that nothing is forcing the outputs low. In my bench test the outputs are actually disconnected from the FPGA load. Is there some other requirement that I've somehow missed in the data sheet?

  • Those are plain CMOS outputs; in theory, it should work.

    What exactly do you mean with "do not generate suitable "1" levels"? What is the voltage? Is the output being driven, or floating? Do all four outputs behave in the same way? What are the input voltages?

    The most common cause for these symptoms would be a solder bridge. Try checking for shorts when everything is unpowered.

  • Hey Brian,

    In addition to Clemens questions, could you provide scope captures showing the issue? It would be good to see the input, output, and OE signal.

  • Is there perhaps some issue with the power supply ramp? As I mentioned in my original post I am using the same part on the same board where VCCA is 3.3V and VCCB is 5V without any problems.

    In the first scope capture trace C1 is VCC_3V3, trace C2 is an output (pin 10), trace C3 is VCC_5V. Input pin 5 is tied hard to VCC_5V, OE is tied to VCC_3V3. All other inputs and all outputs are unconnected. 

    In another experiment the input is tied to VCC via a 1K resistor. In that case the input appears to be pulled by the part down to about half of VCCA and then after some chaotic activity on both the input and output, the output eventually drops to ground. See the second scope capture.

    Here C1 is VCC_3V3, C2 is input pin 5 (pulled to VCC_5V by 1K resistor), C3 is the output pin 10, and C4 is VCC_5V. OE is tied to VCC_3V3.

  • Correction: In the scope capture1 C1 is VCCA == 5.0V and C3 is VCCB == 3.3V.

  • Hey Brian,

    With this info I'm still confused with what you meant by "inputs with acceptable logic "1" levels do not generate suitable "1" levels on the B side." It seems like the issues you are showing aren't when the device is in a stable state and instead while the supplies are ramping. Is the ramping consistent with the up translation circuits that are working?

    I would like to see capture 1 with the input signal like capture 2. Its hard compare performance between the two configuration when the scope shots aren't apples to apples.

    As for the second scope capture:

    This shows about 1.8 V across that 1k pull-up which indicates ~1.8 mA through it. If this current was constant, I would assume damage to the input causing a short to ground. However, since there is a time where there is minimal drop across the pull-up, I'm lead to believe there is something else connected driving the input low during the falling slope. Are you certain there is nothing else connected to the input other than the pull-up? Are you able to monitor supply currents for the configuration where the input is shorted directly? 

  • Hi Dylan,

    You are actually looking at the input signal in the first scope image. C1 was on the input pin (5) of the device, which was tied to VCCA (by replacing the 1K pull up to VCCA with a jumper). C2 probe is on the output (pin 10), and C3 is connected to VCCB (which is the bench supply input). OE is tied to VCCB.

    I have already eliminated obvious problems like shorts and bad connections, having verified everything at the actual pins (vs pads) of the part.  Other inputs are disconnected, and all outputs are disconnected. Although I do see the same behavior on other inputs if I set them up the same way. Unpowered I have measured the resistance to ground on the outputs at about 28K. The resistance between outputs is basically open. 

    The same power supplies are running the parts that are working the in other direction (VCCA == 3.3V and VCCB == 5V). The topology is 3.3V to the board (which is currently being supplied by an Agilent E3631A bench supply), with the 5V being generated by an onboard LT3095 Boost/LDO regulator. I have measured the power at the device's VCCA and VCCB pins and it is 5.993V and 3.295V, respectively. I have measured the resistance from pin 7 to ground at a few mOhms.

    Irrespective of wether the input is tied high or pulled-up, the part settles into a state where the input is high and the corresponding output is low. To me it appears that the part has gotten into a strange internal state. I'm going to try making some changes to the power supply timing to see if it changes the behavior of the part. 

  • Regarding the second capture, I have not measured the supply current over time, although I could do that. It's steady state is about 49mA. The input eventually springs back to a valid high level (although the output is then invalid), so whatever is pulling it low seems to give up. But tying the device input directly to VCCA eliminates the possibility of external actors (see capture 1).

  • Hey Brian,

    My apologies, I do see now that the first capture does indeed show me the input signal since its shorted to the supply. I also see what you mean in the original post, when the supplies are steady state, the OE and Data input are High, the output should result in a High state as well. Instead we are seeing a Low state.

    I'm interested to see your results of different supply ramp timings. At this point I'm unsure of a few things:

    What is pulling down the input in capture two?

    Why does it oscillate from rail to rail at the input? - This is something you can expect to see holding a CMOS input close to 1/2 VCC (like in the scope capture), but the oscillations would be seen at the output side not the input. Not only that, but this device has Schmitt-trigger inputs which would eliminate this type of behavior due to the added hysteresis.

    Uncovering that may help us figure out why the output state is Low while the input is High. If you can perform current measurements then this will be valuable data to have. I'm going into lab tomorrow as well to see if I can whip up a quick circuit similar to yours to run some tests of my own.

  • Hi Dylan,

    Good questions.

    The only evidence right now is that the part itself is pulling the input down. I removed the part from the board and the input looks clean at power up. I can only conclude that the oscillation is also caused by the part.

    So a few new data points:

    1. I isolated the 5V supply to the part and the input so I could bypass the onboard power supply and provide VCCA from the bench supply. That changed the ramp times and relationships, but it did not improve the part behavior.

    2. With the part off the board, I checked for paths to other things and didn't find any. Which isn't surprising because the parts are very near a connector and there is very little track between the outputs and the connector pins.

    I'm reluctantly beginning to think I may have a broken part. A reasonable hypothesis is that the boards I've tested so far (3) are somehow breaking the device. It's a new design, and so there have been a few small surprises. Such as that the ramp time on the SMPS was ~500ms. I've fixed that, but is it possible that while ramping up over such a long time the part was in a stressed state that broke something? I don't see anything in the data sheet that would suggest this. But then 500ms is a long time.

    I've got some new parts coming in the next day or so and should be able to do some experiments off-board. I'll report back when I have more news.

    Thanks for your help. I'll be interested to hear what you find. 

  • Hi Brian,

    The only evidence right now is that the part itself is pulling the input down. I removed the part from the board and the input looks clean at power up. I can only conclude that the oscillation is also caused by the part.

    Based on what we have discussed and the info you have provided I'm beginning to think that as well. This is where my testing will be beneficial as I can pretty much eliminate all variables in my testing not related to the IC itself. Not only that but it may also help with understanding if the parts you are working with are damaged. However, nothing you've shown or explained leads me to think there could be damage from improper operation.

    I'll update you tomorrow on my progress. Feel free to post any thoughts or findings as they come up and i'll look them over.

  • Hi Brian,

    I managed to perform testing on this device, but my results were as expected. I couldn't exactly replicate the long ramp you had for the supplies, but I followed the sequencing order. I also monitored the current into the input during the ramp and it never went above ~1 uA, which is likely why I saw identical performance between shorting the input directly to VCC and using a 1k pull-up.

    Now I am more curious to see the results of you testing when adjusting the ramping and/or using a new unit to confirm there is no damage to the current one.

    I'm attaching my waveform for you to analyze. Let me know if you have any questions on it.

  • Hy Dylan,

    Thanks for checking that out. 

    Unfortunately the parts I ordered won't arrive until later in the week. But my curiosity is severe enough to maybe pull one of the working parts out of another circuit. I'll let you know what I find out.

  • Mystery solved!  

    I did some more experiments this afternoon and the results were even more puzzling. So I looked more carefully at the device markings. Turns out that, for reasons I am investigating now, the boards got built with the TXB0104 instead of TXU0104 parts. Which, of course, explains a lot.

    Dylan, I truly appreciate your efforts on this and I apologize for the fire drill.

  • Hey Brian,

    Haha ya that'll do it, no worries though that's what i'm here for.

  • Yeah, I got distracted by the other instances of the part on the board working. Looking at the data sheet for the TXB it's pretty clear what was going on. 

    Anyway, thanks again for your help. I'll close this out.