Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 4 of 4

Thread: Teensy 4 / MicroMod boot speed?

  1. #1

    Teensy 4 / MicroMod boot speed?

    I tried searching for a previous answer but could not find one. Maybe my google-fu is weak...

    I'm seeing that it takes about 2 seconds for my sketch to start being able to operate. I plug in USB and nothing happens for 2 seconds then it starts to work and print things to screen. Previously while using Arduino Due boards I'm pretty sure it would boot basically instantly and anything I tried to write to USB would just plain be lost until USB was fully set up and running. I'm assuming the Teensy is instead pausing the sketch until USB actually succeeds. I'd rather not do this. There are some cases where it's handy for a program to start up within a very short time and be able to assume control of other hardware.

    So, the questions are:
    1. Is this normal for Teensy boards?
    2. Is there any way to tell the core not to wait for USB to actually connect?
    3. Am I to assume (I will test) that connecting without USB would instead allow me to start up at breakneck speed?

  2. #2
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Maybe you have Serial.begin(9600) in your program?

    On Teensy, Serial.begin() tries to wait for the Arduino Serial Monitor to connect. It waits up to 2 seconds if your PC begins the USB detection process (called "enumeration" in USB speak), but gives up after only 0.7 seconds if no computer appears to be connected to the USB port. My guess is you're suffering that 2 second delay from Serial.begin() which sees a computer is connected and is trying to wait until the serial monitor really is ready.

    Serial.begin() is optional. You can just delete it. USB will still work, but know that the first thing your program sends with Serial.print() might not appear in the Arduino Serial Monitor that's already open because the PC hasn't loaded its drivers and done other USB setup stuff.

    The startup code has a 0.3 second delay by default. If you really want faster startup, it can be edited. You can also use one of the startup hook functions to defeat this delay, but there's not really much documentation (yet) about how to do this. Just deleting that delay from the startup code would be easiest. However, many chips have a startup time in the 0.1 to 0.2 second range, especially motion sensors. Most libraries for sensors won't work. We added that 300ms delay many years ago because so many people experienced a "Teensy doesn't keep my program in non-volatile flash" problem which really turned out to be their program using motion sensors would work after uploading, but not after power cycle, because it was trying to initialize the sensors before they booted up. The 0.3 sec delay "fixed" all those problems!

    The hardware also has some small delay from poweron to running the first part of the startup code. But it's only a few dozen milliseconds and you really can't do much about it.

  3. #3


    Thanks, taking out the call to Serial.begin really did cut down the start up time. Now I can get output within 1/2 a second of boot time as reported by millis(). That's probably fast enough for my uses. The problem I was trying to solve is the inverse of why you have a 0.3 second delay. In cars some of the hardware attached to CAN wants messages very soon after it boots. 2 seconds is too long and causes the devices to hard fault. But, I think 500ms is fast enough as the other devices on the network need to boot as well. I'll keep the hard programmed delay in mind in case I do need more speed but I can confirm the really long delay is gone. Thanks for the quick turn around!

  4. #4
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Quote Originally Posted by PaulStoffregen View Post

    The startup code has a 0.3 second delay by default. If you really want faster startup, it can be edited. You can also use one of the startup hook functions to defeat this delay, but there's not really much documentation (yet) about how to do this.

    @Paul: just created Teensy-4-x-Hooks-before-setup()
    > note the time added for PSRAM:
    #ifdef ARDUINO_TEENSY41
    @CollinK: also there are notes on startup timing and while looking at the hook()'s code two #define's are there that can be overridden with a build edit - not having to change the source code.
    > Note: changing "TEENSY_INIT_USB_DELAY_AFTER 280" much below 280 doesn't result in USB coming online faster below some value even if the code gets into setup() more quickly

    / There are fixed delays in the Resethandler() to allow USB init to being and other connected devices to power up on cold start
    // These are after _middle_ and before _late_ hooks If these values below are #DEFINED for the build the wait times can be changed
    // The code above records entry to _middle_ on a T_4.1 with no PSRAM at 1ms to _middle_ and then 300ms to _late_
    // With PSRAM it is 327ms on a locked Teensy 4.1 with 1 PSRAM, and 653 ms on an unlocked T_4.1 with (2) PSRAMs
    // If NOT predefined when building these values are used in TD 1.57:
    //      #define TEENSY_INIT_USB_DELAY_BEFORE 20
    //      #define TEENSY_INIT_USB_DELAY_AFTER 280 // added to above avlue give 300 ms

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts