Error with simple change in code. Maybe SRAM ?

Hi everyone !
I’m working on a project involving neopixel LED strings (19 in my project) with the Adafruit neopixel library.
Those leds are driven by an Attiny45 “Arduino formated”.

The following code is working fine. The LEDS are lighting up the way they should :

#include <Adafruit_NeoPixel.h>
#ifdef __AVR__
  #include <avr/power.h>

#define PIN 2     //corespond à la pin physique 7 de l'ATTINY 45 signal des LED
#define nbLED 19  // nombre de LED sur la bande
#define modeBt 0  // correspond à la pin 5 de l'Attiny45 bouton de changement de mode
#define modeMax 1 //nombre de modes d'éclairage
#define tiltBt 1 // correspond à la pin 6 de l'Attiny45 bouton tilt

// Parameter 1 = number of pixels in strip
// Parameter 2 = Arduino pin number (most are valid)
// Parameter 3 = pixel type flags, add together as needed:
//   NEO_KHZ800  800 KHz bitstream (most NeoPixel products w/WS2812 LEDs)
//   NEO_KHZ400  400 KHz (classic 'v1' (not v2) FLORA pixels, WS2811 drivers)
//   NEO_GRB     Pixels are wired for GRB bitstream (most NeoPixel products)
//   NEO_RGB     Pixels are wired for RGB bitstream (v1 FLORA pixels, not v2)
Adafruit_NeoPixel strip = Adafruit_NeoPixel(nbLED, PIN, NEO_GRB + NEO_KHZ800);

// IMPORTANT: To reduce NeoPixel burnout risk, add 1000 uF capacitor across
// pixel power leads, add 300 - 500 Ohm resistor on first pixel's data input
// and minimize distance between Arduino and first pixel.  Avoid connecting
// on a live circuit...if you must, connect GND first.

int way = 1;
int mode = 0;
int posit = 0;

//Extinction de tous les pixels
void noPixel(){
  for (byte i= 0; i<nbLED ; i++){


//L pixels aléatoires qui clignotent couleur aléatoire
void randomL(byte L){
  for (byte i=0; i<L; i++){

//5 pixel in a row

void fiveString(int place, int a, int b, int c){
  for (int j=0; j <5; j++){
    strip.setPixelColor((place+j), a, b, c);


void setup() {




void loop(){
fiveString(posit, random(256), random(256), random(256));
/*if (way == 1){

THe diffrent functions I wrote (noPixel(), randomL(), fiveString() ) are used to light the LEDS in various ways. THey seem to work fine.

The problem is in the loop :

Strangely, if I uncomment these final lines :

/*if (way == 1){

something wrong happens :

  • I can compile with no error,
  • I can upload the code on the Attiny,
  • but none of the code executes (the first lines of the loop before the “if” should light a series of LED, but nothing happens)

Stranger : If I replace the condition “way == 1” by just “1”, the code executes fine…

I find it very strange that the use of a variable that has precedently be declared, brakes it all…
I tried to change the types of the variables (int and byte) but the problem remains.
I tried to change the name of the variable, but the problem remain.

Any idea on this strange behavior ? Am I missing something obvious ?

Thank you all

I can upload the code on the Attiny,

Is that maybe a clue?

Is that maybe a clue?

Well... It uploads just normally... What would be the clue ?

The clue that you don’t have much RAM

Okay, so the problem should be SRAM. Thanks.

When compiling, I have a message that says :"Les variables globales utilisent 51 octets de mémoire dynamique." wich means "global variables use 51 bytes of dynamic momory".

I suppose that the 251 bytes of SRAM left are used by the main program. Is there a simple way to reduce the SRAM used by the program ?

(And by the way, thanks for you'r replies :slight_smile: )

I don't know; I don't have that library (which could be using heap) and I don't have any projects on that processor

I suppose that the 251 bytes of SRAM left are used by the main program. Is there a simple way to reduce the SRAM used by the program ?

Where do you get 251 from? 256 -51 = 205 :wink:

Looking at the library it (dynamically) allocates 3 or 4 times the number of leds that you specify (check the function updateLength() in the cpp file) when you create the strip variable. That is at least 57 (and possibly 76 bytes) in your case.

You will never see them in the compiler output as this allocation is done at runtime and not at compile time.

You can try to change your own functions to inline functions; it will save you a few SRAM bytes (program counter does not have to be pushed on the stack) at the expense of code memory.

But I think that you’re skating on very thing ice and an upgrade to an ATtiny85 might be advisable.