Hoping someone can help with a very mysterious CRGBPalette16 problem recently reported on the

Archive FastLED Archive
,
1

Hoping someone can help with a very mysterious CRGBPalette16 problem recently reported on the PJRC forum.

When run on Teensy LC, this program crashes. Merely commenting out the CRGBPalette16 line, or the unused object instance using it allows the program to run. Is it possible something with the CRGBPalette16 assignment operator could be corrupting memory?

// Code stops working when I try to output to serial

#include “FastLED.h”

DEFINE_GRADIENT_PALETTE( heatmap_gp ) {
0, 0, 0, 0, //black
128, 255, 0, 0, //red
224, 255, 255, 0, //bright yellow
255, 255, 255, 255 }; //full white

class LedsMultitask {
CRGBPalette16 heatcolorPalette = heatmap_gp;
};

// Run on Teensy LC to reproduce this problem.

// merely having this object created causes the program to crash
// comment out this line to get see the 3 Serial.print() output
LedsMultitask Bordlys;

void setup() {
while (!Serial) ; // wait for Arduino Serial Monitor
delay(10);
Serial.println(“setup begin”);
Serial.println(“setup2”); // must print 2+ strings to reproduce problem
Serial.println(sizeof(LedsMultitask));
}

void loop() {
}

2

Hi Paul- I’ll check it out. Thanks for the report.

3

Just a hunch… but maybe somewhere deep within the code is an 8 bit char which might be treated as unsigned on AVR but signed on ARM?

4

I’m guessing it has to do with PROGMEM. I remember the teensy LC using the PGM stuff - I didn’t try it but I would try to define FASTLED_USE_PROGMEM 0

5

@PaulStoffregen : I mostly stick to “uint8_t” and similarly-named types for exactly this reason, but clearly there’s some platform-level difference here. I’m currently reading through the ARM asm output and taking it slowly and carefully.

6

@Shlomo_Zippel : You may be onto something there; I’m not sure that the Teensy LC (ARM M0+) with Teensyduino does PROGMEM the same way as other ARM-based boards. I’m reading the gcc ARM asm output now… not how I expected to spend this morning, but there are worse things to do!

7

OK, here’s the update: it may (or may) not be a signed/unsigned situation that is compiling differently for the ARM M0+ than for other ARM boards. I don’t have a stray Teensy LC handy to do actual live testing on, BUT I should have one in my hands in the next day or so, and I’ll be able to confirm at that point. So it’s overnight-shipping versus Winter Storm Stella (18-24" of snow for us), and we’ll see.

8

@Mark_Kriegsman - Please email me directly with your current postal address and I’ll send you a Teensy LC today!

9

The problem was found and fixed, with help from a few folks. Basically: ARM M0 requires even alignment for multi-byte reads, and the code was such that sometimes that wasn’t guaranteed. With code changes just committed to github, it appears to be working fine now on TeensyLC, as well as on other ARM-based boards, and on AVR as usual.

Thanks for the bug report and the help tracking it down.