Issue when connecting two teensy 3.6 via serial pins

Status
Not open for further replies.

lhak

New member
Hello,

In my project I need to connect two teensy 3.6 boards via serial connection (currently using serial2) to transfer data. I have connected GND and the TX, RX pins and data transfer is working fine even at high speeds. However, only the board will start automatically that is connected first to USB (directly to PC or via a hub). The board that is connected later on will not start until I press the button on it (I toggle the onboard LED as the first instruction in the setup() function to confirm this). It works fine if I either remove the RX pin cable on the second board or remove the Serial2.begin() from the program on the first board. I have also tried using serial1 or serial3 but the issue remains.

Any idea on what I am doing wrong?
 
Odd that pushing the button results in it running as that button by design takes the Teensy 'offline' to programming mode?

Is the TeensyLoader active when the button is pushed and perhaps uploading code and restarting the 2nd Teensy? Is anything else connected to or between the T_3.6's?

What version of TeensyDuino is in use? There was a recent change to the power up sequence that affected T_3.6 from certain power supplies.

This isn't something I've seen in working with the T_3.6's - and I expect I've done this as I had Beta units for test before release and have done a lot with them since. I am beta testing something new and I have seen this problem.

Does this problem reproduce with a simple blink sketch on both Teensys? Or only when they actively open the Serial# port to communicate over UART?

I clipped this code from something I have on github - what happens if you put this on both T-3.6's - properly connect GND and Tx and Rx see how they work [ anything from USB Serial should echo out Serial1 and also the opposite ] and then try powering up one and then the other.

Code:
/* UART Example, any character received on either the real
   serial port, or USB serial (or emulated serial to the
   Arduino Serial Monitor when using non-serial USB types)
   is printed as a message to both ports.

   This example code is in the public domain.
*/

// set this to the hardware serial port you wish to use
#define HWSERIAL Serial1
#define HWSERIALBAUD 1843200 // 921600 // 115200

void setup() {
  Serial.begin(9600);
  HWSERIAL.begin(HWSERIALBAUD);
  pinMode(LED_BUILTIN, OUTPUT);
  digitalWrite( LED_BUILTIN, HIGH );
  while ( !Serial && millis() < 2000 );
  Serial.println("\n" __FILE__ " " __DATE__ " " __TIME__);
  Serial.printf(" PORT Serial1 and BAUD=%d \n", HWSERIALBAUD );
  HWSERIAL.println("\n" __FILE__ " " __DATE__ " " __TIME__);
}

char buff[200];
void loop() {
  char incomingByte;

  if (Serial.available() > 0) {
    digitalWriteFast( LED_BUILTIN, !digitalReadFast( LED_BUILTIN) );
    while (Serial.available() > 0) {
      incomingByte = Serial.read();
      HWSERIAL.print(incomingByte);
    }
  }
  if (HWSERIAL.available() > 0) {
    int ii = HWSERIAL.available();
    digitalWriteFast( LED_BUILTIN, !digitalReadFast( LED_BUILTIN) );
    while (HWSERIAL.available() > 0) {
      HWSERIAL.readBytes( buff, ii );
      buff[ii]=0;
      Serial.print(buff);
    }
  }
}

*/
 
Any idea on what I am doing wrong?

Nope, no idea. If you give us the code for both sides (or perhaps smaller, simpler code which is just enough to demonstrate the problem) and show us a photo or clear diagram of the connections, maybe we'll see what's wrong? Or with that kind of info, it'd be possible to give it a try and dig into the issue.
 
I have updated to the latest version from the website (1.46), but this did not change anything.

If I use the code posted above and switch to serial2, most of the time the second teensy starts successfully but sometimes it does not. It will only start again if I disconnect the first teensy (both are directly connected to a laptop, but I also tried a powered usb hub or usb power supply before) or disconnect the serial pins. I could not reproduce the issue when using serial1. Switching my application to serial1 works as long as only the RX, TX and GND pins are connected. However, I also need a trigger signal and if I connect pin 4 to each other, I see the same issue where the teensy receiving the trigger signal will not start. I also tried a different pair of teensys (fortunately, I have a few of them) and see the same issue.
 
When the trigger signal pin4 is attached - is it set as INPUT or OUTPUT and if OUTPUT is it set HIGH or LOW? Assuming it goes one way as input on one end and output on the other?

Does "second teensy starts successfully but sometimes it does not" mean the LED never comes on from the write(HIGH) in setup() when it does not start?

So 'second' Teensy is always the one to fail if started after the 'first' T_3.6 - but that 'first' T_3.6 always comes up even if started after the 'second'?

That program is what I use as a debug echo on a Teensy - and I had a T_3.6 connected with at least one Serial UART to another device that has to be on before the T_3.6 and I never saw the T_3.6 fail to start.
 
Can you be more specific, to say exactly what you are observing. Most of your words are what you believe id happening ("second teensy starts successfully but sometimes it does not"), but you are not saying what specific behavior you are observing on your screen or the LEDs or other visual cues you actually see. We can not see your screen. We can not see your desk with the actual hardware wired up. You're basically saying "it doesn't work" and giving us no visibility into what's actually happening. There may indeed be a problem, but can you understand how this lack of details makes helping you almost impossible?

If I try to reproduce this here, do I run Defragster's code from msg #2, with "Serial1" changed to "Serial2"? Do I run that *exact* code on both boards? That seems kind of pointless, since each side will try to send more to the other in a never-ending loop, because that program prints a lengthy message for each incoming byte.

Imagine I will actually connect 2 boards together here and try the code. But also imagine I will make only 1 attempt. If you show a photo or clear diagram of how you have actually connected the wires, if you give the *EXACT* code to run on each board, if you say very clearly what you actually observe (like screenshots), not merely your interpretation but the actual observed behavior, odds are much higher I will manage to reproduce the same problem.
 

That seems kind of pointless, since each side will try to send more to the other in a never-ending loop, because that program prints a lengthy message for each incoming byte.

I don't think it does that - No never ending loop?
> anything IN USB#1 or USB#2 of the devices #1 or #2 goes out its HWSERIAL to the other Teensy: HWSERIAL.print(incomingByte);
> Anything IN on either HWSERIAL goes to its USB Serial: Serial.print(buff);
 
Sorry, I hope this description is a bit more helpful:

I have loaded the the code as posted by defragster to both boards with the only change being that HWSERIAL is changed from Serial1 to Serial2. The GND pins of both boards (the one next to the USB connector on the teensy) are connected and pin RX2 on the first teensy is connected to TX2 on the second teensy and vice versa. Now the first teensy is connected via a USB->micro USB cable to the PC. I see that the LED turns on and the windows 10 device manager shows the teensy as a COM port. Now I connect the second teensy to a different USB port of the PC. In most cases the LED will also turn on and the COM port will appear in the windows device manager. I can also open the console on the PC and if I send a command to one of the teensys, it will show up in the opened console to the other teensy. Now, sometimes (takes a few tries) when I plug in the USB connection of the second teensy, its LED will not turn on and its COM port will not show up in the windows device manager. I can then plug it out from USB and plug it in again as often as I want and I see the same behavior (No LED and no COM port). The way to see its LED turning on again (and the COM port showing up) is to either remove the serial connection to the other teensy before I plug it into USB or to disconnect the first teensy from USB. Another alternative I have found is to have the teensy loader application running on the PC, press the button on the second teensy (without LED and COM port showing) and click the reboot button in the teensy loader application.
 
That detail is helpful and as expected - where the LED on each turns on at the start.

When both T_3.6's start up have you confirmed sending USB data to either Teensy is transmitted and display on the other Teeny USB Serial Monitor - this takes to active Serial monitors with one connected to each Teensy. I will do this using TyCommander as the IDE SerMon will not do this with a single instance of the IDE open.

Are any other wires or hardware attached to either Teensy?

I have not wired this up yet wanting to see the posted detail was this close to correct to see the trouble. I see it is Windows 10 so I could repeat this test.

It does seem odd to have the second T_3.6 ever not light the LED as noted - and then to persist in that behavior - especially across plugging it in while the first T_3.6 remains powered.

