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

Joshua Salinas — Thu, 02 Jul 2026 22:18:15 GMT

Hello Ishiwata-san,

It seems like adding a series resistor helped but my next concern would be when VCC is active and a signal is driven to the input. If you provide a 3.3V input signal, the part won't detect it. VIH at VCC=3.3V is 1.39V

Regards,

Josh

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?

Jack Guan — Thu, 02 Jul 2026 22:11:16 GMT

Hi Sagar,

Can you provide a scopeshot of the OE signal, VCCA, VCCB, and PCIE_WAKE state on the same capture during this time? Are there any external pulldowns not realized in the block diagram?

Regards,

Jack

CD74AC14: CD74AC14M96 updates in datasheet (June 2026)

Erika Alejandre — Thu, 02 Jul 2026 21:35:19 GMT

Part Number: CD74AC14

Hi, I hope you are well. :)

I would like to know what are the correct values that changed from CD74AC14M96 Datasheet (August 2024) to CD74AC14M96 Datasheet (June 2026), because in the picture that I added below (omit yellow part) the values that I circuled in blue are not align with the updates that we have in both datasheets.

RE: SN74AVC4T774: Letter of Volatility Request

Joshua Salinas — Thu, 02 Jul 2026 21:19:32 GMT

Hello Claudia,

These parts do not contain any volatile or non-volatile memory. Thanks!

Regards,

Josh

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

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: SN74AVC4T245: SN74AVC4T245PWR unpredictable consumption on sleep mode

Joshua Salinas — Thu, 02 Jul 2026 19:50:43 GMT

Hello Gabriel,

Based on your schematic, 1DIR and 2DIR are fixed to either VCC or GND. This means only your inputs 1A1, 1A2, 2B1 and 2B2 need to be biased.

Regards,

Josh

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 — Thu, 02 Jul 2026 19:30:49 GMT

Hello Alexis,

Yes, that was the parameter I was referring to in my previous comment.

From other level translator datasheets, this parameter always equals VCC max voltage.

Regards,

Josh

RE: SN74AVC4T774: Letter of Volatility Request

Jack Guan — Thu, 02 Jul 2026 17:31:48 GMT

Hi Claudia,

We will provide a response to this question shortly.

Regards,

Jack

RE: SN74AVC4T245: SN74AVC4T245PWR unpredictable consumption on sleep mode

Gabriel Cubas — Thu, 02 Jul 2026 17:29:53 GMT

Thank you so much, Clemens. Just to make sure, is this the way to go?

Regards,
Gabriel

RE: SN74AVC4T245: SN74AVC4T245PWR unpredictable consumption on sleep mode

Clemens Ladisch — Thu, 02 Jul 2026 16:22:45 GMT

You must pin all eight I/Os on both sides.

RE: SN74AXC4T774: SN74AXC4T774 /OE pin is tied to GND directly

Clemens Ladisch — Thu, 02 Jul 2026 16:21:21 GMT

The /OE input is not a data I/O.

The datasheet says:

To put the level shifter I/Os in the high-impedance state during power up or power down, tie the /OE pin to V_CCA through a pullup resistor.

If you do not care about the state of the I/Os during power up or power down, then you can tie /OE directly to GND.

SN74AXC4T774: SN74AXC4T774 /OE pin is tied to GND directly

TT_Chin — Thu, 02 Jul 2026 09:15:00 GMT

Part Number: SN74AXC4T774

Hi,

I would like to know whether I can tie /OE signal of SN74AXC4T774 to GND directly ?

I saw the datasheet mentioned that SN74AXC4T774 has 71K ohm integrated weak pull-downs on all data I/Os.

It seems to me that it should not be an issue even though /OE is tied to GND before VCCA/B are stable, does it make sense?

SN74HC42: sn74hc42 problem

Alessandro Farinella — Thu, 02 Jul 2026 07:39:16 GMT

Part Number: SN74HC42

I'm Massimo Gazzato of GELSE SRL from Italy

We purchased 5000 pz SN74HC42DR pin in MAY ( your invoice 5853010352) and found that pins aren't metalized.

