Teensy 3.2 running out of RAM?

Status
Not open for further replies.
Z

Zane470

Member
Hello,

I'm using a Teensy 3.2 for a project, and it's working great, but I'm having some very bizarre issues -- I suspect the device is somehow running out of RAM. I'm not using all that many libraries -- these are them:

Code: 
#include <SPI.h>
#include <Adafruit_GFX.h>
#include <Adafruit_SSD1305.h>
#include <SD.h>
#include <ADC.h>
#include <Adafruit_MAX31865.h>
#include <TheThingsNetwork.h>
#include <Chrono.h>
#include <TimeLib.h>
#include <EEPROM.h>
#include <ArduinoJson.h>

I only have about ~400 lines of my own code, everything is very simple, no large arrays or anything like this. The code will work fine, but when I add even one more function, the serial output is garbage and the device starts behaving very strangely. When I turn on "Optimize code for size", rather than the default "Optimize code for speed" it starts working fine once again.

Here is the start of the serial output before adding an extra function or array. You can see that it looks good....

Code: 
-- JOIN
Model: RN2903
Version: 1.0.3
Sending: mac set deveui 0004A30B0026132E
Sending: mac set adr off
Sending: mac set deveui 0004A30B0026132E
Sending: mac set appeui 70B3D57ED000ACDF
Sending: mac set appkey 105762D2C330C118044E0E23018B085C
Sending: mac save 
Sending: mac set ch status 0 off
Sending: mac set ch status 1 off
Sending: mac set ch status 2 off
Sending: mac set ch status 3 off
Sending: mac set ch status 4 off
Sending: mac set ch status 5 off
Sending: mac set ch status 6 off
Sending: mac set ch status 7 off
Sending: mac set ch status 8 on
Sending: mac set ch drrange 8 0 3
Sending: mac set ch status 9 on
Sending: mac set ch drrange 9 0 3
Sending: mac set ch status 10 on

Here is that same output after putting any new function at any place in my code...Also, when I enable "Smallest size" code optimization, it works normally again with the added function.

Code: 
-- JOIN
#ðñŠBÃ`xÓBhÁ`Ö›±invalid_param
ü h!Sending: �Göíq*ñ_+*ñA@ò�€*ñ+¾ñÛ²@ò–€+!úþ@ò�€£h A@ò�€*ñ+)Û²@ò‡€+&úñÙ£h 'Øßèð&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& invalid_param
&&&&&&&&&&&&&&&&&&&&&&&&&&&invalid_param
Sending: �Göíq*ñ_+*ñA@ò�€*ñ+¾ñÛ²@ò–€+!úþ@ò�€£h A@ò�€*ñ+)Û²@ò‡€+&úñÙ£h úÑË`ÊxÂç off
&&&&&&&&&&&&&&&&&&&&&&&&&&&invalid_param
Sending: �Göíq*ñ_+*ñA@ò�€*ñ+¾ñÛ²@ò–€+!úþ@ò�€£h A@ò�€*ñ+)Û²@ò‡€+&úñÙ£h 'Øßèð&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& invalid_param
&&&&&&&&&&&&&&&&&&&&&&&&&&&invalid_param
Sending: �Göíq*ñ_+*ñA@ò�€*ñ+¾ñÛ²@ò–€+!úþ@ò�€£h A@ò�€*ñ+)Û²@ò‡€+&úñÙ£h íq*ñ_+*ñA@ò�€*ñ+¾ñÛ²@ò–€+!úþ@ò�€£h 70B3D57ED000ACDF
&&&&&&&&&&&&&&&&&&&&&&&&&&&invalid_param
Sending: �Göíq*ñ_+*ñA@ò�€*ñ+¾ñÛ²@ò–€+!úþ@ò�€£h A@ò�€*ñ+)Û²@ò‡€+&úñÙ£h ¡`pbhxbç:O;hð 105762D2C330C118044E0E23018B085C
&&&&&&&&&&&&&&&&&&&&&&&&&&&invalid_param
Sending: �Göíq*ñ_+*ñA@ò�€*ñ+¾ñÛ²@ò–€+!úþ@ò�€£h £h2Yb`¡`pbhxbç:O;hð 
&&&&&&&&&&&&&&&&&&&&&&&&&&&invalid_param
Sending: �Göíq*ñ_+*ñA@ò�€*ñ+¾ñÛ²@ò–€+!úþ@ò�€£h A@ò�€*ñ+)Û²@ò‡€+&úñÙ£h Û²@ò‡€+&úñÙ£h &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& 0 off
&&&&&&&&&&&&&&&&&&&&&&&&&&&invalid_param
Sending: �Göíq*ñ_+*ñA@ò�€*ñ+¾ñÛ²@ò–€+!úþ@ò�€£h A@ò�€*ñ+)Û²@ò‡€+&úñÙ£h Û²@ò‡€+&úñÙ£h &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& 1 off
&&&&&&&&&&&&&&&&&&&&&&&&&&&invalid_param
Sending: �Göíq*ñ_+*ñA@ò�€*ñ+¾ñÛ²@ò–€+!úþ@ò�€£h A@ò�€*ñ+)Û²@ò‡€+&úñÙ£h Û²@ò‡€+&úñÙ£h &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& 2 off
&&&&&&&&&&&&&&&&&&&&&&&&&&&invalid_param
Sending: �Göíq*ñ_+*ñA@ò�€*ñ+¾ñÛ²@ò–€+!úþ@ò�€£h A@ò�€*ñ+)Û²@ò‡€+&úñÙ£h Û²@ò‡€+&úñÙ£h &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& 3 off
&&&&&&&&&&&&&&&&&&&&&&&&&&&invalid_param
Sending: �Göíq*ñ_+*ñA@ò�€*ñ+¾ñÛ²@ò–€+!úþ@ò�€£h A@ò�€*ñ+)Û²@ò‡€+&úñÙ£h Û²@ò‡€+&úñÙ£h &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& 4 off
&&&&&&&&&&&&&&&&&&&&&&&&&&&invalid_param
Sending: �Göíq*ñ_+*ñA@ò�€*ñ+¾ñÛ²@ò–€+!úþ@ò�€£h A@ò�€*ñ+)Û²@ò‡€+&úñÙ£h Û²@ò‡€+&úñÙ£h &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& 5 off
&&&&&&&&&&&&&&&&&&&&&&&&&&&invalid_param
Sending: �Göíq*ñ_+*ñA@ò�€*ñ+¾ñÛ²@ò–€+!úþ@ò�€£h A@ò�€*ñ+)Û²@ò‡€+&úñÙ£h Û²@ò‡€+&úñÙ£h &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& 6 off
&&&&&&&&&&&&&&&&&&&&&&&&&&&invalid_param
Sending: �Göíq*ñ_+*ñA@ò�€*ñ+¾ñÛ²@ò–€+!úþ@ò�€£h A@ò�€*ñ+)Û²@ò‡€+&úñÙ£h Û²@ò‡€+&úñÙ£h &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& 7 off
&&&&&&&&&&&&&&&&&&&&&&&&&&&invalid_param