Not quite clear on the Button press - if TeensyLoader is active with the HEX at hand having been compiled - and in AUTO mode, the normal default case - it should automatically reprogram the Teensy and restart it. It only goes out of Auto Mode when some confusion exists over rapid restarts.

I will look to set this up. One more piece of information that may be helpful to Paul at a glance would be a copy of the 'Help / Verbose Info' log file.

> Open the IDE with the code and do a Ctrl+R Verify build
> Open the Verbose info and clear the log.
> Press the button on Second Teensy
> Press the button on First Teensy

This should bring them both up and running?

Then repeat the test - unplugging the second 'problem' Teensy - and then replug it as needed until it fails.
* NOTE: once plugged in unplugging it too quickly will confuse windows if it doesn't get time to identify it - this can take 1-2 seconds - wait for the Windows USB Arrival sound
* NOTE: be careful not to press or hold the Teensy button while plugging it in
* NOTE: Plugging it back in without a short pause could also confuse Windows - wait for the Windows USB Departure sound

Once the second Teensy has failed to light the LED - and print anything to the Serial Monitor and the problem exists on the 'Verbose Information' window do a ' Log / Save As … '

I'll see how quickly I can set this up and perhaps modify this code to confirm the T_3.6 power up and operation.
 
Paul / @lhak:

I set this up with two T_3.6's. Wired GND and the crossed Rx and Tx on Serial2 pins. Using the code from post #2 - removing the extraneous "*/" I left on the end.

It does indeed not work as expected - but rather as described in post #8. When failed a button press Auto Loaded the same code again and the unit came up running.

I've seen signs of this before it seems in that the serial monitor of the always powered Teensy ends up with this being sent to the Serial Monitor { TyCommander }:
T:\tCode\FORUM\T3.6Power\T3.6Power.ino May 10 2019 03:10:21
���
>> Those extraneous non-ascii chars have shown other times when using Teensy as UART to USB converters - but would get repowered [ or TyCommander GUI Reset ] without thought or knowing the other Teensy was hung.

Attached is a ZIP of:
> Sketch as used : T3.6Power.ino
> OneTeensy.txt :: Always powered Teensy [Serial #2649050 on Com3/usb-1-8-2] :: The SerMon copy including the Serial2 input data from the Second Teensy
> T36Power.txt :: TLoader verbose of first programming and plug/unplug of Second Teensy until fail
> T36PowerRepro.txt :: Second shorter TLoader Verbose where it reproduced the issue
> TwoTeensy.txt :: The Serial Monitor USB output captured after it failed while data was still available - just shows initial string prints as expected.
-- second T_3.6 Ser#:2273070 on usb-1-8-1/Com10

NOTE: There is NO difference in which Teensy is FIRST or SECOND - only which one stays powered (FIRST) and which is unplugged from USN and then re-Plugged.
>> SEE POST #10 - this may not be true - though I thought I saw it once

In my setup I am using a single powered HUB, and just pull and replace the plug. On the first trial I noticed I was pulling the plug enough to hear 'USB Exit' sound, but may have not removed far enough to drop power on first attempts.

Does not always FAIL - except in both trial cases above! - My hub has these USB ports switched together - turned both off and on. Then pulled and replaced USB plug ~10 times on one and then the other - in all ~20 cases both units stayed working?

Then I hit Program to each unit and repeated ~5 times each and both stayed properly active.
 
Last edited:
RE post #10 - I may have found the missing piece...

Turn off BOTH T_3.6's

Power first T_3.6

… wait about 2 seconds

Plug in Second T_3.6 … it won't arrive

Setup - powered USB hub, Win 10, IDE 1.8.9. TeensyDuino 1.47beta2

It seems to happen hardly with one First, but changing the order repeats reliably that the second Teensy till never arrive.

Is it a break in Windows USB where usb-1-8-2 online first can affect the arrival of usb-1-8-1 while it is powering up and transmitting the first message?

Once that happens Second T_3.6 even if unplugged and replugged stays missing, until both off - or Button.

VERY ODD: When Second will not start - with it unplugged - press and hold button ( to discharge a few seconds ) - plug in Second T_3.6 - TeensyLoader programs it through bootloader to running when plugged in ????
 
Status
Not open for further replies.
Back
Top