Logic forum - Recent Threads

SN74LV1T34: VCC=open, Input=3.3V

Shuji Ishiwata — Mon, 29 Jun 2026 02:41:43 GMT

Part Number: SN74LV1T34

Hi All,

I have a question about SN74LV1T34.

When the VCC pin is left open and a 3.3V signal is applied to the input, the input voltage back-feeds into the VCC pin, resulting in a voltage of approximately 3.0V.
To prevent this back-flow to the VCC pin, a 47kohm series resistor is placed on the input line.

Is there any issue with installing a 47kohm series resistor on the input?

Best Regards,
Ishiwata

RE: SN74LV1T34: VCC=open, Input=3.3V

Shuji Ishiwata — Thu, 02 Jul 2026 00:29:44 GMT

Hi Josh-san, Jack-san,

The customer is using a 47kΩ resistor at the input as a countermeasure; this limits the current and causes the 2.5V Vcc level to drop to approximately 0.5V.
They would like to confirm whether there are any issues with placing a current-limiting resistor on the input terminal of the device.

Best Regards,
Ishiwata

RE: TPSM63603E: Switch node

Frank De Stasi — Wed, 01 Jul 2026 20:11:55 GMT

Hello

The SW pin should not be connected to anything.

The VLDOIN can be connected to Vout for the 5vout design.

For the 12vout design, you can tie to ground or vout.

Thanks

TPSM63603E: Switch node

Anicia Yu — Wed, 01 Jul 2026 15:30:22 GMT

Part Number: TPSM63603E

Can I leave SW, RBOOT, and CBOOT open if I am not using them?

SN74AVC4T774: Letter of Volatility Request

Claudia R Martinez — Wed, 01 Jul 2026 19:47:35 GMT

Part Number: SN74AVC4T774

Hello,

I would like to request a Letter of Volatility (LOV) for part number SN74AVC4T774 to find out if this part contains volatility or non-volatility memory. I believe part number SN74AVC4T774 is the same part as 74AVC4T774RSVR-NT, right?

If it has volatilie memory:

- Type (e.g. SRAM, DRAM, etc.)

-Size

-User Modifiable (e.g. user, machine, vendor, no)

-Function

-Process to Sanitize or Validate

If it has non-volatile memory:

-Type (e.g. BBRAM, Flash, EEPROM, etc.)

-Size

-User Modifiable (e.g. user, machine, vendor, no)

-Function

-Process to Sanitize or Validate

Thank you for your time in advance.

Claudia R Martinez

Raytheon Technologies

SN74LVC2G34: SN74LVC2G34DCKR Thermal Resistance Data

Claudia Dufour — Wed, 01 Jul 2026 19:21:23 GMT

Part Number: SN74LVC2G34

The SN74LVC2G34 datasheet includes the junction-to-ambient thermal resistance for the DCK package. Are there additional thermal properties available for this package? (thetaJC, thetaJB, psiJB, psiJT, etc.)

CD4051B: Significant device behavioural change masquerading as a non-issue between datasheet revisions

George Tzanatos52 — Tue, 30 Jun 2026 02:05:30 GMT

Part Number: CD4051B

Hi,

We are in the midst of a large production quality spill caused by an un-announced (to us) parameter change in a TI product.

Industry standard practice has been that PCNs announce minor deviations to existing performance levels, not make the updated part incompatible with prior products; that level of change has been treated as an EOL event for the prior part and a new part number for the revised part.

The part in question has been in our allowed manufacturer set (3 vendors) since 2017. The inexplicable change in Vil (details below) is the cause of our quality problem. It has not been detected until recently as our specific drive level still functions as normal in almost all situations, including production test fixtures. In extreme load cases we get a small number of unexpected failures that led to this analysis (Vil<=800mV for the new device, <=4V @ Vcc=15V for earlier product; drive level ~ 950mV normally, failure detected ~1V1).

We are not a military manufacturer and so do not sample validate the datasheet parameters of each device batch prior to loading - I doubt there are (m)any electronic assembly operations that still do this.

We are probably not the only customer you have harmed with this abjectly poor behaviour.

To assist with containing other latent failures, can you please list any other TI devices that went through a similar die shrink and ended up with changes in parameters.

Details:

In 2023, TI updated the long-running CD405xB device from rev. I to J. It looks like a die shrink with significant changes in operation, namely (comparing SCHS0471I to SCHS0471K):

a) Changed Quiescent Idd.
TSSOP - Significantly increased from 5 to 60uA max 25C 5V, typ from 40nA to 17uA).
Note 1. Change actually on p6.
Other packages – Only significantly increased Idd (@20V typ 25C from 80nA to 18uA).
Note 1. Change actually on p11.

b) TSSOP - Increased the typ off channel leakage, x40.
Note 1. Change actually on p7.
Other packages – no change (p12)

c) TSSOP - Increased the max on channel leakage, x2.7.
Note 1. Change actually on p7.
Other packages – no change (p12)

d) TSSOP - Changed the Vil levels from CMOS ratioed to Vcc to fixed <800mV.
Change is on p8.
This is not an 'update', it is a NEW DEVICE;
This alone renders the device incompatible with some contemporaneous driving circuits in long-running production circuitry. IT IS NO LONGER COMPATIBLE with earlier CD4051 or current production OnSemi & ST equivalents.
Other packages – no change (p14)

e) TSSOP - Increased the max input current, x10.
Note 1. Change actually on p8
Other packages – no change (p13)

f) Stated Typ timing change, Inh-out turn off
TSSOP - p9; no change in any max timing values
Other packages – no change in any max timing values (typ, 15V up to 90ns) (p14)

g) Updated ESD ratings
All packages other than TSSOP, no change.
TSSOP - Note 1

h) Updated typical characteristics
Note 1. Change actually on p16; lost 5x channel resistance graphs

Note 1: This is not an 'update', it is a downgrade to a worse process.

Rev L consolidates datasheet double speak by stating that tables were consolidated across packages. THIS MOVES THE SIGNIFICANT DEGRADATION IN rev.J TSSOP PARAMETERS TO ALL DEVICES (a-h above).
This is not a consolidation or an 'update', it is a NEW DEVICE.

TI SHOULD HAVE EOLed CD405x devices in non-TSSOP packages at this point.

RE: CD4051B: Significant device behavioural change masquerading as a non-issue between datasheet revisions

Nir Gilgur — Wed, 01 Jul 2026 18:47:08 GMT

Hello George,

The goal of the new die variant is to update the design while maintaining the same operation capabilities as the old one.
Clearly for this case it was greatly missed, and then mostly fixed with another PCN.

There is no capability to acquire older datasheet revision externally, at least not within ti.com.
Other websites like you mentioned might have it, but only internally we can pull older revisions.

I have checked internally and it seems like the only information about Vil characteristics is what shown in the datasheet.

Since the goal of the die shrink initiative is to update the die while maintaining the same operation characteristics, there should be no changes between the datasheets. The case here is an anomaly.
If there are any changes in specifications, it will be found under the revision section of the datasheet.

It is not feasible from my side to provide such a list.

Right now my recommendation is to operate the devices according to the information available in the current datasheet.
I know this is not ideal and they should be operated same as before, but unfortunately with this device it is not the case.

Another option is to use a voltage translator for the logic pins, but I don't know if it feasible from your side.

Thanks,

Nir

TXS0108E: What happen if we did not provide Pull down on OE line?

Sagar Kumar — Tue, 30 Jun 2026 17:10:11 GMT

Part Number: TXS0108E

Hi

I am using TXS0108ERGYR in one of the board for level translator where VCCA = 1.8V and VCCB = 3.3V.

And OE pin is having Pull up only with 10K on VCCA.

We initiate the powerdown please let me know what will happen on A and B IO pins. Will they drive it low on A and B side?

Thanks

Sagar

RE: TXS0108E: What happen if we did not provide Pull down on OE line?

Sagar Kumar — Wed, 01 Jul 2026 18:33:11 GMT

Hi,

we have following condition as shown in below image-

When we intiate the shutdown in host machine only AUX_3V3 is up while 1.8V and 3.3V got off. But what we observed we are seeing WAKE on B side is 1.3V while VCCB = 0.8V.

As per datasheet when OE pin is GNDED since 1.8V is not available All I/O Pins are in HI-z state so PCIE_WAKE should be on 3.3V but it is on 1.3V. Can you provide the reasoning behind this?

RE: TPSM63603E: Switch node

Anicia Yu — Wed, 01 Jul 2026 18:22:04 GMT

I am using two of these converters to output 5V and 12V. Do I need to use a cap in VLDOIN or can I just tie it to ground?

