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

Thread: Teensy 3.1 only runs code on usb port power from computer and not any other source

  1. #1

    Teensy 3.1 only runs code on usb port power from computer and not any other source

    Hey guys, first post here as I've been able to learn tons from just lurking and reading other posts thus far.
    My current issue though after much googling continues to elude me so hoping one of you knows something I don't!

    Here's my physical setup, it's not going to show much due to the fact that it's all attached together and there's stuff going on underneath the breadboard too:
    Click image for larger version. 

Name:	assembled.jpg 
Views:	806 
Size:	148.6 KB 
ID:	1742
    I'm running windows 8.1 and teensyduino.

    In summary this is my basic hardware setup:

    - usb power from laptop only at the moment (trying to switch over to 5v 2.1 a cigarette lighter adapter from my car)

    - 4 inputs:
    -- 1 is the red microphone breakout board from sparkfun
    -- 3 identical potentiometers from adaFruit (connected to analog)

    - 1 output:
    -- Neopixel board, soon to be replaced with some neopixel strip.

    - Everything is pretty much connected to common positive and negative leads that are on the two corners of the teensy, on the usb plug end.
    - Capacitor across pos/neg as instructed from adafruit
    - resistor inline with the signal to the neopixels as also instructed by adafruit.

    Basically, my code has been working wonderfully this whole time while debugging and working on my laptop's usb power. However when I switch to any other power source (all 5 v, betweween 1-2 amps) I get nothing coming from the led's. The only indication that everything is not frozen is a tiny indicator light on the red board that flashes when audio input passes a certain threshold, so I'm certain everything is getting power...

    Also, I have not cut any leads on the back of the board as I'm not totally sure if I should?

    Also, I've tried the default arduino blink example and the on board LED does infact blink when plugged into any other power supply so I am thinking the problem lies within my code?.....:

    #include <Adafruit_NeoPixel.h>
    #define PIN 15
    Adafruit_NeoPixel strip = Adafruit_NeoPixel(64, PIN, NEO_GRB + NEO_KHZ800);
    int numOfLeds = 64;
    int audioPin = 14;
    int pot_sensitivity_Pin = 16;
    int pot_sensitivity_val = 0;
    int pot_Speed_Pin = 17;
    int pot_Speed_Val = 0;
    int pot_Brightness_Pin = 18;
    int pot_Brightness_Val = 0;
    float pot_Brightness_Val2 = 0;
    int pot_Brightness_Val3 = 0;
    int maxBright = 64;
    // Initial multiplier for brightness.
    int valueGain = 200;
    // initial hue offset
    int hueOffset = 150;
    int micRemapMax = 128;
    // interval for pushing led values down the chain..
    long stepSize =100;
    // Gamma lookup table
    const byte dim_curve[] = {
        0,   1,   1,   2,   2,   2,   2,   2,   2,   3,   3,   3,   3,   3,   3,   3,
        3,   3,   3,   3,   3,   3,   3,   4,   4,   4,   4,   4,   4,   4,   4,   4,
        4,   4,   4,   5,   5,   5,   5,   5,   5,   5,   5,   5,   5,   6,   6,   6,
        6,   6,   6,   6,   6,   7,   7,   7,   7,   7,   7,   7,   8,   8,   8,   8,
        8,   8,   9,   9,   9,   9,   9,   9,   10,  10,  10,  10,  10,  11,  11,  11,
        11,  11,  12,  12,  12,  12,  12,  13,  13,  13,  13,  14,  14,  14,  14,  15,
        15,  15,  16,  16,  16,  16,  17,  17,  17,  18,  18,  18,  19,  19,  19,  20,
        20,  20,  21,  21,  22,  22,  22,  23,  23,  24,  24,  25,  25,  25,  26,  26,
        27,  27,  28,  28,  29,  29,  30,  30,  31,  32,  32,  33,  33,  34,  35,  35,
        36,  36,  37,  38,  38,  39,  40,  40,  41,  42,  43,  43,  44,  45,  46,  47,
        48,  48,  49,  50,  51,  52,  53,  54,  55,  56,  57,  58,  59,  60,  61,  62,
        63,  64,  65,  66,  68,  69,  70,  71,  73,  74,  75,  76,  78,  79,  81,  82,
        83,  85,  86,  88,  90,  91,  93,  94,  96,  98,  99,  101, 103, 105, 107, 109,
        110, 112, 114, 116, 118, 121, 123, 125, 127, 129, 132, 134, 136, 139, 141, 144,
        146, 149, 151, 154, 157, 159, 162, 165, 168, 171, 174, 177, 180, 183, 186, 190,
        193, 196, 200, 203, 207, 211, 214, 218, 222, 226, 230, 234, 238, 242, 248, 255,
    // Initializing some led value holding arrays.
    int ledValues_1_r[64];
    int ledValues_1_g[64];
    int ledValues_1_b[64];
    int ledValues_2_r[64];
    int ledValues_2_g[64];
    int ledValues_2_b[64];
    int ledValues_3_r[64];
    int ledValues_3_g[64];
    int ledValues_3_b[64];
    void setup() {
      strip.begin();; // Initialize all pixels to 'off'
      // Set all values in led holding arrays to an initial 0.
      for (int j = 0; j <= (numOfLeds-1); j++) {
        ledValues_1_r[j] = 0;
        ledValues_1_g[j] = 0;
        ledValues_1_b[j] = 0;
        ledValues_2_r[j] = 0;
        ledValues_2_g[j] = 0;
        ledValues_2_b[j] = 0;
        ledValues_3_r[j] = 0;
        ledValues_3_g[j] = 0;
        ledValues_3_b[j] = 0;
    // initialize some timing variables to count intervals.
    unsigned long currentMillis;
    unsigned long time;
    long previousMillis = 0;
    // Initializing some more timing and color variables.
    float trans_normalized;
    float previousStep = 0;
    int audioValue = 0;
    float currentOffset = 0;
    int r_led = 0;
    int g_led = 0;
    int b_led = 0;
    int rgbResult[3];
    // Method to convert HSV to RGB, and store the valeus in the array: "rgbResult"
    void getRGB(int hue, int sat, int val, int colors[3]) { 
      /* convert hue, saturation and brightness ( HSB/HSV ) to RGB
         The dim_curve is used only on brightness/value and on saturation (inverted).
         This looks the most natural.      
      val = dim_curve[val];
      sat = 255-dim_curve[255-sat];
      int r;
      int g;
      int b;
      int base;
      if (sat == 0) { // Acromatic color (gray). Hue doesn't mind.
      } else  { 
        base = ((255 - sat) * val)>>8;
        switch(hue/60) {
        case 0:
            r = val;
            g = (((val-base)*hue)/60)+base;
            b = base;
        case 1:
            r = (((val-base)*(60-(hue%60)))/60)+base;
            g = val;
            b = base;
        case 2:
            r = base;
            g = val;
            b = (((val-base)*(hue%60))/60)+base;
        case 3:
            r = base;
            g = (((val-base)*(60-(hue%60)))/60)+base;
            b = val;
        case 4:
            r = (((val-base)*(hue%60))/60)+base;
            g = base;
            b = val;
        case 5:
            r = val;
            g = base;
            b = (((val-base)*(60-(hue%60)))/60)+base;
    // Main Loop
    void loop() {
      // update current milis to current time.
      currentMillis = millis();
      // Get some analog values.
      pot_Speed_Val = analogRead(pot_Speed_Pin);
      pot_sensitivity_val = analogRead(pot_sensitivity_Pin);
      pot_Brightness_Val = analogRead(pot_Brightness_Pin);
      // Remap some stuff.
      pot_Speed_Val = map(pot_Speed_Val, 0, 1023, 1, 400);
      stepSize = pot_Speed_Val;
      pot_sensitivity_val = map(pot_sensitivity_val, 0, 1023, 64, 2048);
      micRemapMax = pot_sensitivity_val;
      pot_Brightness_Val2 = (float) pot_Brightness_Val;
      pot_Brightness_Val2 = ( (pot_Brightness_Val2 / 1023.0) * -1) + 1.0;
      // If enough time has passed, do the following.
      if ( (currentMillis - previousMillis) > stepSize) {
        // Read our envelope value from audioPin so that we can filter and use it.
        audioValue = analogRead(audioPin);
        // remapping it down from the raw input's range to a range that hue expects.
        audioValue = map(audioValue, 0, 1023, 0, micRemapMax);
        // Here we use a method we defined above to convert hsv to RGB for neoPixels
        getRGB(abs(((audioValue + hueOffset) % 360)), 255, valueGain, rgbResult);
        // Here we set the first item in ledvalue 1 to the direct result of our hsv to rgb method.
        // We do this because we dont have any earlier pixels in the chain to take the value from, there for it must come from the live audio source.
        ledValues_1_r[(numOfLeds-1)] = rgbResult[0];
        ledValues_1_g[(numOfLeds-1)] = rgbResult[1];
        ledValues_1_b[(numOfLeds-1)] = rgbResult[2];
        // ledValue 3 is basically a holding array that will hold our old led rgb pattern for tweening from, to the new pattern.
        // Here we are assigning the first item the direct result of the audio because it has no previous led's to take from.
        ledValues_3_r[(numOfLeds-1)] = rgbResult[0];
        ledValues_3_g[(numOfLeds-1)] = rgbResult[1];
        ledValues_3_b[(numOfLeds-1)] = rgbResult[2];  
        // Here we assign the rest of the items in our led arrays. Since the color information needs to "shift" down the chain, we use ledValues 3 to hold
        // the previous pattern, taken from ledValues 2. Then we take the newest pattern from ledValues 1 by referencing the same item + 1. effectively shifting
        // everything down one. Since we read the value of our audio input into the first array item, it will be propogated as well.
        for (int k = 0; k <= (numOfLeds-2); k++) {
          if (k < (numOfLeds)) {
            ledValues_3_r[k] = ledValues_2_r[k];
            ledValues_3_g[k] = ledValues_2_g[k];
            ledValues_3_b[k] = ledValues_2_b[k];
            ledValues_2_r[k] = ledValues_1_r[k+1];
            ledValues_2_g[k] = ledValues_1_g[k+1];
            ledValues_2_b[k] = ledValues_1_b[k+1];
          // Here we make sure we don't try and copy from an item that doesn't exist (total length of strip + 1) by using the above if statement.
          // When it fails, we know we ran out of existing array items and we just do a direct assignment instead of +1. While this is technically
          // incorrect it's the last one in the chain and wont really be noticeable..
          ledValues_1_r[k] = ledValues_2_r[k];
          ledValues_1_g[k] = ledValues_2_g[k];
          ledValues_1_b[k] = ledValues_2_b[k];
        // Here we update our interval timer, reseting it to the current time. When the difference beteween these two reach the specified max, the if statement
        // is trigered again, and the colors are shifted yet again. Tweening happens between these events and uses the same information.
        previousMillis = currentMillis;
      // Here we calculate the normalized 0-1 count down from when the pixels were just updated, to when they will be updated again.
      // We will use this value below to blend between before and next in realtime in timing with the actual shift.
      trans_normalized = ((previousMillis + (float) stepSize) - currentMillis) / (float) stepSize;
      // here we actually set the final rgb variables to set pixel colors with.
      for (int i = 0; i <= (numOfLeds-1); i++) {
        // By multiplying before by trans_normalized and next by (1 - trans_normalized) and adding the results we 
        // get a 1:1 brightness, a blend, or a cross fade if you will.
        r_led = (float) ( (int) ((((float) ledValues_3_r[i]) * trans_normalized) + (((float) ledValues_1_r[i]) * (1.0 - trans_normalized))) ) *  pot_Brightness_Val2;
        g_led = (float) ( (int) ((((float) ledValues_3_g[i]) * trans_normalized) + (((float) ledValues_1_g[i]) * (1.0 - trans_normalized))) ) *  pot_Brightness_Val2;
        b_led = (float) ( (int) ((((float) ledValues_3_b[i]) * trans_normalized) + (((float) ledValues_1_b[i]) * (1.0 - trans_normalized))) ) *  pot_Brightness_Val2;
        // The next 3 lines are a massively important safety precaution for running this setup soley from the USB. no matter what shenannigans goes on above, we must clamp our 
        // max brightness to a value deemed safe for the power suppy. For usb I am keeping it at a very low and safe value of 64 which provides decent range for testing.
        r_led = constrain( r_led, 0, maxBright);
        g_led = constrain( g_led, 0, maxBright);
        b_led = constrain( b_led, 0, maxBright);
        // Actually setting the strip led's their respective colors.
       strip.setPixelColor(i, r_led, g_led, b_led);
      // refresh the strip and show off that hard work, microcontroller!;

  2. #2
    Another thing I just noticed, with 1 power supply in particular the animation on the led starts and then freezes at about up the chain.

    The same same happens when I plug in the usb cable from my computer, however in that scenario the programming reboot button reboots the device and the animation starts and keeps going?

    Is teensy getting caught up because of lack of communication with my computer somehow?

  3. #3
    Senior Member Jp3141's Avatar
    Join Date
    Nov 2012
    do you have a voltmeter ? check at the Teensy that it is getting 5 V (it will work down to << 3 V though).

    How long are the wires between the 5 V external supply and the Teensy ?

  4. #4
    Thanks for the quick reply, probably 3-4 feet, same length as my usb cable.
    Infact, it's the detachable phone charging type (although I've tried with 1 other as well). The very same cable plugged into my computer works.

    Another thing I just noticed too is that when plugged into the pc, it does that freezing thing at 6 led's in, then it takes a moment, windows makes the device recognized / plugged in sound, and the bootloader auto restarts the teensy and the code runs fine after that...

  5. #5
    Confirmed about the voltage though:

    4.83 from laptop

    5.03 from wall adapter

  6. #6
    Well..... It just started working. I did absolutely nothing besides create a new sketch intended for debugging and had uploaded a few times, then went back to the code posted here and it worked from both usb and wall adapter.

    I am absolutely stumped as to why, I will keep this thread updated if I happen to find out why!


    False alarm, back to the same problem right after I submitted this. Now it gets stuck a few led's further, 12 or 16 down.


    So I threw in a simple "delay(10);" at the start of my void loop() and it runs both ways with that in there.

    It seemed stable, next I changed the delay to .25 and it worked at first, then it stopped working on my computer USB power and not the regular power.

    Then I play with the cpu clock options under tools, try 48, and then the situation flips and it works on pc usb and not wall usb?
    Last edited by visualSound; 03-28-2014 at 10:57 PM.

  7. #7
    Senior Member
    Join Date
    Jun 2013
    So. Calif
    My teensy 3's run OK on one of those L-ion batteries with a USB connector - normally used as backup for a smart phone's dead battery. To the Teensy, it looks like same 5V as from a USB port.

  8. #8
    This project has to run off of a dc converter connected to my car so trying get it happy with something I can stick in my cigarette lighter.


    Testing in my car results in even stranger results. it's getting 5.15 volts from the adapter there however the pattern appears randomly, and only a few led's light up and it's stuck that way until I replug it in, then another random set of a few led's light up.

    All the while the audio board's led is working fine..

    Any ideas? I'm totally stumped!
    Last edited by visualSound; 03-28-2014 at 11:16 PM. Reason: updated info

  9. #9
    Senior Member
    Join Date
    Jun 2013
    So. Calif
    Noise on the DC converter? Some some sort of flaky common ground?

  10. #10
    with the delay trick and keeping the clock speed at 48 seems to do the trick indoors, I'll have to investigate the car more, there is probably much more noise in that system thanks to the engine and whatever else might cause some.

    Do you mean flaky common ground in the car? or in my circuit?


    Sorry for the flood of posts, I keep noticing trends that I'm not sure are pertinent or not..

    The latest thing I've noticed:

    If I get it "working", it usually stays working. For example I get it working with on board usb, then switch over another usb cable that plugs into the computer, but plugs into a small usb break out board attached to my device (see above picture, only using the power connectors from it) it works, and I can unplug and plug it back in as many times as I want.

    THEN, if I plug that very same usb cable into a wall adapter, it just wont start.

    Now, if I switch back to a usb port on my computer it remains "broken" until I hit the restart button or re upload the code to the teensy.
    Last edited by visualSound; 03-29-2014 at 12:34 AM. Reason: more data / testing

  11. #11
    Senior Member Jp3141's Avatar
    Join Date
    Nov 2012
    If it is a power problem, perhaps limiting the maximum brightness (temporarily) would alleviate it ?

  12. #12
    It's a good thought, I have limited it through code, the very last color adjustment clamps the value no matter what it tries to be, between 0 and 64 which has been working very well via usb. I may try bringing that down to 32 and see how it does.

  13. #13
    Seems to not make a difference, the problem just feels intermittent right now. can't quite find a pattern.

    I've been switching between two different usb wal wart power supplies, and switching between the on board usb and the one I installed through an opening in the case.
    I've been plugging those into a couple different plugs and my computer. the plugs sometimes work, the usb ports always do although sometimes i have to hit the reset button, and the car usb chargers have not worked once, yet. Even with the engine off.

    Arrghhh I am sure I am missing something simple, I am rather new to micro controllers.

  14. #14
    Alright so another update (I'm determined to try and finish this project this weekend):

    I stumbled across this thread:

    Someone else seemed to be having similar intermittent problems. I tried the referenced library from Paul, didn't notice any difference really, but then I decided to try out the bare bones color example that came with it.

    That proved to seem much more stable across certain power supplies, and others nearly 100% unsuccessful which leads me to believe that maybe this is power supply related after all?

    1 walwart adapter worked flawlessly, the older one I had lying around did not work at all. the brightness was way higher in this test so Im thinking current draw had something to do with it.
    However, the adapter for my car is rated higher than anything else I have at 2.1 amps, and that one didn't work at all, ever, not once.

    I then dug up an older power inverter for the car, a much larger one that also outputted ac wall as well as dc usb, I was able to plug a small 1 amp charger square into the ac of THAT inverter, and then finally got solid results! Woo!

    I also just realized I was not using a 74HCT245 buffer chip anywhere, so I assume the voltage coming out of the teensy has been at 3.3v this whole time and the neoPixels need the signal to be closer to 5v, maybe this is the issue? I'm dancing dangerously close to the line with some of these adapters and others just barely cut it?

    Sorry for the spam fest, just trying to get this figured out and leave a trail for anyone else having trouble too.

  15. #15
    Still no stuck, but maybe it's not what I thought it was:
    I installed this logic level converter from sparkfun (please correct me if this was the wrong thing to use!):

    I followed this setup:
    but kept the teensy on the 3.3v side and the neopixels on the 5v etc.
    It turned out to not work at all. Even when I loaded strandTest, nothingness.

    So I took the logic level converter off.
    With it back off again, I loaded the standard blink, and the strandtest. BOTH work flawlessly, and immediately. When loaded, the teensy never has trouble being recognized by my laptop as a usb device either.

    However, when I load my code back on(above), it goes back to not being recognized as a usb device UNTIL I hit the rest button after plugging it in to the usb port.

    What gives? I'm totally out of ideas.

    Is the logic level board im using not the same thing as the 74HCT245 chip?
    Does the error I get when my code is loaded point towards an error in the code, rather than the setup?

    I'm pulling my hair out over this, any help would be greatly appreciated! I have a feeling I'm overlooking something ridiculous...

    Last edited by visualSound; 04-05-2014 at 02:18 AM. Reason: typo

  16. #16
    So I stripped down my code and started from scratch, reassembling my led code from bare bones and testing as I went...

    This is as big as my code got before I found out where the issue was occuring:

    #include <Adafruit_NeoPixel.h>
    #define PIN 2
    #define OTHERPIN 3
    Adafruit_NeoPixel strip = Adafruit_NeoPixel(64, PIN, NEO_GRB + NEO_KHZ800);
    Adafruit_NeoPixel otherStrip = Adafruit_NeoPixel(64, OTHERPIN, NEO_GRB + NEO_KHZ800);
    const int ledPin = 13;
    const int ledCount = 64;
    int ledValues_1_r[ledCount];
    int ledValues_1_g[ledCount];
    int ledValues_1_b[ledCount];
    int ledValues_2_r[ledCount];
    int ledValues_2_g[ledCount];
    int ledValues_2_b[ledCount];
    int ledValues_3_r[ledCount];
    int ledValues_3_g[ledCount];
    int ledValues_3_b[ledCount];
    // initialize some timing variables to count intervals.
    unsigned long currentMillis;
    unsigned long time;
    long previousMillis = 0;
    void setup() {
      strip.begin();; // Initialize all pixels to 'off'
      // Set all values in led holding arrays to an initial 0.
      for (int j = 0; j <= (ledCount-1); j++) {
        ledValues_1_r[j] = 0;
        ledValues_1_g[j] = 0;
        ledValues_1_b[j] = 0;
        ledValues_2_r[j] = 0;
        ledValues_2_g[j] = 0;
        ledValues_2_b[j] = 0;
        ledValues_3_r[j] = 0;
        ledValues_3_g[j] = 0;
        ledValues_3_b[j] = 0;
      pinMode(ledPin, OUTPUT);
    void loop() {
      currentMillis = millis();
      currentMillis = sin(currentMillis * .005) * 16 + 16;
      if(currentMillis > 6){
        digitalWrite(ledPin, HIGH);
        digitalWrite(ledPin, LOW);
      uint16_t i;
      for (i = 0; i<ledCount; i++) {
        strip.setPixelColor(i, (int) currentMillis, 0, 0);

    What it came down to was ";" at the end of my void loop.

    If I added a delay(4) in there it one line before it worked flawlessly on usb, and walwart and I can plug and unplug to my hearts content.
    Now if I drop that delay down to 3 micro seconds it is as intermittent as with out it at all.
    If I commented out the delay and the all the other computations ran fine and there was no crashing.

    One other thing did was throw the pin 13 blink led in there and tied it up to my sine wave as an indicator of the teensy freezing. That helped me see when it crashed vs when the led's were just not working ( I think it's been a code issue all along)
    Also to note, I am still not using any logic level converters or this time around. That might still pose issues too, but so far so good.

    I guess my next question would be why..
    Having that delay in this project wont make any noticeable difference so I'm probably going to leave it that way for now but it might cause noticeable flicker / lag in bigger projects.

    I'll keep this thread updated with my findings if anything new comes up!

  17. #17
    Also, I am still not having luck with 1 particular power supply but it and the rest that do work are acting consistent now and I think this is indeed an issue with the 3.3v to 5v.

    Click image for larger version. 

Name:	testingPowersupplies.jpg 
Views:	266 
Size:	62.5 KB 
ID:	1787

    1) my trusty cellphone charger walwart. after the code fix this guy worked solid.
    2) the device I ultimately want to power my project with due to it's small form factor and 2.1 amp max amp draw. Ironically this is the only one that still doesn't work BUT it is also putting out a higher voltage than the rest by a whole .2 volts which is beyond the threshold for the neopixels i believe..
    3) apple charger plugged into the bigger inverter's ac plug. (this now works flawlessly too.)
    4) the usb output on the same inverter, also works flawlessly.

    5) and of course my computer's usb port which never gave any voltage trouble that I could see.

    Going to throw the logic level chip back in and see if that solves the problem with #2.

  18. #18
    Junior Member
    Join Date
    Apr 2014
    it could be just a timing issue...i.e the .begin was before spi/i2c /serial device become stable after receiving power...i did add a little delay just after setup for them to stablize after power up before initiliazation starts

  19. #19
    Yep, it was a timing thing. I ended up asking about the logic level shifter I had vs the 74HCT245 HERE and got a pretty extensive explanation as to why the one I had couldn't work.

    I ordered some of the 74HCT245's for the next project and went with the mega I had lying around since it outputted 5v for this project.

    I'll post pictures soon of the end result.

  20. #20
    Junior Member
    Join Date
    Apr 2014
    I experienced the same problem, and as a complete noob to the Teensy I assumed that I just didn't understand the upload process.
    Thanks to this thread, I think I have the Teensy working stand-alone.
    I was having a problem where the Teensy would only work as long as Teensy Loader 1.18 was running. If I tried to run directly from a wall-wart, the design would never "boot up".
    Added a 500 millisecond delay as the first instruction in the 'setup' section and it seems to be working correctly.
    Maybe the processor in the LCD display that I am using needs some time to finish booting itself up before getting any data?
    In any case, 500ms delay (probably could be less) is irrelevant when I am just plugging in the power.

Tags for this Thread

Posting Permissions

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