Power restart on Teensy 3.6


Well-known member
My Teensys 3.6 do not start at power up but appear dead. Connecting it to the computer and uploading the program again, it works fine though. Using the exact same program with a Teensy 3.2, the system starts up every time, when power is applied. In both cases power is applied externally - not via the USB port.

The Teensy 3.6 is from the Kickstarter batch, unlike the 3.2 which run the Blinky program after power up, this was not the case with the Teensy 3.6.

Is there something extra I have to connect or program to get it to restart?
Might help to see the program!

Could be as simple as having something like: while (!Serial) ;
In setup so code is waiting for uSB...
But why would the 3.6 need this when the 3.2 is working fine without it? The system is supposed to work independent of any connection to a computer.
This question comes up regularly...

My Teensys 3.6 do not start at power up but appear dead.
But why would the 3.6 need this when the 3.2 is working fine without it?

... and it's almost always something in the application which doesn't handle startup properly. People usually believe it's a problem with Teensy, but it always turns out to be something not done correctly at startup. Failing to wait for other chips which have slow startup is a common issue. Teensy 3.6 runs much faster than 3.2. Perhaps the code which works on 3.2 does so only just barely, depending on its executing speed?

We have the "Forum Rule" for exactly this sort of situation. If you want useful help, you really must post a complete (but hopefully concise) program which shows the problem.

Edit: It's also possible there is a bug in Teensy 3.6's core library or other library code. As you can see in the 1.32-beta1 changes, small issues on 3.6 are still being found and fixed. Again, nobody can look into the true cause of the problem unless you post a complete program that demonstrates the problem. If you do, and if it's really a problem with Teensy 3.6, I do want to look into the issue and fix it... so please, post a complete program and detailed info about your other hardware!
Last edited:
I am certain the Teensy 3.6 is working fine, the program runs without a hitch after it is uploaded and the Teensy Uploader states Reboot OK. Turning the power off and then on again, it does not boot. I have uploaded the program also with 96 MHz and 72 MHz settings with the same result.

Besides hardware which is driven by the digital outputs (opto relays) and using analog inputs and outputs I am using the 2.4" TFT display (PJRC) and a RTD board based on the MAX31865 https://hallard.me/max31865. There are provisions for other boards using the RX1/TX1 and RX3/TX3 which are currently not connected and only used when required.

Quite some time ago we had a discussion about the library program used for the MAX31865, which requires some special "tricks" to make it not clash with the display using the same SPI bus. Could that be the reason? Would it be opportune using an alternate SPI bus for the MAX31865 to circumvent the issue? Here is the link to that thread: https://forum.pjrc.com/threads/32372-SPI-problems Furthermore I just noticed an apparent hardware problem now with this board, which is showing using either the Teensy 3.2 or 3.6. I think it is related to the SPI bus connections. I will be checking that now.

I do not consider the program concise - more than 5,000 lines - and still have not learned how to enter it into the forum. Also, can I delete the program from the forum after the problem has been solved?

Edit: In the meantime I edited the code for the MAX31865 out without any change and checking the wiring it appears to be correct. The problem persists 3.2 boots with power up and 3.6 does not.
Last edited:
As several have mentioned, there is little we can do to help, other than throw darts.

My first dart is, are you using the max31... library that you mentioned in your other thread? In particular: https://github.com/hallard/arduino-max31865/blob/master/MAX31865.cpp

The things that I have run into in the past is libraries that do stuff in their constructors. For example from that library:
MAX31865_RTD::MAX31865_RTD( ptd_type type, uint8_t cs_pin, uint16_t rtd_rref )
  /* Set the type of PTD. */
  this->type = type;

  /* CS pin for the SPI device. */
  this->cs_pin = cs_pin;
  pinMode( this->cs_pin, OUTPUT );

  /* Pull the CS pin high to avoid conflicts on SPI bus. */
  digitalWrite( this->cs_pin, HIGH );

  // reference resistor value set ?
  if (rtd_rref)
    this->configuration_rtd_rref = rtd_rref;
    this->configuration_rtd_rref = type == RTD_PT100 ? RTD_RREF_PT100 : RTD_RREF_PT1000;
I have found that doing stuff to hardware like pinMode, and the like can sometimes lead to issues, like a program never gets to the setup() function.

So when I run into issues like this, I start doing stuff like, first things in setup:

While (!Serial && (millis() < 2000)) ;
Serial.println("Setup Called");Serial.flush(); // make sure it goes out before something else called.
Then I add more Serial.println like calls before and after each call made by setup, to see if we hang where it was called...

If the first print does not come out, try commenting out the pinMode/digitalWrite in the library mentioned and move them into configure method

But again just throwing darts!

Edit: when you said you edited it out, did you actually remove the object (so the constructor was not called?)
Kurt, yes that is the library I was using, however I have edited it all out so it is no longer being used but still have the same problem.

I'll keep looking and trialling. :)
Edit,Oops, clicked the wrong button at first.

Here is another tidbit of info: After compiling the program, the Teensy 3.2 reboots automatically for the Teensy 3.6 I always have to press the reset button.

Sketch uses 267,828 bytes (25%) of program storage space. Maximum is 1,048,576 bytes.
Global variables use 13,332 bytes (5%) of dynamic memory, leaving 248,812 bytes for local variables. Maximum is 262,144 bytes.
Teensy did not respond to a USB-based request to automatically reboot.
Please press the PROGRAM MODE BUTTON on your Teensy to upload your sketch.
Last edited:
Again if it were me, I would try removing the whole library like you mentioned, including the header file. I would Exit Arduino (all windows open in that process). I would then reload Arduino and then try download the program and see if it works. That helps if the Arduino was caching some stuff and or you thought you had the whole library removed but it was still there.

Also if it were me, I would probably take the library and take 10 minutes or so and add SPI.beginTransaction/SPI.endTransaction calls around the few places that actually do SPI.
Just put them near where you muck with the SPI cs pin.
Thanks for that suggestion Kurt. I went as far as shutting down the computer and starting again but to no avail.
Today I tried to turn of the power but by mistake only interrupted it briefly, strangely at that time the system started working normally.

Edit: BTW this is totally repeatable.
Last edited:
Again it really sounds like you have a race condition going on. That is something that is probably trying to use the hardware before it is ready or maybe stuff in constructors depending on stuff to be done in a certain order.

As I mentioned, if it were me, I would probably hack up the MAX... library to use transactions.

Maybe something like, I did in the zip file here.

Then remove the other SPI init stuff you were doing, like setting mode3 and setting speed...

If it works, again I don't know if you are the library owner if so, maybe pull in the changes. If not try to issue a Pull request... This is not specific to Teensy, but should work with most newer Arduino IDEs...


  • max31865.zip
    18.5 KB · Views: 96
After some trials and tribulations I am at the same point, my Teensys 3.6 will not start at power up but work perfectly after uploading a program. Using the Teensy 3.2 instead the problem is eliminated. Since the issue is happening right at the beginning, I have eliminated everything else and only a few lines of code are left to demonstrate the problem. I am using the 2.4" and the 2.2" TFT's from PJRC and the issue is the same for both. I am baffled.

#include "SPI.h"
#include "ILI9341_t3.h"
#include <XPT2046_Touchscreen.h>
#include <font_LiberationSansNarrowBold.h>

#define TFT_DC 20                                    // TFT screen 
#define TFT_CS  9                                    // TFT screen select for SPI
#define CS_PIN  15                                   // Touch panel select for SPI

// Use hardware SPI
ILI9341_t3 tft = ILI9341_t3(TFT_CS, TFT_DC);
XPT2046_Touchscreen ts(CS_PIN);

void setup() {
  Serial.begin(115200);                              // Set up serial port


  SPI.setSCK(13);                                    // SCK pin default
  SPI.begin();                                       // Setup and begin SPI library:

void loop() {
  tft.begin();                                       // Initialize the display
  tft.setRotation(3);                                // Rotate the display to be horizontal
  tft.fillScreen(ILI9341_BLACK);                     // Clear the display
  tft.setTextColor(ILI9341_RED);                     // Set the text color
  tft.setFont(LiberationSansNarrow_16_Bold);         // Set the font size
  tft.setCursor(125, 20);                            // Set the curser position
  tft.print("ViscoTron");                            // Print the text
  tft.setFont(LiberationSansNarrow_12_Bold);         // Set the font size
  tft.setTextColor(ILI9341_WHITE);                   // Set text color
  tft.setCursor(160, 60);                            // Set the curser position
  tft.print("by");                                   // Print the text
  tft.setFont(LiberationSansNarrow_16_Bold);         // Set the font size
  tft.setTextColor(ILI9341_RED);                     // Set text color
  tft.setCursor(70, 88);                             // set the cursor position
  tft.print("Viscotronics Co., Ltd.");               // Print the text
  tft.setTextColor(ILI9341_WHITE);                   // Set text color
  tft.setFont(LiberationSansNarrow_12_Bold);         // Set the font size 
  tft.setCursor(125, 130);                           // Set the cursor positoon
  tft.print("designed in");                          // Print the text
  tft.setFont(LiberationSansNarrow_16_Bold);         // Set the font size
  tft.setCursor(55, 160);                            // Set the cursor position
  tft.print("British Columbia, Canada");             // Print the text     
  tft.setFont(LiberationSansNarrow_16_Bold);         // Set the font size
  tft.setCursor(65, 200);                            // Set the cursor position
  tft.print("info@viscotronics.com");                // Print the text
  delay(2000);                                       // Delay 2 seconds

Edit: Since I also have a single Teensy 3.5 available I tried that one as well. First thing different to the 3.6 was that it started off with Blinky when I plugged in the USB port. I then severed the USB power connection, started it with external power and it worked on Blinky right away. After that I uploaded the code above and powered down and up and it was working same as the Teensy 3.2. Now I am just more baffled.
Last edited:
I reported a problem that I think is related here https://forum.pjrc.com/threads/39107-Teensy-3-6-Slow-boot-time with the Teensy 3.6.

While my program does boot up, it takes much longer, about 15 seconds with the Teensy 3.6, while the 3.2 and 3.5 boot up almost instantly. I'm using Watchdog code so that's maybe why it starts up after a while. While writing this, I decided to disable the watchdog code by not calling startup_early_hook(), and as a result my program never starts up now, just like your code.

I can also repeat your issue above by using the example blink sketch.

int led = 13;

// the setup routine runs once when you press reset:
void setup() {                
  // initialize the digital pin as an output.
  pinMode(led, OUTPUT);     

// the loop routine runs over and over again forever:
void loop() {
  digitalWrite(led, HIGH);   // turn the LED on (HIGH is the voltage level)
  delay(1000);               // wait for a second
  digitalWrite(led, LOW);    // turn the LED off by making the voltage LOW
  delay(1000);               // wait for a second

When I power on the blink sketch it does not boot up at all unless I turn the power off and then on in quickly.

In my hardware I'm setup using a 12V to 5V converter plugged into another circuit board and I use that to power the Teensy 3.6 and an LED panel. Exact same setup works in 3.2 and 3.5. If I use an external 5V power source plugged directly into my Teensy it seems to work most of the time, depending on the power source. In my situation it seems like the teensy is trying to start before it has full power locking up as a result.
Wow coinop, that sounds so much like my problem. I am also using a 12 V to 5 V converter. In my case the 12 V power something else. I have a 1,000 uF capacitor connected to the 5 V supply. I can also turn it off and on quickly to make it work most of the time.

Teensy 3.2 and 3.5 work fine though.
Which BEC or the like are you using? Will check again with one of my boards that has a built in 5v regulator, that I use to alow 3S liipo to work. I actually have not tried it yet with Lipo, but have used 5amp 12v AC/DC converter.
Kurt, I am not familiar with the terms BEC, 3S liipo and Lipo, so the below may not answer your questions.

I am using a 12V DC/DC isolation converter, which has a maximum of 0.83 A (XP-JCA1012S12). The output is connected to two separate buck converters, one of which is used for the Teensy and related circuitry. It is set to to 5 VDC. The other one only comes into use about 30 seconds after the program has started. The voltage for that circuit is adjusted depending on the application and uses a maximum of 150 mA.
Yep on my Robots I have used BEC(Battery Eliminator Circuit) like: https://www.amazon.com/Castle-Creat..._1?ie=UTF8&qid=1480380156&sr=8-1&keywords=bec To drive Teensy and or Odroid or RPI...

I have not used your converter so maybe not much help. If I get a chance I will try with the BEC I have and also again with with boards using the DC/DC converter I am using.
One board is using: https://www.digikey.com/product-det...lutions-inc/OKR-T-6-W12-C/811-2179-ND/2199629
Some of my others are using: https://www.digikey.com/product-det...inc/OKI-78SR-5-1.5-W36H-C/811-2692-ND/3438675 (or the vertical version)
But I have not assembled one yet with the smaller one.
Today I removed the 1,000 uF capacitor and was able to see a definite change in start up behaviour. Previously I was only able to start the teensy 3.6 either by reloading the code or most of the time by very briefly interrupting the power. Now after the removal of the capacitor I am able to turn the power off and on again. Whilst I have no definitive measurement, I think previously it was a few tenths of a second versus now being maybe 1 or 2 seconds easily.
For What it is worth, I then tried a quick hookup to the same board using the same 12v 10 amp wall wart, but this time used my BEC (https://www.amazon.com/Castle-Creat..._1?ie=UTF8&qid=1480380156&sr=8-1&keywords=bec)

And with this setup, I new get the behavior you are seeing. I plug in power and wait up to 30 seconds with no blinks, but if I quickly unplug/replug it then starts blinking...

Note: I believe that this is setup to maybe output 5.1v. So Paul this may be a cheap setup ($16+) from Amazon setup that you might want to try. Maybe later today or tomorrow, I will try to see where it is hanging, but ...
Any chance you can get access to an oscilloscope (and someone with the experience to use it) so you could capture the start-up behavior of the power supply? Capturing what's happening on Teensy's 3.3V power and maybe even the reset signal (if the scope has more than 2 channels) might be useful.
Sure, I will do that later today or early tomorrow morning. I already had turned up the power to the Teensy to 5.7 VDC but if there was a change it was not anything noticeable.
Paul, not sure how much the logic analyzer output helps. Note Currently using my Logic 8 and not my Logic Pro 8, on the off chance there looked like there is some bad voltage and if I were screw one up, prefer to screw up the cheaper one :D

Here is logic output for T36 again with VIN, D13 and reset, with both Analog and digital.

But as it looks like voltage are not out of range, if it would help, I can get faster resolution with the PRO if that would help. Note: I left it plugged in and finally started blinking a few minutes later.

Just in case it helps. I hooked up Pro. Here is showing that area. again... It is interesting looking at the voltages ramping up.
Last edited:
Hi Paul,

here you go.The screenshot was done by quickly turning the power off and on again, so that the processor starts. I also tried longer off periods and the processor still started after a brief delay with the traces looking identical. Please keep in mind, that I removed the 1,000 uF capacitor, I had in there, however I should put at least some capacitance back in to avoid the ripple when measuring an analog signal.

The yellow trace represents the currently 5.7 VDC output from the buck converter The input to the buck converter is 12 VDC from a DC/DC isolation converter, which has an input of 12 VDC from a lab power supply (EA-PS 3032-06 B) The supply can provide a maximum of 5 A. The maximum current draw is 300 mA during operation.

The magenta trace represents the 3.3 VDC output from the processor.

Screenshot 2016-11-30 18.48.33.png

Edit: if you want me to put the capacitor or one with 330 uF back in again to see the change, just let me know.
Last edited:
The yellow trace represents the currently 5.7 VDC output from the buck converter The input to the buck converter is 12 VDC from a DC/DC isolation converter

Well, that's a pretty nasty looking power supply startup, as it crosses between 1 to 2 volts.

Is this buck converter and isolation converter a product I can buy somewhere? Or if it's something you've made, is there any chance you can send me one?

Edit: my gut feeling, from only these words and that waveform, is one or both of those converters may be suffering from inadequate capacitance at their inputs. The capacitor ESR matters greatly, sometimes even moreso than the actual capacitance. So do the design details like switching frequency, the converter's circuit topology, and so on. But this is just a guess, or a hunch really, based on prior (painful) experiences with other switching power supplies.
Last edited: