Serial not picking up data on resets

Status
Not open for further replies.

MolsonB

Active member
I have a weird issue that I can't seem to fix or debug very well. Have a device that pumps data out their serial bus into teensy 3.6.

When I first boot up the power or send new code, the serial data get's picked up by teensy. If I unplug the serial cable and re-plug in, teensy stops picking up the serial data. Takes a few times of unplugging and re-plugging the serial cable before the serial data get's picked up again by Teensy. I can confirm with scope that data is being delivered each time.

I scaled down the code to a simple sketch and still seems to be an issue for me. Any idea what I can try next?


Code:
#include <Metro.h>          
Metro Serial1_TMR = Metro(1000); 

void setup() {
  Serial.begin(115200);
  Serial1.begin(19200); 
}

void loop() {
  if (Serial1_TMR.check()) {
    Serial.println("No Data");
  }

  while (Serial1.available() > 0) {
    Serial1.read();
    Serial1_TMR.reset();
    Serial.println("HERE");
  }
}




Results
......
HERE
HERE
HERE
HERE
HERE
HERE
HERE
No Data
No Data
No Data
No Data
HERE (unplug cable)
No Data (plug in cable)
No Data
HERE (unplug cable)
No Data (plug in cable)
No Data
No Data
HERE (unplug cable)
HERE
No Data (plug in cable)
No Data
No Data
HERE (unplug cable)
HERE (plug in cable)
HERE
HERE
HERE
......
 
You may have a timing issue...

You might try waiting until the Serial port is available, like:
Code:
#include <Metro.h>          
Metro Serial1_TMR = Metro(1000); 

void setup() {
  while (!Serial) ;
  Serial.begin(115200);
  Serial1.begin(19200); 
}

void loop() {
  if (Serial1_TMR.check()) {
    Serial.println("No Data");
  }

  while (Serial1.available() > 0) {
    Serial1.read();
    Serial1_TMR.reset();
    Serial.println("HERE");
  }
}
This one will wait until the Serial object is ready before continuing... Normally when I do this I put in some timeout, like:
Code:
while (!Serial && (millis() < 2000)) ;
Which would wait up to 2 seconds...
 
This mainly happens while the teensy is already running it's code. I do think it's a timing issue, as if I need to plug in the cable while the device is inbetween sending data packets.
 
Sorry misread your question.

When you unplug USB does that un power the Teensy or does it continue to run? (using VIN pin?)

I have not used metro, but looks like a simple timer check.... So probably nothing with it...

Not sure what is on the other end of your Serial1 connection. Is it powered while the USB is not connected? Does it try to keep sending data? Does it need something to tell it to continue if it filled it's own buffers? ... Again sorry not much help
 
I'm using Vin for both the teensy and the other serial1 connection, with a power supply. The serial1 device continually pumps out data, doesn't need/wait for any feedback. I've confirmed with scope that the data is always present on the teensy pin, even when teensy isn't picking up the data.

Any help is help. Thank you. I know this shouldn't be hard, probably something really dumb that I'm doing / overlooking.
 
Again it is hard to guess not seeing the actual data or the like... I would probably add some more diagnostics to get an idea... Again not sure how much it would help.

Code:
#include <Metro.h>          
Metro Serial1_TMR = Metro(1000); 

void setup() {
  Serial.begin(115200);
  Serial1.begin(19200); 
  pinMode(13, OUTPUT);
}

void loop() {
  if (Serial1_TMR.check()) {
    Serial.println("No Data");
  }

  if (Serial.available()) {
    digitalWrite(13, HIGH);
    while (Serial1.available() > 0) {
      Serial1.read();
      Serial1_TMR.reset();
      Serial.println("HERE");
    }
    digitalWrite(13, LOW);
  }
}
Then hopefully you can monitor when you receive data as the LED should go on and off... Also you can hook up scope to it and maybe to Serial1 RX pin so you can see how well they reflect each other.
 
With the Teensy powered by Vin from external supply when USB plugged in you'll have two power sources feeding the Teensy.

Have you cut the underside VIN<>VUSB pads apart? That will require VIN power to run the Teensy and the USB cable will only connect to program or receive USB/Serial() data.
 
Yes underside is cut. No power from the computer.

I'm trying a different teensy and a different serial device as we speak.
 
Last edited:
It has to do with the timing. At 19200, the bus was too over loaded and couldn't "re-connect" a starting packet (I'm guessing).
Up'd it to 38400 and it seems to catch every time I unplug and replug in the cable.
 
Again without seeing your data stream hard to totally say what it is seeing...

