TeensyLC Fried by 5V Tx/Rx from Serial communication with UNO??

Status
Not open for further replies.

SaturnV

Member
I've been agonizing over this for two nights and can't get an UNO to talk via Serial Communication with a TeensyLC. I just realized the UNO had probably been sending over with a 5V signal Tx-->Rx TeensyLC. I can not get this to work -- and now I get my error. Did I fry the darn TeensyLC? The Teensy will load and run a previous program driving an Alphanumeric display, reading i2c bus with a RTC etc. Can it take a 5V signal without permanent damage?

Frustrating indeed. I can get both the UNO and the LC to transmit a simple counting variable but neither side will read incoming serial data. I checked connections and the ground is mutually connecting these boards. Is it because of this voltage disparity?

Thanks.
 
Hard to say, yes the +5v from UNO can cause damage to the LC which is not 5v tolerant. Did you damage it? I don't know.

However sometimes hard to know what is going on, without seeing additional information, like how do you have the two boards connected?

What code are you running on both boards?

I am assuming you are using pins 0, 1 on the UNO, Which pins did you use on the LC? 0, 1 ?

If so I assume you connected 0->1 and 1->0 ?
Did you connect up a common GND between the two boards?


On Uno I assume you are talking the the Serial object? As there is only one Serial object and it shares the USB.

On LC I assume if you are using pins 0 and 1, that you are talking to the Serial1 object?

Testing of the LC. Probably the first thing I would do would be to try running a simple sketch like: the
File->Examples->Teensy->Serial->EchoBoth:

Code:
// set this to the hardware serial port you wish to use
#define HWSERIAL Serial1

void setup() {
	Serial.begin(9600);
	HWSERIAL.begin(38400);
}

void loop() {
        int incomingByte;
        
	if (Serial.available() > 0) {
		incomingByte = Serial.read();
		Serial.print("USB received: ");
		Serial.println(incomingByte, DEC);
		HWSERIAL.print("USB received:");
		HWSERIAL.println(incomingByte, DEC);
	}
	if (HWSERIAL.available() > 0) {
		incomingByte = HWSERIAL.read();
		Serial.print("UART received: ");
		Serial.println(incomingByte, DEC);
		HWSERIAL.print("UART received:");
		HWSERIAL.println(incomingByte, DEC);
	}
}

I would then use a jumper wire and connect pin 0 to pin 1 on the LC, and run this program.
In the SerialMonitor, I would type in some text and see if it echoes back.

If it does, this says that it would out Serial1 TX pin and was received back on the RX pin, which is a good sign.

Can you get away with direct connecting the TX pin of the UNO (Pin 1) to the RX pin of LC? I am not really sure, but probably a good idea.

I know some have done things like this by putting in a current limiting resistor to maybe help some. Others have used a couple of resisters as a resister divider to drop the voltage down to the LC.Other times use a TTL level converter... (or simply use a T3.2 which is +5v tolerant).

Good Luck
 
I was connected as you suggest-- Uno to LC. I ran a jumper from 0 to 1 on LC. Ran example program, EchoBoth. When I type, "Hello" in the serial monitor, I get reams of: "UART received: 101" for pages and pages ad infinitum. What does that tell me? I tried, "tree" and now I get same, UART received and a random numbers come up. After awhile get stuck at, "85" and just sit there.
 
I was connected as you suggest-- Uno to LC. I ran a jumper from 0 to 1 on LC. Ran example program, EchoBoth. When I type, "Hello" in the serial monitor, I get reams of: "UART received: 101" for pages and pages ad infinitum. What does that tell me? I tried, "tree" and now I get same, UART received and a random numbers come up. After awhile get stuck at, "85" and just sit there.

Try the same test on the T_LC's Serial2 with pins #9 and #10 connected, and Serial1 replaced with Serial2 throughout. If only Serial1 pins are a affected those may return as expected:

Perhaps replace this line in both :: Serial.println(incomingByte, DEC);
with this to show the actual chars for human readability:
Code:
Serial.print(incomingByte, DEC);
Serial.print(" :: ");
Serial.println((char)incomingByte);
 
Ran example program, EchoBoth. When I type, "Hello" in the serial monitor, I get reams of: "UART received: 101" for pages and pages ad infinitum. What does that tell me?

I ran the same test just now on a known-good Teensy LC. It does exactly the same thing. So that (probably) means your Teensy LC is working.

If you do that test but uncheck Autoscroll before typing Hello, it prints this:

sc.png

Just in case the reason is unclear, when you run this test each single byte the serial port receives causes the program to print many bytes to both the serial port and USB port. With the serial port jumpered together, those many bytes each cause many more until the serial transmit and receive buffers are full and then the process keeps repeating as an infinite loop, unable to receive most bytes until it finally ends up just infinitely printing just 101.
 
Paul,

Does it make sense that putting a 5V signal out via Tx/Rx to an LC that nothing would show on LC receiving side using serial monitor? Likewise sending a 3V from LC to UNO? How would LC deal with a 5V High/Low signal? I thought I might see something -- though garbled and then a failure if it burnt the chip.

Thanks.
 
Never connect a 5V transmit pin from Uno to Teensy LC. It could damage your Teensy LC. If it doesn't destroy the hardware, it could cause things to not work in ways that are difficult to predict. I can not answer questions about whether specific things you observed while making this wrong connection are the expected behavior. I can only tell you this should never be done, and if you do so, there is a very real risk it can damage your hardware.

You must reduce Uno's transmit signal to 3.3V, before connecting to Teensy LC. A pair of resistors can be used. 2.2K and 3.3K will work. Search for "resistor divider" if you're unsure. Or show us photos of how you've connected the resistors & wires if you want confirmation here (many people on this forum are very familiar with this circuit). I recommend testing with a voltmeter before you connect to any pin on Teensy LC. Run the LED blink example with long delays and use of pin 1, so you can see voltage change on your voltmeter's display.

Uno should be able to properly receive Teensy LC's 3.3V output. The AVR chip on Uno has TTL level thresholds, so it is supposed to recognize anything over 2V as logic high, and anything under 0.8V as logic low.
 
I was after your opinion on the logic being parlayed by 5V from UNO to the LC. The accident already happened, I'm not intending to continue it. Really it would have been only the Rx pin on LC that would have been subject to potential damage by the 5V signal. I like the divided resistor option -- that could keep my project alive.

I'm working through the blocking problem that comes with using an IR remote while driving a strip of Neopixels WS2812s. I've read Marc Merlin (He had the pinout illustration card in his video for an LC)-- I know T3.2 could do the trick yet I have an LC and I thought it might handle the IR and drive LEDs but I didn't succeed-- it blocks despite instating interrupts for a brief time as he did. I decided to break the IR detection part off to another uC and have it report button presses to the LC. I really didn't find a heck of a lot on my searches as to if the LC was powerful enough to handle IR+Neo in one chip. Any idea if others who use the two uC mode -- go with i2c or Serial? Didn't find much on that either.
 
actually, even an input pin of a 5V circuit or controller can bleed enough voltage to fry a 3.3V output. So it is always good practice to either use overvoltage suppressors and in-line resistors or level-changer ICs. These things are often disregarded by Arduino-makers and lead to unexpected failure of the inventions later on.
 
If you use the non-blocking WS2812Serial library for the Neopixels, then you can receive IR remote signals on the same Teensy LC using the IRRemote library.

Marc's article says:

It's hard (or near impossible on some chips) to actively update neopixel strips for animations and listen for IR commands at the same time.

This is advice applies to boards like Uno which lack non-blocking libs for the LEDs.

Doing these together is very easy on Teensy, if you use either WS2812Serial or OctoWS2811 for the LEDs.

Just do not use blocking libs like Adafruit_NeoPixel. That library never plays nice with IRRemote. It even tends to mess up receiving serial data, unless you use slow baud rates.
 
In the case of using the non-blocking WS2812 Serial library for the Neopixels -- I would be using the Tx pin on the LC. So much for using pin#17 then? I assume Tx is 3V -- as long as my neopixels follow this:
"Most of WS2812 LEDs made before 2014 or after 2015 can use 3.3V signals, which Teensy LC and 3.x output. But a buffer chip to boost the signal to 5 volts is still the best practice." -- I am under 150 neopixels with my project.

Any way this all could work with FASTLED ala Merlin using the LC? Did he modify the FASTLED library or just add that line, "sei(); delayMicroseconds(WAIT_TIME); cli();" in the body of his code? I'm unclear -- as I added that line in my project and it did nothing and blocked anyway.
 
I have used the Sparkfun bi-directional logic level shifter to go from an UNO to a Teensy.
They only cost $3.00 so I think it is worth the investment in a stock of them.
I have used it for interrupt pins (so low-latency use cases) and it appears to work exactly as expected.

Here is the link:
https://www.sparkfun.com/products/12009

You need to solder pins, but that is not a major issue.
 
Yes, those level shifters are nice indeed. Thanks for the recommendation. An update: the non-blocking WS2812Serial library as recommended by Paul worked nicely. I ended up frying my LC because there was a short across my common and +5V rails. I had to resort to a Teensy 3.2 I had in stock. The library does help a lot but it still makes for a dodgy IR reception. Every 3rd or 4th press is garbled.

Is the use of a dual uC reporting to the Teensy via i2c or serial really crisp? Anybody have a comment on trying that?

Happy New Year everyone!
 
Status
Not open for further replies.
Back
Top