Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 7 of 7

Thread: Teensy 3.1 crashing, memory problem?

  1. #1
    Junior Member
    Join Date
    Sep 2015
    Posts
    19

    Teensy 3.1 crashing, memory problem?

    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.

  2. #2
    Senior Member+ Theremingenieur's Avatar
    Join Date
    Feb 2014
    Location
    Colmar, France
    Posts
    2,600
    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.

  3. #3
    Junior Member
    Join Date
    Sep 2015
    Posts
    19
    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...

  4. #4
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    9,408
    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..

  5. #5
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    15,271
    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."?

  6. #6
    Senior Member
    Join Date
    Aug 2013
    Location
    Gothenburg, Sweden
    Posts
    419
    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 );

  7. #7
    Junior Member
    Join Date
    Sep 2015
    Posts
    19
    Quote Originally Posted by mlu View Post
    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... 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!

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •