FastLED freezing with prop shield

Status
Not open for further replies.

jgilbert

Member
I just received my prop shield with IMU and Teensy 3.2 and I've encountered a strange, repeatable hang using the FastLED library. I am using the "FirstLight" sketch with the examples provided by Paul on the main page to raise pin 7. When powered by USB, the whole teensy freezes after about 5 seconds. (Powered by a 3.7V lipo 2000mah, this freeze does not happen.) The only connections are the four leads to the APA102 array. Its a hard freeze - serial monitor, USB, etc all seem to hang. I am only driving 30 LEDs. Host is a MPB 15" with USB directly connected.

Things i have tried:

- Adding in transactions with SPI and varying the speed from 24000000 to others
- Changing teensy processor speed
- Resoldering the pins
- Different USB cables
- Forcing pins 5,6 LOW to take the memory chip out of the SPI bus
- Monitoring voltage on the strip with a voltmeter (its rock solid at 4.99V the whole time.)
- Completely reinstalling Arduino + teensyloader.

I cannot reproduce this with the Adafruit dotstar libraries, however they appear to be somewhat incompatable with some of the other things I want to eventually test attach to the prop shield. My project needs a speaker, rotary encoder, IMU, and some sort of LED display in addition to the APA102s. My experience when I wired all of this up originally was that using the adafruit library seemed to prevent the ssd1351 libraries from interfacing properly once i had the full project wired up, thus the use of FastLEd, and thus the discovery of a hang.

My concern is that i have a hardware problem I cannot identify, and thus I'm worried. I'm trying to integrate a few different things together in one project and its concerning to have a wildcard in the mix.

I am using a freshly installed 1.29 teensy installer.

Code:
#include <FastLED.h>
#include <SPI.h>

#define NUM_LEDS 30
CRGB leds[NUM_LEDS];

void setup() {

 Serial.begin(57600 );
  
  
  FastLED.addLeds<APA102, BGR>(leds, NUM_LEDS);
  FastLED.setBrightness(10);
  pinMode( 7, OUTPUT );
  digitalWrite( 7, LOW );

  pinMode( 6, OUTPUT );
  digitalWrite( 6, LOW );

    pinMode( 5, OUTPUT );
  digitalWrite( 5, LOW );

}

void loop() {
  // Move a single white led 
  for(int n = 0; n < NUM_LEDS; n++) {
    leds[n] = CRGB::White;

    // beginTransaction prevents SPI bus conflicts
    SPI.beginTransaction(SPISettings(24000000, MSBFIRST, SPI_MODE0));
    digitalWrite(7, HIGH);  // enable access to LEDs
    FastLED.show();
    digitalWrite(7, LOW);
    SPI.endTransaction();   // allow other libs to use SPI again

    delay(6);
    leds[n] = CRGB::Black;
  }

 Serial.println( millis() );
}
 
Hah, doesn't it figure that the very next thing I tried seemed to fix part of the problem?

I downloaded a fresh copy of FastLED and forced to checkout b01f941.

Problem resolves.

Still very strange about the USB vs. LiPo. DO I have anything to worry about in terms of hardware?
 
Thanks!

I was experiencing the same issue and using the FastLedV3.1.0 b01f941 solved it.

Related to the older version of the FastLed.h the Arduino compiler errors when functions are at the bottom of the sketch "functions not declared error".. so you have to move all the functions to the top of the sketch... per this comment.
 
Has anyone found a better work around than b01f941? That version does not lock up but corrupts my strip after about 50 pixels.
 
This was my solution....

...Here's the link to the other post.

In order to run the LEDs without flickering I had to upload the LEDs running the teensy at 16MHz (no USB), and then I could run the APA102 at 12MHz.
I'm running four strands of about ~600 LEDs.
Code:
Code:
FastLED.addLeds<APA102, DATA_PIN1, CLOCK_PIN1, BGR, DATA_RATE_MHZ(12)>(colors1, LED_COUNT);
If I ran the teensy at 96MHz then almost the entire strip of LEDs would flicker no matter the led DATA_RATE.
If I tried to run the teensy at say 48MHz, I could run the APA102 at 1MHz and there would be almost no flicker but the response time was slow. It didn't seem to matter if I ran them combined SPI pins (as my initial post) or ran them as forced software SPI via an unmutilated octo-shield.
 
The fix that has worked for me (and at least one other) so far has been to use the mainline FastLED but undo fe32cf1, "attempt a fix for #339 - guard waitfully against a race condition".
 
Status
Not open for further replies.
Back
Top