Teensy 3.1 only runs code on upload

Status
Not open for further replies.

Sinomat

Member
I've had a bit of a snoop around the forums and found a couple of things that looked like this problem but no solution that worked for me.

I've got a Teensy 3.1 driving 7 x 42 RGB LED strips. I've cut the pads so the Teensy has decoupled USB from Vin. If I upload code from Teensyduino/Teensy Loader then it runs just peachy. If I just power up the device on external power than it seems to begin running code and then hangs very shortly thereafter.

It's getting power fine. It's happened with numerous sketches. I suppose FastLED might be a common factor. I tried the delay(4) at the beginning of setup. I've tried 48MHz instead of 96 but that doesn't seem to work at all, possible timing related and FastLED.

Anyone got any clues?
 
Does it hang or do the LEDs stop processing updates? I've found that if voltage drifts above 5v (e.g. 5.2 or above), that WS2812 strips start having problems w/the teensy's 3.3v signals and stop processing updates. While I'm poking at moving to level shifters for projects going forward where I can't ensure a 5v peak, i've done things to pull my voltage down (e.g. running my 5.25v output'ing "5v" power supply through a 3amp dc/dc buck converter from adafruit that ends up pulling it down to about 4.7/4.8v).
 
'ello again!

After a bit more digging... it didn't seem worthwhile posting massive loads of code and electrically there's clearly nothing wrong, I worked back towards a minimal LED flashing sketch (to show the Teensy is still running) and added more until the problem manifested. It was indeed the Teensy seizing up and not just a failure to run the leds.

That said it WAS FastLED 2.1 related. Removing this and the problem goes away. I updated my 2.1 branch to the beta and things got worse, I had two bad lines on my display. After further investigation it turns out:

It would seem that not only should you avoid delay() with FastLED 2.1 but it actually breaks stuff badly if you do and it doesn't matter if you turn of temporal dithering. Ranging from lines of leds completely freaking out all the way to the obscure and frustrating failure of the Teensy to boot the sketch on power up (external power).

Replacing delay() with FastLED.delay() and it cured both problems.

It gets weirder still. Based on some comments in an earlier thread, delay(4); as the very first thing in void setup() was suggested. Well, if I have delay(4) there, the top two strips fail to work. If I remove it, or change it to FastLED.delay(4) then all is well. This is BEFORE FastLED.AddLeds blah blah. Below is minimal code;

Code:
#include "FastLED.h"

#define TEENSYLEDPIN 13
#define NUM_ROWS 7
#define NUM_LEDS 42
#define LED_PIN1 22
#define LED_PIN2 21
#define LED_PIN3 20
#define LED_PIN4 19
#define LED_PIN5 18
#define LED_PIN6 17
#define LED_PIN7 16

CRGB leds[NUM_ROWS][NUM_LEDS];

void setup() {
    delay(4); // COMMENT THIS OUT AND THE FIRST TWO STRIPS WORK, OTHERWISE THEY'RE HOSED!
    Serial.begin(115200);
    FastLED.addLeds<NEOPIXEL, LED_PIN1>(leds[0], NUM_LEDS);
    FastLED.addLeds<NEOPIXEL, LED_PIN2>(leds[1], NUM_LEDS);
    FastLED.addLeds<NEOPIXEL, LED_PIN3>(leds[2], NUM_LEDS);
    FastLED.addLeds<NEOPIXEL, LED_PIN4>(leds[3], NUM_LEDS);
    FastLED.addLeds<NEOPIXEL, LED_PIN5>(leds[4], NUM_LEDS);
    FastLED.addLeds<NEOPIXEL, LED_PIN6>(leds[5], NUM_LEDS);
    FastLED.addLeds<NEOPIXEL, LED_PIN7>(leds[6], NUM_LEDS);
    pinMode(TEENSYLEDPIN, OUTPUT);
    // do a power up colour fade
    for (int h=0;h<256;h++) {
        for (int row=0;row<NUM_ROWS;row++) {
            for (int l=0;l<NUM_LEDS;l++) {
                leds[row][l].setHSV(h,255,64);
            }
        }  
        FastLED.show();
        FastLED.delay(1);
    }
}