RE: TPSM63603E: Switch node

Anicia Yu — Wed, 01 Jul 2026 18:15:27 GMT

If I keep Rboot and Cboot do I still leave SW open or is the copper pour connected to GND? This is what the datasheet says:

Switch node. Do not place any external component on this pin or connect to any signal. The amount of copper placed on these pins must be kept to a minimum to prevent issues with noise and EMI.

RE: TPSM63603E: Switch node

Frank De Stasi — Wed, 01 Jul 2026 18:04:36 GMT

Hello

Rboot and Cboot be tied together, as shown in the data sheet.

This connection can be left open, however the switch transition will be slower, giving better EMI but worse efficiency

Thanks

SN74LV8T245: Input voltage tolerance on IO pins

Alexis Monaci — Thu, 25 Jun 2026 08:26:47 GMT

Part Number: SN74LV8T245

Hello dear TI team,

In my application, I am using the SN74LV8T245 to interface a 3V3 FPGA to a 5V bus. I used this IC because it is bidirectionnal and available in VQFN small package.

By default at power on the OE pin is high (chip disabled). On a buffer I saw a failure on a IO and after digging into the datasheet the specifications are confusing me:

The ouput in the high impedance state is absolute maximum 4,6V (no information on recommended operating conditions) and the inputs are specified with 5,5V in recommended operating conditions.
the Ax and Bx pins are bidirectionnal so connected to input and output internal buffer

So when the chip is disabled the Ax and Bx support max 4,6V but when enabled and configured in inputs the Ax and Bx support 5,5V?

If this is the case I assume that there is a kind of internal switch in series with the output buffer to disconnect it and disconnect the output clamping diodes. Can you confirm this?

In datasheet like SN74LVC8T245 the informations in specification tables are very clear on that points.

Thank you in advance!

RE: SN74LV8T245: Input voltage tolerance on IO pins

Joshua Salinas — Wed, 01 Jul 2026 17:28:43 GMT

Hello Alexis,

We need to rewrite this parameter to make it more clear but you can apply 5V to I/Os when Hi-Z is enabled.

The parameter, Ioz, uses VCC = 5.5V when Hi-Z is enabled.

Regards,

Josh

TPLD2001: No simulation in interconnect studio

Clément Letonnelier — Tue, 30 Jun 2026 08:26:25 GMT

Part Number: TPLD2001

Hello,

I wanted to open a TPLD-ICS related ticket but couldn't find it in the TI part number, feel free to put this ticket in the correct area.

We used to run InterConnect Studio from a computer outside of our standard IT setup and everything was fine. However, after getting through the validation process to integrate it to our standard IT setup it seems we are encountering issue.

We don't have the simulation menu under Settings and we are unable to perform a simulation.

We are a big company so IT rules are quite strict, e.g., a software can't write in its own directory or can't interact with the web. We had similar issue at the beginning of CCS Theia for example and following our issue things got fixed on your side.

Could it be possible that we encounter similar issue here? Does the tool require to write in its install directory when running?

Best regards,

Clément

RE: TPLD2001: No simulation in interconnect studio

Clément Letonnelier — Wed, 01 Jul 2026 17:09:12 GMT

Hi Malcolm,

Oh indeed I did not catch that change.

I do use > 1.7.

Thank you

Clément

RE: SN74LV1T34: VCC=open, Input=3.3V

Joshua Salinas — Wed, 01 Jul 2026 15:55:15 GMT

Hello Ishiwata-san,

The issue is not necessary the current but the input voltage when VCC is floating. Adding a current limiting resistor won't improve much.

Regards,

Josh

RE: SN74AVC4T245: SN74AVC4T245PWR unpredictable consumption on sleep mode

Joshua Salinas — Wed, 01 Jul 2026 15:39:59 GMT

Hello Gabriel,

I would agree with the comments from Clemens. If you are not able to bias the inputs to a known logic state (high or low) then TXU product family would be better in this situation.

Regards,

Josh

SN74AVC4T245: SN74AVC4T245PWR unpredictable consumption on sleep mode

Gabriel Cubas — Tue, 30 Jun 2026 18:28:55 GMT

Part Number: SN74AVC4T245

Good afternoon,

