All sketches lock up on Teensy 3.6 for me

CollinK

Well-known member
Yes, every sketch. Any sketch. It is always after a seemingly determinate amount of time: something like 1.4 seconds.

Here's a test sketch that still locks up on me:
Code:
void setup() {
  delay(1000);
  Serial.println(F("Board test."));
}

void loop() {
  delay(25);
  Serial.print(".");
}

It prints the start up message and then several .'s and dies. It will print the same number of dots if rebooted. Changing the 1000 ms delay at the beginning will cause more or less dots but the 1.4 seconds remains. Changing the loop delay will cause more or less dots to appear but the 1.4 second crash remains. Changing the startup delay to more than 1.4 seconds causes nothing to ever print. I must believe that something is hosed on my machine as someone would have noticed this by now otherwise.

I'm running Linux (Mint) the latest version. Arduino IDE 1.6.12 and 1.31 TeensyDuino. This configuration should have been thoroughly tested by now so it must be me but I don't know why. The only complicating factor I can think of is that my laptop is set to Russian for the default language and the IDE is in Russian. Maybe there is some sort of oddity with using a US keyboard but with the interface in Russian? Or, maybe I somehow have corrupted files? Or, is the 1.6.12 IDE not the thing to use? It's really acting like there is a watchdog set to 1.4 seconds and I'm not resetting any watchdog. But, I'm not aware of any such thing being active on a Teensy by default. Also, yes, I did try different speeds, down to 72MHz and nothing changes at all. Always I can do whatever I want in the sketch but when 1.4 seconds comes around it dies.

EDIT: I take it back, the time it dies at is 1780ms. It sometimes could fluctuate up to around 1785 but it is very tight around that exact time when it dies.
 
Last edited:
You might try adding a Serial.begin()...

For example try:
Code:
int count = 0;
void setup() {
    Serial.begin(115200);
    while (!Serial && (millis() < 3000)) ;
    delay(250);
    Serial.println("Board test");
}

void loop() {
    delay(25);
    Serial.print(".");
    count++;
    if (count > 50) {
        Serial.println();
        count = 0;
    }
}
I also added a simple counter to output something like 50 .'s per line, as I can not tell from your description if the Teensy itself is hanging up or maybe the terminal monitor that you are displaying the results in or...
 
That simple sketch ran fine on the pair of T_3.6's on my desk. I'm on Win 10 with IDE 1.6.12 and TD_1.31. And I use TYQT for my uploader and Serial Monitor.

What do you see with the sketch below? It adds a blink that shows the Teensy is running loop() in the event you are just losing USB connect to the computer. It would run the same on a battery pack - or a power only cable - or any case with no USB Serial Monitor after a 4 second delay.

I left the F() on the test string - but it has no use or value on Teensy where static strings go to FLASH by default.

Code:
#define qBlink() (digitalWriteFast(LED_BUILTIN, !digitalReadFast(LED_BUILTIN) ))

void setup() {
  pinMode(LED_BUILTIN, OUTPUT);
  qBlink();
  while (!Serial && (millis() <= 4000)) ;
  Serial.println(F("\nBoard test."));
  Serial.println(millis());
}

int ii = 200;
void loop() {
  delay(25);
  qBlink();
  Serial.print(".");
  ii++;
  if (ii > 50) {
    Serial.println(millis());
    ii = 0;
  }
}

It starts like this here::
Board test.
783
.808
...................................................2083
...................................................3358
 
Thanks for the suggestions. I'm finding all of this weird because I compile Arduino Due sketches constantly and I've never had this trouble... Well, new results:

In Windows 10 (I can dual boot) it works perfectly fine. I don't have to recompile the sketch even. The same sketch that locked up in linux just works flawlessly if I boot into Windows and ask for the serial monitor. So, it's something with my linux installation. I've tried downloading Arduino IDE 1.6.11 and then applying Teensyduino to that and the problem remains. On a lark I switched my language back to English in case that matters. It doesn't. The idea of flashing an LED was a good one and I tried that sketch. Sure enough, the LED keeps going but the serial data just plain dies after 1.8 seconds. So, the problem is maintaining a consistent serial connection in Linux and it does not seem to be related to the Arduino IDE or Teensyduino files. It's just my laptop apparently. "dmesg" doesn't show any USB faults happening when this occurs so that's unfortunately not helpful.

My last remaining idea is that perhaps it is an issue with USB access. I had to run the IDE as root to allow the Teensy loader program to find the board for upload. I don't have this trouble with Due boards so either I previously installed the proper patches to my USB subsystem for the Due or it doesn't need it. I've seen mention that Teensy boards do need a file installed to make them work without needing root. I suppose I should go dig up the info on that and try it and see if not running root makes any difference.
 
Indeed, 49-teensy.rules fixed the problem. I don't know why it locks up on me if I'm running the Arduino IDE sudo but it sure does. Applying the proper udev rules file and running as my normal user works perfectly fine. I guess hopefully this thread can stand witness to the potential need to use the 49-teensy.rules file when running on Linux. I didn't think running as root would break anything, I have no idea why it did. But, that was the problem.
 