void loop() {
    ... doesn't matter what's here
}
 
Hmm, removing the delay doesn't entirely cure the failure to run from cold start problem. Removing the power up colour fade code above seems to though. I really have no idea what's going on here but I'm happy it's working at least :)
 
Your setup loop should only have setup code in it - the rest of that code should be in loop, I wouldn't be shocked if that was interfering with things, though I'd have to dig into why.

FastLED.delay simply calls show and delay alternately behind the scenes to drive the dithering algorithm, so you were still calling delay, indirectly. Also, 280 LEDs at quarter brightness is going to have some power draw - what kind of power supply are you running on this stuff?
 
It's got a 20A power supply. It can drive all of them full on white. The leds aren't screwing up, the Teensy is hanging. I've gone back to some alternative visualisations and I've got the two-dead-line problems which I didn't have on the earlier 2.1, and it's not delay related. Teensy seizes up after about 60ms.
 
So, outside of the timing problems at 24/48Mhz (which i'm looking into) - when I run the code that you've pasted above, it runs through all the output in loop - no hanging anywhere, no matter whether or not i have any calls to delay, or delay vs. FastLED.delay.

At 48Mhz and 96Mhz, it runs and exits setup (I added a Serial.println at the end of setup to confirm that it's getting to the end), and I can upload new code. At 24Mhz, it also runs and exits setup, but then I need to use the reset button to upload new code.

Now, here's something fun - so, at 24Mhz, I get the leds showing an all on pattern, and get stuck there (because there output timing is off, that's fine - i'm working on tackling that separately) - and I have a loop running a regular activity print out. If I unplug power from the leds, but not from the teensy 3.1, I sometimes (not always, but often enough), will see the teensy 3.1 hang, I suspect it is because with the lack of power coming over the power line, the leds are attempting to pull power over the data line and something throws internally. Re-applying power does not bring the teensy out of its hung state.
 
It doesn't hang at all for you? Well well. It hangs for me even if I pull the chip from it's socket on the board and power up with a bench power supply with nothing else attached.

I've confused the issue by conflating the hanging issue with several problems I had with the new FastLED 2.1 beta.

Pretty much all of my visualisation code simply wont start on the Teensy if I just switch the PSU on. Except for the barest minimal code but even that's sensitive as shown here.
 
I've had a bit of a snoop around the forums and found a couple of things that looked like this problem but no solution that worked for me.

I've got a Teensy 3.1 driving 7 x 42 RGB LED strips. I've cut the pads so the Teensy has decoupled USB from Vin. If I upload code from Teensyduino/Teensy Loader then it runs just peachy. If I just power up the device on external power than it seems to begin running code and then hangs very shortly thereafter.

It's getting power fine. It's happened with numerous sketches. I suppose FastLED might be a common factor. I tried the delay(4) at the beginning of setup. I've tried 48MHz instead of 96 but that doesn't seem to work at all, possible timing related and FastLED.

Anyone got any clues?

I am having the exact same problem. Has anyone made any progress on this?? It seems like this whole thing used to work until recently, though I have added a lot of code since then. FWIW, I have not updated my FastLED2_1 library since July 3 and based on the content of the thread I am loathe to try updating at this point as that just adds another variable to the situation.

As far as I can tell, after cycling power, the setup routine runs, and I can also confirm that it starts to run the loop, at least. Also, if it ends up hanging (which is the majority of the time, I can sometimes start it up by hitting the reset button on the board. However, even if this worked 100% of the time (which it does not), this is unacceptable in my application.

Please let me know if anyone has something to offer here. I'm very frustrated at this point, and it would totally suck if I cannot get this to work reliably.

Thanks in advance for any help you can offer.

= Ed =
 
Last edited:
The wiring is pretty simple, besides power and ground, I have the LED data out attached to pin 11, and I have a touch sensitive plate (about 10 inches of 22 gauge wire soldered to s 2 inch diameter copper foil disc) attached to pin 23. Power comes from a wall art supply that supplies 5.1 volts as measured by my VOHM. There is quite a bit of code that I will list below. There is one oddity in the code in that in order to use the touchRead() function, I had to make the calls from the Sketch, and not the library I ws writing. I got an error trying to call touchRead from the library code. My debounce stuff is pretty primitive, but it all seems to work.

Here is the link to the LED strip I'm using: http://www.lightingnext.com/1m-96-ws2812b-neopixel-strip.html

There is a good bit of code here, even though I'm just prototyping with it now.
Here is the Sketch code:

Code:
#include "FastLED.h"
#include <dot.h>
#include <dbswitch.h>

// How many leds in your strip?
#define NUM_LEDS 96
#define NUM_SPOTS 32

// For led chips like Neopixels, which have a data line, ground, and power, you just
// need to define DATA_PIN.  For led chipsets that are SPI based (four wires - data, clock,
// ground, and power), like the LPD8806 define both DATA_PIN and CLOCK_PIN
#define DATA_PIN 11
#define CLOCK_PIN 12
#define NUM_SPOTS 32
#define DELAY_TIME 30
#define VALUE_THRESHHOLD 2000
#define BOUNCE_TIME 150
#define NUM_EFFECTS 2

DBSwitch::DBSwitch( unsigned char pinNum, int delayTime )
{
	pin = pinNum;
	lastRead = touchRead( pin ) > VALUE_THRESHHOLD;
	lastRead = state;
	count = 0;
        leadingEdge = 0;
        trailingEdge = 0;
	if ( delayTime >= BOUNCE_TIME )
		bounceThreshhold = 2;
	else
		bounceThreshhold = ( delayTime + BOUNCE_TIME - 1 ) / BOUNCE_TIME;
}

void DBSwitch::Update( void )
{
	unsigned char value = touchRead( pin ) > VALUE_THRESHHOLD;    // convert to a digital signal
	if ( value == lastRead )                                                          // if input has NOT changed since last update
	{
		if ( lastRead == state )                                                   // ignore if the state is the same - clear leading & trailing edges 
                {
			leadingEdge = 0;
                        trailingEdge = 0;
                }
		else if ( ++count > bounceThreshhold )                                     // if this is a valid change in state.  Count in any event
		{
			state = lastRead;
			count = 0;
                        leadingEdge = state;
                        trailingEdge = state == 0;
		}
	}
	else                                      // input value changed since last update.  start counting
	{
		lastRead = value;
		count = 0;
	}
}

unsigned char DBSwitch::State( void )
{
	return state;
}

unsigned char DBSwitch::LeadingEdge( void )
{
	return leadingEdge;
}

unsigned char DBSwitch::TrailingEdge( void )
{
	return trailingEdge;
}


// Define the array of leds
CRGB leds[NUM_LEDS];
LEDDot dotString[ NUM_SPOTS ];		// these represent physical dots
Spot redSpot;
Spot pulseVioletSpot;
Spot pulseGreenSpot;
DBSwitch touchSwitch( 23, DELAY_TIME );
int effect = 0;

void setup()
{
    pinMode( 13, OUTPUT );
      // Uncomment/edit one of the following lines for your leds arrangement.
      // FastLED.addLeds<TM1803, DATA_PIN, RGB>(leds, NUM_LEDS);
      // FastLED.addLeds<TM1804, DATA_PIN, RGB>(leds, NUM_LEDS);
      // FastLED.addLeds<TM1809, DATA_PIN, RGB>(leds, NUM_LEDS);
      // FastLED.addLeds<WS2811, DATA_PIN, RGB>(leds, NUM_LEDS);
      // FastLED.addLeds<WS2812, DATA_PIN, RGB>(leds, NUM_LEDS);
      // FastLED.addLeds<WS2812B, DATA_PIN, RGB>(leds, NUM_LEDS);
  	  FastLED.addLeds<NEOPIXEL, DATA_PIN>(leds, NUM_LEDS);
      // FastLED.addLeds<UCS1903, DATA_PIN, RGB>(leds, NUM_LEDS);
      // FastLED.addLeds<UCS1903B, DATA_PIN, RGB>(leds, NUM_LEDS);
      // FastLED.addLeds<GW6205, DATA_PIN, RGB>(leds, NUM_LEDS);
      // FastLED.addLeds<GW6205_400, DATA_PIN, RGB>(leds, NUM_LEDS);
      
      // FastLED.addLeds<WS2801, RGB>(leds, NUM_LEDS);
      // FastLED.addLeds<SM16716, RGB>(leds, NUM_LEDS);
      // FastLED.addLeds<LPD8806, RGB>(leds, NUM_LEDS);

      // FastLED.addLeds<WS2801, DATA_PIN, CLOCK_PIN, RGB>(leds, NUM_LEDS);
      // FastLED.addLeds<SM16716, DATA_PIN, CLOCK_PIN, RGB>(leds, NUM_LEDS);
      // FastLED.addLeds<LPD8806, DATA_PIN, CLOCK_PIN, RGB>(leds, NUM_LEDS);
      
  CRGB dimViolet = CRGB( 8, 0, 8 );
 
 // initialize the LEDs that are in use 
  for( int i = 0; i < NUM_SPOTS; ++i )
  {
    dotString[i].clear();
    dotString[i].setBaseColor( dimViolet );
    dotString[i].reset();
  }

// initialize our virtual spots (sections)
  redSpot.Init( 9.0, 0.0, 0.20, CRGB::DarkRed );  
  pulseVioletSpot.Init( 12.0, 16.0, 1.0/30.0, CRGB( 32, 0 , 28 ) );
  pulseGreenSpot.Init( 48.0, 16.0, 1.0/30.0, CRGB::DarkGreen );
}

void loop()
{
    digitalWrite( 13, HIGH );                                                // prove that we get to the loop at least once
    for ( unsigned char i = 0; i < NUM_SPOTS; ++i )
    {
      switch( effect )                                                      // allow the user to switch effects
      {
        case 0:
  	pulseVioletSpot.PopulateDot( dotString[i], i, (bool)true );		// affect this physical dot with the pusling violet Spot
  	redSpot.PopulateDot( dotString[i], i, (bool)false );			// affect this physical dot with the red Spot
          break;
          
        case 1:
   	pulseGreenSpot.PopulateDot( dotString[i], i, (bool)true );		// affect this physical dot with the green Spot
          break;
      }
      leds[i] = dotString[i].c;                                                // output to the LEDs
    }
    
    FastLED.show();
    FastLED.delay( DELAY_TIME );
  
    if ( touchSwitch.LeadingEdge() )                                        // change effects
    {
      if ( ++effect >= NUM_EFFECTS )
        effect = 0;
    }

    // update the position/color/size of the Spots
    pulseVioletSpot.Pulse(); 
    pulseGreenSpot.Pulse();
    redSpot.Update( NUM_SPOTS );
  
    // update the switch state
    touchSwitch.Update();

}

Here is the header file for the DBSwitch class:
Code:
#ifndef _DBSWITCH_H_INCLUDED_
#define _DBSWITCH_H_INCLUDED_

#include "lib8tion.h"

class DBSwitch
{
private:
	unsigned char	state;			// the current state of the switch input
	unsigned char	lastRead;		// last read value
	unsigned int	count;			// how long have we been at this count
	unsigned char	pin;			// which pin are we reading
	unsigned int	bounceThreshhold;	// how long do we need to effect a change in state
	unsigned char	leadingEdge;	// true if leading edge detected
	unsigned char	trailingEdge;	// true if trailing edge detected

public:
	DBSwitch( unsigned char pinNum, int delayTime );
	void Update( void );			// 
	unsigned char State( void );
	unsigned char LeadingEdge( void );
	unsigned char TrailingEdge( void );
};
#endif

Here is the header file for my LEDDot and Spot classes:
Code:
#ifndef _LEDDOT_H_INCLUDED_
#define _LEDDOT_H_INCLUDED_

#include "lib8tion.h"
#include "FASTLED.h"

// dotData is a generic data field that can be used for multiple purposes
union dotData
{
public:
	unsigned long l;
	unsigned short s[2];
	unsigned char c[4];
	float f;
};

class LEDDot
{
public:
	CRGB c;					// current color of our LED
	CRGB baseColor;			// base color of our LED
	dotData d;

public:
	LEDDot();
	LEDDot( CRGB currentColor, CRGB base, long data = 0 );
	LEDDot( CRGB currentColor, CRGB base, short* data );
	LEDDot( CRGB currentColor, CRGB base, char* data );
	LEDDot( CRGB currentColor, CRGB base, float data );

	void setBaseColor( CRGB base );
	void blendWithBase( CRGB inputColor, fract8 percentage = 0x80 );
	void setCurrentColor( CRGB newColor );
	void blendToCurrentColor( CRGB inputColor, fract8 percentage = 0x80 );
	void reset( void );
	void clear( void );
	CRGB getBaseColor( void );
	CRGB getCurrentColor( void );
};

class Spot
{
public:
	CRGB spotColor;			// color of this virtual spot
	CRGB refColor;			
	float position;
	float speed;			// speed of motion/pulsing/effect
	float size;				// home many LEDs does this virtual spot cover
	float dir;				// what direction is it moving
	float data;
	
	void Init( float sSize, float pos, float sSpeed, CRGB col );
	void PopulateDot( LEDDot& dot, unsigned char index, bool first );
	void Update( unsigned char stringLength );
	void Pulse( void );
};
#endif

And here is the code for the LEDDot and Spot classes:
Code:
/*
 * dot.cpp
 *
 *  Created on: Jun 25, 2014
 *      Author: edwardrotberg
 */
#include "dot.h"

LEDDot::LEDDot()
{
	clear();
};

LEDDot::LEDDot( CRGB currentColor, CRGB base, long data)
{
	c = currentColor;
	baseColor = base;
	d.l = data;
};

LEDDot::LEDDot( CRGB currentColor, CRGB base, short* data )
{
	c = currentColor;
	baseColor = base;
	d.s[0] = data[0];
	d.s[1] = data[1];
};

LEDDot::LEDDot( CRGB currentColor, CRGB base, char* data )
{
	c = currentColor;
	baseColor = base;
	d.c[0] = data[0];
	d.c[1] = data[1];
	d.c[2] = data[2];
	d.c[3] = data[3];
};

LEDDot::LEDDot( CRGB currentColor, CRGB base, float data )
{
	c = currentColor;
	baseColor = base;
	d.f = data;
};

void LEDDot::setBaseColor( CRGB base )
{
	baseColor = base;
};

void LEDDot::blendWithBase( CRGB inputColor, fract8 percentage )
{
	fract8 basePercent = 0xFF - percentage;
	c = (inputColor % percentage) + (baseColor % basePercent);
};

void LEDDot::setCurrentColor( CRGB newColor )
{
	c = newColor;
};

void LEDDot::blendToCurrentColor( CRGB inputColor, fract8 percentage )
{
	c %= 0xFF - percentage;
	c += (inputColor % percentage);
};

void LEDDot::reset( void )
{
	c = baseColor;
};

void LEDDot::clear( void )
{
	c = 0;
	baseColor = c;
	d.l = 0;
}

CRGB LEDDot::getBaseColor( void )
{
	return baseColor;
};

CRGB LEDDot::getCurrentColor( void )
{
	return c;
};

//////////////////////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////////////////////////////////////////////////////


void Spot::Init( float sSize, float pos, float sSpeed, CRGB col )
{
	spotColor = col;
	refColor = col;
	size = sSize;
	speed = sSpeed;
	position = pos;
	dir = 1.0;
	data = 0;
}

void Spot::PopulateDot( LEDDot& dot, unsigned char index, bool first )
{
	float halfSize = size / 2.0;
	float value = position - (float)index;		// how far is this dot from the index
	if ( value < 0 )
		value = -value;
//	Serial.println( halfSize );
//	Serial.println( value );
//	Serial.println( index );
	if ( value < halfSize )								// we can affect this LEDDot
	{
//		Serial.println ( "yes" );
		float fpercent = 1.0 - value / halfSize;
		fract8 percent = (fract8)(255.0 * fpercent);
		if ( first == true )
			dot.blendWithBase( spotColor, percent );
		else
			dot.blendToCurrentColor( spotColor, percent );
	}
	else if ( first )									// reset to base color
	{
//		Serial.println ( "no" );
		dot.reset();
	}
//	Serial.println ( refColor.r );
//	Serial.println ( refColor.g );
//	Serial.println ( refColor.b );
//	Serial.println ( "" );
}

void Spot::Update( unsigned char stringLength )
{
	position += dir * speed;
	if ( position >= stringLength - 1.0 )
	{
		position = stringLength - 1.0;
		dir = -1.0;
	}
	else if ( position < 0 )
	{
		position = 0;
		dir = 1.0;
	}
}

void Spot::Pulse( void )
{
	spotColor = refColor;
	fract8 percent = (fract8)(255.0 * data);
	spotColor %= percent;			// note this is equivalent to scaling by a percent
	data += dir * speed;
	if ( data < 0.5 )
	{
		data = 0.5;
		dir = 1.0;
	}
	else if ( data > 1.0 )
	{
		data = 1.0;
		dir = -1.0;
	}
}
 
Last edited:
Daniel Garcia recommended changing the FastLED.delay() to a simple delay(). I tried that and the results are very interesting. The flickering I had been seeing comes back, which I expected, but it starts properly MUCH more reliably. With FastLED.delay() it would only run correctly after a power cycle about 1 in 10 times. Now it seems to run correctly about 6 out of 7 times. I'd still like to get the reliability up to 100%.

Also, can someone tell me if there is a way that I can #include something to be able to call touchRead() from my library? I hate having that class code sitting in the main sketch file itself.

Thanks in advance,

= Ed =
 
OK, so I did quite a bit more experimentation and I figured out a bunch of stuff - hopefully there will be enough information here to enlighten someone with a deeper understanding as to the inner workings of FastLED2.1 and the Teensy3.1 board.

As I mentioned in the post just above, if I switch to using the Arduino delay() function rather than the FastLED.delay() function, the reliability goes up dramatically. However it still occasionally will hang. Also, if you look at the code I posted, I define NUM_LEDS to be 96. That's because the strip I'm using has 96 LEDs on it. I also define NUM_SPOTS to be 32. This is because I am only using 32 of the LEDs at this point and I wanted the other to be black. Eventually I will cut the strip when I determine the exact length it needs to be, but it (fortunately) won't be 96 LEDs and 32 is probably about as long as I expect the final version to be.

In any event, if I change NUM_LEDS to 32 and, with the change to use delay() instead of FastLED.delay() in place, I can cycle power repeatedly without it hanging. Of course all of the LED's beyond the first 32 are bright blue instead of black, but that's OK as eventually they will be cut off. I can even set NUM_LEDS to 48 and it works reliably as far as I am able to tell (~30-35 power cycles). I also tried NUM_LEDS set to 95 as sort of an edge case test, but that will fail about as often as setting it to 96.

So it appears that the code I have written can only reliably handle a smaller number of LEDs. It may be because I'm doing some processor intensive (for an ARM) stuff right now. I currently do a very small amount floating point that I may try changing to fixed point soon, and that would only be done to get to the bottom of this by optimizing my code to see if it alleviates the problem at all. In any event, I don't think the failure mode should be to hang. And again, the only reason I would consider doing the rewrite/optimization to not use floating point multiplication would be to test this theory, as my actual use will have a small enough strip to run reliably with the code I have in place now.

Hopefully, this will give one of you enough information to figure out what is actually happening to cause the loop to hang. Please post back here if you do figure something out, as I'd like to understand this better.

= Ed =
 
Last edited:
(filling in here from the g+ discussion in case people are following here)

The flickering is caused by having dithering enabled at low frame rates (you're running ~30fps)

The bug in FastLED.delay is likely something to do with how i'm attempting to compensate timing from having disabled interrupts - it's on my next list of things to look at.

The problem with number of leds may actually be a power problem. It's rare for there to be a code problem with number of leds unless you're running out of memory (and you'd have to get up into the thousands of leds before you had to start worrying about that on a teensy 3.1 - I've run well over a thousand leds w/FastLED off of a teensy 3.1 with no problems, but I also use a 10A power supply :). It's quite common for power to be an issue, however. What kind of power supply do you have it hooked up here - your photos made it look like you were pulling power/ground over usb, which is going to cap you at somewhere between 500mA and 2A.
 
(filling in here from the g+ discussion in case people are following here)

The flickering is caused by having dithering enabled at low frame rates (you're running ~30fps)

The bug in FastLED.delay is likely something to do with how i'm attempting to compensate timing from having disabled interrupts - it's on my next list of things to look at.

The problem with number of leds may actually be a power problem. It's rare for there to be a code problem with number of leds unless you're running out of memory (and you'd have to get up into the thousands of leds before you had to start worrying about that on a teensy 3.1 - I've run well over a thousand leds w/FastLED off of a teensy 3.1 with no problems, but I also use a 10A power supply :). It's quite common for power to be an issue, however. What kind of power supply do you have it hooked up here - your photos made it look like you were pulling power/ground over usb, which is going to cap you at somewhere between 500mA and 2A.

I'm not pulling power from the USB, but a wall-wart type of power supply, however it's rated at 5V 2A. I expect to eventually run off of batteries -- A rechargeable quad-AAA pack that should give me 4.8V.
 
I've been having trouble with USB cables. Mostly micro USB connectors.
Most such cables have wire gauges seemingly too small to avoid a serious IR drop at 1A. Maybe even at 0.5A.
Of about 8 assorted such cables I went through, only one was acceptable. Even the short ones were a problem.
I'm getting one of these...
https://www.adafruit.com/products/1549
as it has serial output of detail, as well as LEDs that, I expect, would show when there's too much IR drop in the cable and the load wants 0.5 or more amps.

And searching for USB micro cables with wire gauge of 24AWG or better. Adafruit had one.
 
Last edited:
If you have 96 LEDs and they all turn on fully white, each can draw approx 50 mA, for a total of about 4.8 amps.

A mere 2 amp rated power supply probably isn't enough for so many LEDs.
 
We've seen so many issues related to insufficient power. Would it save forum time to add power monitoring to the LED library? The LED management library could take some extra parameters defining the power supply capacity and the current requirements of the LEDs. If the application attempted to turn on too many lights, the library could display an error pattern instead. A really slick version could use the brownout detection circuitry built in to the Kinetis.
 
pictographer - the other person I work on the FastLED library with has been working on basically that type of system (basic rough numbers for per-led consumption) where you give it the max amperage you want to use, and it will automatically scale the brightness down behind the scenes for you if you exceed the power requirement.
 
Paul,

I have 96 LEDs. but I turn 64 of them off (i.e. black). I never tried to drive more than 32 LEDs which should be only about 1.6 amps at full white. Still, it turns out that using a better power supply is always a good idea.

= Ed =
 
This may be a dumb question, but have you tried using the NeoPixel or OctoWS2811 library, just to see if Teensy starts up properly and makes the LEDs light when using other software?

NeoPixel has a stand test example that should require only setting a single pin number, and off you go. Even if you never intend to actually use Adafruit's library, at least it could help to figure out if you have a hardware or software problem.
 
This may be a dumb question, but have you tried using the NeoPixel or OctoWS2811 library, just to see if Teensy starts up properly and makes the LEDs light when using other software?

I was using NeoPixel prior to moving to FastLED, the issue was present at least with that one as far as I can remember. I don't know if it was better since I didn't use it for long. Just to confirm other comments here, the issue is not that setup runs and the loop doesn't. This can happen but sometimes the loop runs a bit before locking up. Power supply has been eliminated from the equation. I paired the code down to a fairly minimal example which still did it.

I've tried quite a lot of things to try fix this. I was even prepared to enact some sort of workaround using reset but then this isn't really accessible on the board. Realistically, FastLED is less replaceable than Teensy given how much work has gone into the library. Ah well.
 
Had a similar problem: when i uploaded the code everything went fine. When i disonnected power supply and reconnected (no matter if it was usb or vin) the sketch did not work until i commented FastLED.show () out. I later fixed it by addind delay (1000) to the setup. So far it seems stable and even fixed the problem that i was unable to run it anywhere beyond 48MHz. So now i am running on 72 MHz with usb and external power supply.
 
Status
Not open for further replies.
Back
Top