Overflowing RAM

CollinK

Well-known member
I'm using Platform IO and it seems to be using the 1.58 version of the Teensy support files.

Here is what is reported at the end of my compile:

teensy_size: Memory Usage on Teensy MicroMod:
teensy_size: FLASH: code:332920, data:94080, headers:8196 free for files:16079876
RAM1: variables:164064, code:328840, padding:31608 free for local variables:-224
teensy_size: RAM2: variables:24736 free for malloc/new:499552

I have to admit, this caught me off guard. I was having some problems where seemingly very tiny source code changes could cause the code to work or not. This appears to be because I was running right up to the edge of RAM and the stack would overflow kind of randomly. Now I've added so much that it totally overflows by 224 bytes and won't even link and upload. So, I guess I was on the razor's edge before and wasn't paying close enough attention.

So, let my troubles be a warning. You can run out of RAM especially because the default is for all functions to be copied to and run from RAM. If you make large programs you can run out of RAM or get so close that it crashes the program in seemingly random ways. I really didn't expect this behavior but now that I see it, it makes sense. I guess for programs this large you have to get more acquainted with DMARAM and PROGMEM for storage then FLASHMEM for functions.
 
Code and static variables go into RAM1, and that's where you have the overflow. On the other hand, almost all of your RAM2 is available, so an easy fix is to add the DMAMEM keyword for some of the statically defined variables, or allocate them dynamically from the heap, either of which will result in them being in RAM2.
 
As a quick test, you could also try the "Smallest Code" optimization. This allows my TeensyMIDIPolySynth project to fit within the available RAM1 on the T4.0 that I am using as the audio processor.

Mark J Culross
KD5RXT
 
yeah, I'm aware of ways to mitigate the problem. I originally posted to get help but midway through the post I figured it out. But, I felt it was still worth a post in the off chance that someone might find it while searching and read all our replies to get solutions to their problem.

One thing that is maybe not obvious is the padding value. The PJRC site does mention that there is 32k alignment in RAM1 so the start of sections in RAM1 must fall on 32k alignment. Because of this, you have a padding value that will be between 0 and 32k bytes and you can't use the RAM in those padding bytes. Well, what happens if you are right near a boundary and then a subtle code change makes it go over? You go from very little padding to a LOT of padding. As above, if there was no padding I'd have plenty of RAM1 but because it went just slightly over I have a lot of padding. This can make builds break or not depending in the smallest code changes. In fact, I've seen this directly. While trying to fix the problem I'd find that small things like making one function FLASHMEM could tip the scale, cause padding to be basically zero, and everything would work fine.

One thing that is not so good here is that it seems like the Teensy flasher will still flash a program with negative free ram! That's not very developer friendly. When it happens it basically bricks the processor. You'll see the bootloader report all sorts of strange errors as it tries to bring up the processor. Luckily you can force an erase and be able to flash again but until you do, it looks dead.
 
One thing that is not so good here is that it seems like the Teensy flasher will still flash a program with negative free ram! That's not very developer friendly. When it happens it basically bricks the processor. You'll see the bootloader report all sorts of strange errors as it tries to bring up the processor. Luckily you can force an erase and be able to flash again but until you do, it looks dead.
This problem was reported a while ago. It is marked as fixed but I guess the fix will only be rolled out with the next Teensy release (real soon now)
 
Last edited:
Back
Top