We're using a SN74AVC4T245PWR bus transciever for an IoT application in which consumption and battery life are the main concerns. The IC is being used as an interface for UART (STM's LPUART) serial communication between an STM32L452CEU6 (3V5) and a Fibocom L610-GL LTE modem (1V8).

The problem is that we've found out the sleep-mode consumption of our devices (our own product, assembled in a proper factory) is unpredictable. We've noted, so far, 2 'groups' of devices: the first one consumes 200-300 uA while on sleep. The second one consumes, on average, 1 - 1.2 mA on sleep. The Hardware and the Firmware are absolutely identical. There's nothing different between any board.

The firmware was properly checked, and the modem manufacturer was contacted and also found nothing wrong with the hardware design or their product itself. The modem is turned off while the device is on sleep mode, and we've already checked that it is, indeed, off.

After a lot of testing, we decided to remove the SN74AVC4T245PWR IC from one of the highest consuming boards, and it immediately reached the intended consumption (200-300 uA) while on sleep. We re-soldered it and the device went back to high consumption.

Finally, we've used a thermal camera, and we could see that the IC, even on sleep mode, is slightly warmer than the rest of the components.

We're pretty sure that the transciever is the problem, as we've already checked every other component in the board. We've also tried to find an optimal configuration for the pins for sleep mode (STM's STOP2 mode): all of the boards show a lower consumption when the LPUART port is kept initialized. The only information we have about the modem is that both of the UART pins enter HiZ while the device is off.

Is that a behavior that has already been observed? Should we use another IC, designed for extreme low power?

RE: SN74LV1T34: VCC=open, Input=3.3V

Jack Guan — Wed, 01 Jul 2026 14:49:48 GMT

Hi Ishiwata-san,

We will get back to you shortly.

Regards,

Jack

RE: TXS0108E: What happen if we did not provide Pull down on OE line?

Clemens Ladisch — Wed, 01 Jul 2026 09:41:44 GMT

The TXS is a passive switch. Normally, all I/O pins on both sides are pulled up by the internal pull-up resistors. When the device is powered down or disabled with OE, then the internal pull-up resistors are disconnected, and all I/O pins are Hi-Z.

RE: SN74AVC4T245: SN74AVC4T245PWR unpredictable consumption on sleep mode

Clemens Ladisch — Wed, 01 Jul 2026 09:37:56 GMT

This is typical behaviour for a CMOS input that is floating. (Even when the outputs are disabled with /OE, the input buffers are still active.) You can try adding pull-up or -down resistors to all signal lines that can be inactive. (Note that a bidirectional device like the '245 has input buffers on both sides.)

Alternatively, use a unidirectional translator like the TXU0202 or TXU0204, which does not have input buffers at its output pins, and has integrated pull-down resistors at its inputs.

SN74HC74-Q1: Failure in time (FIT) number for SN74HC74QPWRQ1

Nikhil Jose — Wed, 01 Jul 2026 09:27:50 GMT

Part Number: SN74HC74-Q1

Part Number: SN74HC74QPWRQ1

I am in need of the functional safety document specifically the FIT value and the PIN FMA/FMEA for SN74HC74QPWRQ1.

This is a dual channel channel D-Type flip flop, what is the probability of both the Q` (inverted outputs - Q1` and Q2`) failing together.

MSPM0G5187: Clarification on Generating Separate Main and Non-Main DFU Images

Ramanathan S — Wed, 01 Jul 2026 09:24:05 GMT

Part Number: MSPM0G5187

The DFU programming flow has explained in e2e support. I now understand the required programming sequence and why the Non-Main image must be programmed first.

I have a few questions regarding the image generation process.

Currently, I am using the command you previously shared to convert .out file into a .txt file for the DFU Host Utility in tiarmhex.exe. However, I am not sure how this conversion process determines the programming addresses. It appears to generate the image starting from address 0x00000000 by default, and I do not know how to modify or control the flash address during the .out to .txt conversion.

Could you please guide me through the complete process?

How can I separate the Main and Non-Main images at the project/code level?
How can I generate separate main.out and nonmain.out files?
Once I have the separate .out files, what is the correct procedure to convert each of them into main.txt and nonmain.txt for the DFU Host Utility?
How can I specify or change the programming (flash) address during the .out to .txt conversion? Is there any command-line option or configuration that controls the address included in the generated .txt file?

If there is any reference project, application note, or example demonstrating the generation of separate Main and Non-Main DFU images, please share it. That would help me understand the expected workflow.