It seems like there should be enough RAM:

Code: 
Sketch uses 75712 bytes (28%) of program storage space. Maximum is 262144 bytes.
Global variables use 8320 bytes (12%) of dynamic memory, leaving 57216 bytes for local variables. Maximum is 65536 bytes.

I'm a little baffled by this problem...with 64K RAM I'd assume I wouldn't be running into these types of issues. It isn't like I'm running a huge ethernet stack on it...
 
Hard to say without seeing the code. Could be something as simple as you are using an array and go outside the bounds of the array.

Or you have a function, that takes a large stack space, like a large array, especially if this functions ends up being called recursive... Or maybe one of these libraries and/or your code calls malloc or new for some large objects...

I believe that there is code somewhere up here on the forum, that allows you to get a reasonable guess on how much RAM is being used. Both by heap and stack... I have not looked in awhile.

I recently hacked up some code to run on another processor (Robotis OpenCM9.04), to get an idea of how much memory was being used, plus to help me quantify how much my changes save in ram...

But again only guessing here.
 
Code: 
uint32_t FreeMem(){ // for Teensy 3.0
    uint32_t stackTop;
    uint32_t heapTop;

    // current position of the stack.
    stackTop = (uint32_t) &stackTop;

    // current position of heap.
    void* hTop = malloc(1);
    heapTop = (uint32_t) hTop;
    free(hTop);

    // The difference is (approximately) the free, available ram.
    return stackTop - heapTop;
}

I just sprinkled the FreeMem() function around my code and this was the result:

Free RAM: 58404
Free RAM: 58092
Free RAM: 58092
Free RAM: 58404
Free RAM: 58404
Free RAM: 58412
Free RAM: 58404
Free RAM: 58092
Free RAM: 58092
Free RAM: 58404
Free RAM: 58404
Free RAM: 58412
Free RAM: 58404
Free RAM: 58092
Free RAM: 58092

So that looks fine I suppose...
 
One thing I don't quite understand is how that FreeMem() function (msg #2) is printing numbers slightly larger than the 57216 bytes (msg #1) Arduino's memory summary said are supposed to exist after subtracting the static variable allocations.
 
looks like a buffer overflow, array-index out of bounds, ...something is corrupting the ram.
Without code, impossible to say.
Try to strip it down and remove parts, until it works.
 
Could also be a wrong baud rate with a serial device, maybe with "TheThingsNetwork"? But this too is just a blind guess, since we can't see much about what you're doing.

Maybe this is a good moment to share the meme-style graphic from this blog article I recently wrote...

tech_support_steps-1.jpg
 
Status
Not open for further replies.
Back
Top