If for example your stream is a constant output with no breaks between groups, than maybe hard for hardware to synch up. If there are gaps between groups than hopefully they can synchronize on the byte level... Than if you have packets of data, you need to setup mechanism to get back in synch. In the past I have done this with packets lets say arriving by XBee, by either having a known preamble on a message, like: 0xff 0xff <data> where data did not have 0xff in it... I also had timeouts in my code.

I know that my packets were lets say 8 bytes long, so if I get a gap in receiving data in a packet over a threshold, I know I am out of synch, so I toss everything, wait for a byte that arrives after some gap of time (known that packets are spaced every N milliseconds or the like) and then know that should be the first byte of the new packet...
 
Again without seeing your data stream hard to totally say what it is seeing...

If for example your stream is a constant output with no breaks between groups, than maybe hard for hardware to synch up. If there are gaps between groups than hopefully they can synchronize on the byte level... Than if you have packets of data, you need to setup mechanism to get back in synch. In the past I have done this with packets lets say arriving by XBee, by either having a known preamble on a message, like: 0xff 0xff <data> where data did not have 0xff in it... I also had timeouts in my code.

I know that my packets were lets say 8 bytes long, so if I get a gap in receiving data in a packet over a threshold, I know I am out of synch, so I toss everything, wait for a byte that arrives after some gap of time (known that packets are spaced every N milliseconds or the like) and then know that should be the first byte of the new packet...

Oh yeah, I have a good processing sub routine to handle the start & end flags, checksum and stuffed bytes. But I dumbed down the sketch to just read anything on the serial bus for this example to keep things simple. It's hard to tell if there was any 'breaks' between the packets, I'm guessing not enough for Teensy to pick up on. Which is weird because it does work when things first boot up. Tried with 3.2 and 3.6

Paul, using Windows7, but I was only using the serial.print for this example to see if the data was being picked up. Tried with onboard LED with the computer not connected with same results. Very weird, the data is there at the pin, but it is like there wasn't enough of a break between packets to be picked up. It does work if the teensy is running first, then the streaming device turns on. Increasing the baud rate to 38400 seem to make it stable and pick up the serial bus every time I re-plug in the data cable.
 
using Windows7

Maybe you're hitting this Windows driver bug? With Arduino, the serial monitor automatically closes when you upload. But if you have another program running when you upload, or if you physically unplug the cable, well, Windows 7 and all pre-10 versions have this very confusing bug:

 
Oh Sorry, I didn't explain this well enough.

The devices (Teensy and DeviceX) are standalone and talk to each other via serial cable on serial1. DeviceX just pumps out data on the serial cable while the Teensy reads and processes the sensor data. If I start the Teensy first, then DeviceX, everything goes well and Teensy reads the serial1 data. If I reset DeviceX, or unplug the serial cable between them and plug it back in, Teensy has a hard time picking up the serial1 data. We think the serial1 stream didn't have enough breaks in transmission for the Teensy to pickup a starting packet. (maybe?) AS soon as I turn off some sensor data, the stream starts again automatically. Or if I keep on unplugging and replugging in the serial cable a few times. I can even add those sensors back in once the teensy is reading the data again.

Nothing to do with windows and usb cable. Just for this example, I was writing out to the serial monitor anytime it picked up serial1 data. Normally a computer is not hooked up.
 
Is the data send at maximum rate without any gaps, so each start bit comes immediately on the tail of the prior stop bit?

This is a well known problem with all async serial communication. Just mentioned it over on this other thread.

Or maybe it is unable to sync to the start bits? If it initializes after the data stream has begun, there's a chance it could mistake some data bit the start bit, and forever not be able to recover because Teensy is managing to relentlessly send maximum possible speed data with no extra gaps that would allow the receiving UART to recover and find a true start bit again.
 
Yup stupid me, I should of done this simple test a year ago to see how much data was being passed. Turns out, found a bug in DeviceX with their code overloading the serial bus.

Code:
#include <Metro.h>          
Metro Serial1_TMR = Metro(1000); 

long counter;

void setup() {
  while (!Serial && (millis() < 2000)) ;
  Serial.begin(115200);
  Serial1.begin(38400); 
}

void loop() {
  if (Serial1_TMR.check()) {
    Serial.println(counter);
    counter = 0;
  }
 
  if (Serial1.available()) {
    Serial1.read();
    counter++;
  }
}

@19200 baud, it was being maxed out at 1920 bytes per second when a certain sensor was activated
@38400 baud, it was averaging around ~2070 bytes per second.

The joys of debuggin devices you don't have source code to. I sent the info back to the manufacturing company for DeviceX to fix.
 
Status
Not open for further replies.
Back
Top