Thanks for the suggestions. ...
The idea of flashing an LED was a good one and I tried that sketch. Sure enough, the LED keeps going but the serial data just plain dies after 1.8 seconds.
...

Glad that worked and gave you hope to continue to find the problem. BLINKING the LED is not just fun - but an important tool for seeing what is going on.

Indeed udev rules is needed - odd that it worked at all if it is supposed to be 'controlled'?
 
Glad that worked and gave you hope to continue to find the problem. BLINKING the LED is not just fun - but an important tool for seeing what is going on.

Indeed udev rules is needed - odd that it worked at all if it is supposed to be 'controlled'?

Yeah, I had thought that maybe I should be trying to flash the LED but then I told myself it wouldn't matter. The lies we tell ourselves... And, I knew better than to run the IDE as root but I've done that in a bout of laziness before with the Due boards and it worked fine. I knew I should eventually find the rules and install them but it didn't seem like it would be imperative right away.

Oddly enough, the rules file is NOT included anywhere when you install Teenyduino. You have to go find it and download it separately. If it is that important it should be included in the installer and either automatically installed or put in an easy place to find.

So, it works again. Peace has been restored to the galaxy.
 
Yeah, I had thought that maybe I should be trying to flash the LED but then I told myself it wouldn't matter. The lies we tell ourselves...
Indeed the voices in our heads often know more than we give them credit for - and we ignore them at our own peril. At least no blood or 'magic smoke' was spilled ... this time.

So, it works again. Peace has been restored to the galaxy.
What galaxy do you live in :)
 
Occasionally I've considered adding the udev rule to the Teensyduino installer. But doing this would require adding a step to the GUI to prompt for either the root password or a sudo account password, and then either changing the process permission with setuid() or seteuid(), or forking and running an interactive shell for sudo. Perhaps only the sudo approach would need to be supported? On some systems, sudo does funny terminal stuff for security purposes, but has an option to (maybe on all systems) get the password from stdin. The man page says it has an --askpass option to run a GUI program to securely prompt the user for a password, but when I try on Ubuntu 14 it doesn't work (no default askpath program set up).

Windows, despite its many headaches, makes this sort of thing very easy to do consistently. First, the program can be identified as an installer, which solves the problem of securely prompting for permission without having to build a bunch of GUI stuff to ask for the root or sudo password, and handle such sensitive security info with my own code. Then to install the INF (aka "driver" even though it's just a text file, similar to the udev rule), there's a WIN32 SetupCopyOEMInf system call to actually install it. All versions of Windows support this system call. It's not 100% perfect. When Windows 10 came out with the INF finally built into Windows, I did add some code to detect that case and skip this step, but that was pretty simple.

Desktop Linux is a nightmare of inconsistency across dozens of differently configured distributions, or even a few years of releases within almost any single distro. It's also a minefield of GUI library compatibility headaches, like the Teensy Loader problems we've been seeing with baked in GTK dependency on incompatible versions of libpng. Fortunately the installer is built on FLTK rather than wxWidgets, so it avoids GTK.

On Linux, the Teensyduino installer is purely about modifying ordinary user permission files within a single folder. Linux is already quite troublesome. I'm really not eager to add code with assumptions about distribution specific stuff that's likely to make supporting Linux any harder than it already is.

Maybe a nag/reminder message could work. That would require only reading files that normally have read permission. Maybe?
 
Last edited:
Paul, it would be helpful if the udev rule file was included as one of the files installed by the installer, so that people don't have to download it separately. And have the final screen of the installer on Linux remind Linux users to install the rule.
 
Paul, it would be helpful if the udev rule file was included as one of the files installed by the installer, so that people don't have to download it separately. And have the final screen of the installer on Linux remind Linux users to install the rule.
Not being a unix user (anymore), but maybe having for Linux a special warning with instructions before the last step1 to 3 screen could be an idea.
 
Paul, it would be helpful if the udev rule file was included as one of the files installed by the installer, so that people don't have to download it separately. And have the final screen of the installer on Linux remind Linux users to install the rule.
I agree, maybe should be put into the top level directory of where Arduino was installed. In addition, maybe have a script file that is setup for the user to do the copy. Don't know how hard it would be to check to see if the file already existed (like the windows check), and if not, maybe at the end, maybe either put up message box, telling user to do: sudo install_udev
But maybe not every installation has sudo...

When I install on Linux, I often do it from command prompt, so in that case, maybe just an ugly reminder at the end. For cases where I use the GUI, to turn on the Execute bit using properties and then click on it to launch, Maybe dialog, or maybe hack to open command prompt for the user...

But maybe the assumption is, if the user is using Linux, they know what they are doing.
 
Yeah, I don't mind it not automatically installing. I just found it odd that the rules file is not even included in the installation. I had to go online and look for it along with the instructions (yeah, I use linux but I don't routinely install udev rules so I didn't really remember where they were supposed to go). So, I'd vote for including the file and just reminding linux users that they really, really should install it.
 
Back
Top