Also the TEXAS SIMBOL that identifies the state of TEXAS is different.

I wanted to make it's fine.

I wait your answer

Best regards

Massimo Gazzato

RE: SN74HC42: sn74hc42 problem

Nikki Dengel — Thu, 02 Jul 2026 15:31:04 GMT

Hi Massimo,

I do not see cause for concern.

The appearance of the pins is due to 'roughened lead frame' which is intentional because it provides better solder adhesion. [FAQ] Why do the leadframes look strongly oxidized or corroded?

The difference in logo is normal.

Regards,

Nikki

RE: SN74AHCT1G126: OE pin tied to VCC

Chris Pui — Thu, 02 Jul 2026 15:09:46 GMT

Hi Gabriele,

If OE is tied to VCC, the buffer will be active at all times and pass any signals that arrive on the A input. During startup, it may be the case that whatever SPI controller you are using will drive some signals to the chip select as it powers on. These signals will be passed through the buffer if OE is always high.

If this is not an issue, then there should be no problem with setting OE to VCC.

Best,

Chris Pui

SN74AHCT1G126: OE pin tied to VCC

Gabriele Pellegrinelli — Thu, 02 Jul 2026 06:03:07 GMT

Part Number: SN74AHCT1G126

Hello.

I'll use the buffer component SN74AHCT1G126 as a voltage translator from 3.3V to 5V in my application. The signal applied to the buffer is a SPI chip select.

I would like to tied OE to VCC (5V), because I don't want to use a dedicated uC pin for this signal.

In the datasheet I read "To ensure the high-impedance state during power up or power down, OE should be tied to GND through a pulldown resistor", so I don't know the behavior at power up/down if the OE tied to VCC.

Thanks.

Gabriele.

RE: SN74AVC4T245: SN74AVC4T245PWR unpredictable consumption on sleep mode

Gabriel Cubas — Thu, 02 Jul 2026 12:39:45 GMT

Thank you so much for your help, Joshua. I'm trying to work with the transciever that's already designated for the project. If I can't get the consumption to lower to a safe level, I'll be exploring the TXU products.

Regards,
Gabriel

RE: SN74AVC4T245: SN74AVC4T245PWR unpredictable consumption on sleep mode

Gabriel Cubas — Thu, 02 Jul 2026 12:38:09 GMT

Good morning, Clemens.

Thank you so much for your reply. It was very helpful and elucidative. I pinned both UART TX and RX and the Airplane mode pin, wich is also interfaced by the bus transciever, with pull-up and pull-down resistors (by firmware, on the STM side - The modem side is still floating). The consumption dropped from 1,2 mA to 550 uA, wich is a great improvement. I have two more questions about the typical application:

1) Should I pin both sides of the transciever with pull up/down resistors, or pinning only one side is enough?
2) There is a 4th line that's not being used (NC). Should I also pin it?

RE: SN74LV8T245: Input voltage tolerance on IO pins

Alexis Monaci — Thu, 02 Jul 2026 07:21:49 GMT

Hello Joshua,

OK thank you it is good news! To be complete, do you also need to change this parameter in the specification table? And if the IO in Hi-Z are 5.5V tolerant, what is the absolute maximum in this case?

Best regards

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

Pengfei Xie — Thu, 02 Jul 2026 06:37:21 GMT

Hi Ramanathan,

For default .out output format, it is a format that already includes address information inside, so the NONMAIN content will be included for corresponding address region (start from 0x41c00000) in .out file. And it is not feasible to directly divide nonmain and main content based on .out format.

For .txt format, you could refer the 3.5.1.5 Generate Hex Files of MSPM0 MCUs Development Guide (Rev. G) and select TI_TXT format as output format. If your project has include NONMAIN configuration, then you will see 0x41c00000 and 0x41c00100 content included in generated .txt output file, and it is nonmain content. You could manually divide this txt file into main.txt part and nonmain.txt part. TI-TXT is a simple understanding format, the binary content is just start with a @addresss and following the bytes after the address, and a "q" is required at the end of .txt file.

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.