Teensy 3.1 crashing, memory problem?

Status
Not open for further replies.

emiel.h

Member
Hi,

I'm working on the code of an installation that uses a teensy 3.1 with OctoWS2811 to control leds.
Here is a bit of an old video of the installation to get an idea: https://www.youtube.com/watch?v=0KjQS3GsGWQ
This "Creative Mind" artistically represents a neural network with the spheres being neurons and the tubes being synapses.

I'm now trying to get the code to be more structured by making a library and using classes, for example every ledstrip in a neuron or synapse is defined by the "Segment" class.
Now, i ran into a problem that got me stuck for a couple of days.
I'm trying to add more variables to the "Segment" class, but up to now this always results in the system to behave unexpectedly and freeze after some seconds.
This happens already when I only add an int to the list of variables.

I know this sounds like too much memory is being used and data therefore is getting corrupted, but after compiling it says only 15% of the program memory and 48% of the dynamic memory is being used.
No dynamic memory allocation is done as far as I know; I don't use malloc. When I print the amount of free ram in the program itself it stays around 33588 bytes.
When I reduced the amount of instances of the Segment class from 75 to 10 it still happened.
So it seems to me the problem is not caused by a lack of free memory space, but more because of some kind of limit on the size a class can have or something...

I hope somebody could at least help me to look in the right direction, because I really don't know how to solve this.


I'm using Arduino 1.6.5 and teensyduino 1.25 on Windows 10.
The code can be found here: https://github.com/emielch/Colore
The sketch I'm working on is called CMControllerNXT and can be found in the examples.
 
Without having actually the time to look onto your code, I can tell you than I ran recently into similar crashes: Program compiled fine but froze during execution. That happened because of addressing non instantiated classes or class members. Runtime code jumping to NULL pointers is deadly.
 
I'm quite sure this is not happening here. The code runs fine, even for extended periods of time.
But if I add one extra variable to the class, just for increasing the size of the class so without actually using it anywhere else, the program freezes during runtime. It can't be a memory size problem because there is still plenty left...
 
Local variables are dynamic, they're placed on the stack, for example when there is no unused cpu-register or it is an array, structure..
but of course, there are myriads other possibilities to crash..
 
Wondering if there was any OctoWS2811 hardware change that came with the software change - Is it confirmed the hardware as is works fine with the old software?

Perhaps you are now running the old sketch - can you gratuitously add the same variable to that old code - and leave them unused without all the other rewrite? Or did you already confirm this and that is what you did with this: "This happens already when I only add an int to the list of variables."?
 
Check the segAm variable that is passed to the colore.begin.
In CMControllerNXT.ino setup() you do:

Code:
  byte segAm = sizeof(seg)/4;
  colore.begin(LED_AM, seg, segAm, beams, BEAM_AM, &set_ledLib, &get_ledLib, &show_ledLib );

But as far as I can see seg is an array of Segment objects, not an array of segment pointers, so it probably should be

Code:
  byte segAm = sizeof(seg)/sizeof(Segment);
  colore.begin(LED_AM, seg, segAm, beams, BEAM_AM, &set_ledLib, &get_ledLib, &show_ledLib );
 
Check the segAm variable that is passed to the colore.begin.
In CMControllerNXT.ino setup() you do:

Code:
  byte segAm = sizeof(seg)/4;
  colore.begin(LED_AM, seg, segAm, beams, BEAM_AM, &set_ledLib, &get_ledLib, &show_ledLib );

But as far as I can see seg is an array of Segment objects, not an array of segment pointers, so it probably should be

Code:
  byte segAm = sizeof(seg)/sizeof(Segment);
  colore.begin(LED_AM, seg, segAm, beams, BEAM_AM, &set_ledLib, &get_ledLib, &show_ledLib );

Yes that fixed it, thank you so much!
I feel a bit stupid right now... :rolleyes: In an earlier version seg indeed was an array of Segment objects, but after I changed it I apparently forgot to change segAm accordingly. by some lucky chance (or unlucky actually) everything was still kept in balance and worked somehow until I started changing the segment class.

Thanks everybody for taking a look at this problem and getting it fixed so quickly!
 
Status
Not open for further replies.
Back
Top