Logic Level Conversion using TXS0108E

Status
Not open for further replies.

JimKazmer

Well-known member
I've read the many other (Teensy) threads about Logic Level Conversion (and looked at many of the products referenced). I need bi-directional Logic Level Conversion from/to the Teensy 4.0 SPI ports; I am driving the SPI MOSI port both directions (data rate is ~20 MHz), interfacing with an external 5V device.

I have "successfully" used the TXS0108E (https://www.ti.com/lit/ds/symlink/txs0108e.pdf); the word "successfully" is in quotes since one completed system works flawlessly, and the other one is "glitchy". I am trying to understand the underlying issue and believe it to be related to TXS0108E. The datasheet indicates:
• Maximum data rates
– 110 Mbps (push pull)
– 1.2 Mbps (open drain)

There are some things I am trying to figure out:
(1) How do I determine whether my SPI MOSI pins are "push pull" or "open drain"? I'd like to assume they are, by default, "push pull" in order to support SPI high data rates, but I don't know.
(2) To keep my wiring simple, I've tied the OE of the TXS0108E to 3.3V using a 1k ohm resistor. This "violates" the suggestion from the datasheet "To ensure the Hi-Z state during power-up or powerdown periods, tie OE to GND through a pull-down resistor." Is this something I should worry about?
(3) Regarding #2 above, should I be using one of the Teensy's digital I/O pins to enable the chip somewhere in my setup? Do the Teesny's pins default to GND during the poweron sequence?
(4) Are there reasons I should not use this chip? The features on the cover sheet make it seem like the ideal logic level converter; I just wish there was a smaller 4-channel offering since I don't need all 8 channels.
(5) I am making the SPI MOSI pin the master some of the time, acting as the slave some of the time, and inactive the reset of the time. How do these chips, like the TXS0108E, know which side is trying to drive the line and decide when to drive the other side? The answer may indicate what should I be doing with the SPI MOSI line to help this dynamic switching.

Thanks, Jim
 
From one of the documents referenced in the "support resources" section of the TXS0108E data sheet, I found the answer to #2 and #3: "If the application does not require output enable control then the OE pin should be tied to the VCCA supply."
 
Hi Jim,
(1) SPI always uses push-pull pins.
(4) I don't see a problem, the chip can be used for SPI, see this product.
(5) the chip is bi-directional, it just "voltage-translates" signals from one side to the other, without having to know the direction. See this blockdiagram:

Capture.PNG

Regards,
Paul
 
(4) Are there reasons I should not use this chip? The features on the cover sheet make it seem like the ideal logic level converter; I just wish there was a smaller 4-channel offering since I don't need all 8 channels.
There are 4 channel and two channel versions look for TSX0104 and TSX0102.
 
PaulS and BriComp, Thank you for the replies. I haven't overcome my skill/fear of soldering those surface mount parts, so I like the product that PaulS recommended. I haven't found a similar version for the the TXS0104, but that would be the perfect solution for my current project.
The data rates of the TSX0104E are different... (there may be a different version, still reading data sheets)..
Max Data Rates
– 24 Mbps (Push Pull) <-- much lower, and very close to my usage.
– 2 Mbps (Open Drain) <-- a bit higher
 
I've used this logic level shifter in the past. I've used it for I2C shifting and WS2812B/neopixel shifting. Unfortunately, there is no data sheet:
I believe I've used it without the 10k pull-ups and it was fast enough for the WS2812B switching. Mostly I used it with the 10k pull-ups mentioned.

However recently, I've switched WS2812B/neopixel shifting to use the single direction shifting chip SN74AHC1G125DBVR (1 pin shifted, SMT soldering) or SN74AHC125N (4 pins shifted, through hole soldering).
 
@MichaelM, I think you mean the SN74AHCT125N part, isn't it? The one with TTL level input [VIH = 2V].
The non-T part has an VIH of 3.85V at 5.5V VDD.

Regards,
Paul
 
Hi, just FYI I am using the TXS0108 just now for a couple of projects and I have posted one question that can enter in the category of "Are there reasons I should not use this chip?" if ESD is an issue for your project.

The TXS just works nicely for SPI in my experience although I'm not using it a very high frequencies for that.

Best regards.
 
...and the other one is "glitchy".

I discovered the source of my "glitchy" behavior... it had nothing to do with the SPI signal, nor the TXS0108E. The issue was a bad connection in the wiring from the RC-receiver SBUS into the teensy UART. Once I made that solid, the system behaved as desired.

Still a useful discussion for me. I have ordered some of the TXB0104 parts referenced above and look forward to further reducing the footprint.

Jim
 
Another follow-on question...

ordered some of the TXB0104 parts

Well, I received my parts and tried them out... they work fine for the SPI, but they do not work for the Serial connection (RX2). The TXS0108E worked for both the SPI and the Serial connection.

The Adafruit website had this disclaimer in their description:
Only thing that doesn't work well with this chip is i2c (because it uses strong pullups which confuse auto-direction sensor) or control lines with a lot of capacitance on them. If you need to use pullups, you can but they should be at least 50K ohm - the ones internal to AVRs/Arduino are about 100K ohm so those are OK!

I skimmed the library documentation, but didn't see anything about making the serial pin use INPUT_PULLUP. Does anyone know if this is possible?
 
I did try that... didn't make a difference. I was thinking the Serial library forces it to be INPUT (unless something else is done).
 
I did try that... didn't make a difference. I was thinking the Serial library forces it to be INPUT (unless something else is done).

If you read the data sheet it does NOT state that pull up resistors are required, but if they are present they should be at least 50k due to the low output drive of the tsdx0104. Ie the device does not have sufficient power to drive inputs with pullups of less than 50k due to the power required. For instance it would NOT be be able to pull down a 10k pull up. If NO pullups are present on the i/p of the device being driven then that is the ideal situation.

What are you doing with the OE pin? Apparently it should be held low until both power voltages are present.
 
In this case, the device being driven by the 3.3V side-A is the Teensy 4.0 Pin 7 (UART/Serial RX2 input); the 5V side-B driving device is a RC receiver. I don't have access to that RC-receiver's technical specs to see how they are driving the line; but as (I think) you are describing, the driving side isn't the issue.

Adafruit indicates they've added "a 10K pull-up resistor on the output enable pin so you can use it right out of the box". I did try adding my own OE signal to ensure it was being enabled... I am using SPI and SPI1 with this TXB0104, each SPI is driving the MOSI line bidirectionally at ~20Mhz, and those are working fine. The 100,000 baud serial line is not working with the TXB0104.
 
Digging into the Hardware Serial code: there is a place were the PIN is configured, from "HardwareSerial.h":
Code:
	typedef struct {
		const uint8_t 		pin;		// The pin number
		const uint32_t 		mux_val;	// Value to set for mux;
		volatile uint32_t	*select_input_register; // Which register controls the selection
		const uint32_t		select_val;	// Value for that selection
	} pin_info_t;

And then in HardwareSerial.cpp the pin_info for RX2 (UART4) is defined with:
Code:
{7,2, &IOMUXC_LPUART4_RX_SELECT_INPUT, 2},

The above definition and HardwareSerial code sets Pin 7 as "Selecting Pad: GPIO_B1_01 for Mode: ALT2" as described by page 856 of the https://www.pjrc.com/teensy/IMXRT1060RM_rev2.pdf:
Page-856.png

Then on page 722, you can see these options for setting the behavior of that pin:
Page-722.jpg

As you can see, the physical behavior can be set in many different ways (22K, 47K, 100K pull-ups or a 100K pull-down).
Some questions...
(1) What does "Mode: ALT2" refer to? I searched for an explanation in that document, but didn't find it (I think the word "mode" is used more than 6,600 times, and "ALT2" more than 500 times.)
(2) I am thinking of redefining this register to change the behavior... what should I set it to? I would guess the 100K pull-up.

Next up, after dinner, I will search for how it is set be the current libraries. Will add what I find.

The thumb nail shown below was page 761, which was one of the other pin options available via the configuration... I have no idea how to remove it.
 

Attachments

  • Page-761.jpg
    Page-761.jpg
    103.7 KB · Views: 50
From avr_emulation.h:#define CONFIG_PULLUP ( IOMUXC_PAD_DSE(7) | IOMUXC_PAD_PKE | IOMUXC_PAD_PUE | IOMUXC_PAD_PUS(3) | IOMUXC_PAD_HYS )

IOMUXC_PAD_PUS(3) = 11 PUS_3_22K_Ohm_Pull_Up — 22K Ohm Pull Up

So for this to work, it looks like I need to change this.
 
I tried several settings, like:
CORE_PIN7_PADCONFIG = ( IOMUXC_PAD_DSE(7) | IOMUXC_PAD_PKE | IOMUXC_PAD_PUE | IOMUXC_PAD_PUS(2) | IOMUXC_PAD_HYS );
and later
CORE_PIN7_PADCONFIG = ( IOMUXC_PAD_DSE(7) | IOMUXC_PAD_PKE | IOMUXC_PAD_PUE | IOMUXC_PAD_PUS(0) | IOMUXC_PAD_HYS );

Neither made a difference with the TXB0104; both these settings worked with the TXS0108E. The two SPI channels worked fine, but the UART never did.
 
What does "Mode: ALT2" mean?
This refers to the "hardwired" options available for the pin to connect it to a peripheral. By "hardwired", the processor only allows a certain level of configurability (not every peripheral can be wired to every pin). For example:
000 ALT0 — Select mux mode: ALT0 mux port: FLEXCAN2_RX of instance: flexcan2
001 ALT1 — Select mux mode: ALT1 mux port: XBAR1_INOUT17 of instance: xbar1
010 ALT2 — Select mux mode: ALT2 mux port: LPUART6_RX of instance: lpuart6
011 ALT3 — Select mux mode: ALT3 mux port: USB_OTG1_OC of instance: usb
100 ALT4 — Select mux mode: ALT4 mux port: FLEXPWM1_PWMX01 of instance: flexpwm1
101 ALT5 — Select mux mode: ALT5 mux port: GPIO1_IO03 of instance: gpio1
110 ALT6 — Select mux mode: ALT6 mux port: REF_CLK_24M of instance: anatop
111 ALT7 — Select mux mode: ALT7 mux port: LPSPI3_PCS0 of instance: lpspi3
 
I tried several settings, like:
CORE_PIN7_PADCONFIG = ( IOMUXC_PAD_DSE(7) | IOMUXC_PAD_PKE | IOMUXC_PAD_PUE | IOMUXC_PAD_PUS(2) | IOMUXC_PAD_HYS );
and later
CORE_PIN7_PADCONFIG = ( IOMUXC_PAD_DSE(7) | IOMUXC_PAD_PKE | IOMUXC_PAD_PUE | IOMUXC_PAD_PUS(0) | IOMUXC_PAD_HYS );

Neither made a difference with the TXB0104; both these settings worked with the TXS0108E. The two SPI channels worked fine, but the UART never did.
I think you need to use a TSX0104 part not a TSB0104.
 
I think you need to use a TSX0104 part not a TSB0104.

Bummer, I bought a bunch of them... The one breadboard version of TSX0104 I found was 3x the price of adafruit and sparkfun. Reading through the spec sheets, I cannot see anything that should stop this from working with a UART.
 
I've been looking at this problem all afternoon. I will need to do uart 3.3v to 5v and back. I had purchased some TXB1040 and obviously they will not work.
I have just found this LSF010x.
Seems like it might fit the bill for me. Unfortunately for you (JimKazner) it is only available in x1, x2 and x8.
The LSF0102 which I require does not seem to be available from Ti but I found some in China. Time will tell whether they will be any good or not.
I ordered 20 each of the chip and SSOP8 TO DIP adaptors from AliExpress. All for < £15 inc tax (VAT @ 20% in the UK).
If they work it will be a good deal.
 
Bummer, I bought a bunch of them... The one breadboard version of TSX0104 I found was 3x the price of adafruit and sparkfun. Reading through the spec sheets, I cannot see anything that should stop this from working with a UART.

I agree, but you said that the TSX0108E worked and the TSB0104 does not.
The LSF010x mentioned above looks good to me. But then I went and bought a TSB0104, so what do I know!!
 
I just found some more info which has led me to an idea for you.
I will get back to it tomorrow.
 
Status
Not open for further replies.
Back
Top