Understanding RAM Usage

Hydra has 16MB RAM, 1MB reserved for RLP.

If I start a PURE NETMF project with nothing but Microsoft.SPOT.Native and mscorlib referenced and the following code:

using System;
using Microsoft.SPOT;

namespace MFConsoleApplication1
    public class Program
        public static void Main()
            Debug.Print("FREE RAM: " + Debug.GC(true));


My free RAM is 5.7MB in debug, 5.9 in release. I’ve lost more than 2/3 of my RAM just to turning the board on! :frowning:

And of course despite only having 2 references EVERYTHING loads. See output:

Found debugger!

Create TS.

 Loading start at 20175958, end 201a2c9c

   Assembly: mscorlib (     Assembly: Microsoft.SPOT.Native (     Assembly: Microsoft.SPOT.Hardware (  
   Assembly: Microsoft.SPOT.Graphics (     Assembly: Microsoft.SPOT.TinyCore (  
   Assembly: Microsoft.SPOT.IO (     Assembly: System.IO (     Assembly: Microsoft.SPOT.Hardware.Usb ( 
    Assembly: Microsoft.SPOT.Hardware.SerialPort (     Assembly: Microsoft.SPOT.Touch (  
   Assembly: Microsoft.SPOT.Ink (     Assembly: Microsoft.SPOT.Hardware.PWM (  
   Assembly: Microsoft.SPOT.Hardware.OneWire (     Assembly: System.Xml (  
   Assembly: Microsoft.SPOT.Time (     Assembly: Microsoft.SPOT.Net (  
   Assembly: System (     Assembly: Microsoft.SPOT.Net.Security (  
   Assembly: System.Net.Security (  Loading Deployment Assemblies.

Attaching deployed file.

   Assembly: MFConsoleApplication1 (  Resolving.

GC: 1msec 297108 bytes used, 5994024 bytes available

Type 0F (STRING              ):     24 bytes

Type 15 (FREEBLOCK           ): 5994024 bytes

Type 17 (ASSEMBLY            ):  21756 bytes

Type 1E (BINARY_BLOB_HEAD    ): 275256 bytes

Type 34 (APPDOMAIN_HEAD      ):     72 bytes

GC: performing heap compaction...

The debugging target runtime is loading the application assemblies and starting execution.

'Microsoft.SPOT.Debugger.CorDebug.dll' (Managed): Loaded 'C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.2\Assemblies\le\mscorlib.dll', Symbols loaded.
'Microsoft.SPOT.Debugger.CorDebug.dll' (Managed): Loaded 'C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.2\Assemblies\le\Microsoft.SPOT.Native.dll', Symbols loaded.
'Microsoft.SPOT.Debugger.CorDebug.dll' (Managed): Loaded 'C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.2\Assemblies\le\Microsoft.SPOT.Hardware.dll', Symbols loaded.
'Microsoft.SPOT.Debugger.CorDebug.dll' (Managed): Loaded 'C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.2\Assemblies\le\Microsoft.SPOT.Graphics.dll', Symbols loaded.
'Microsoft.SPOT.Debugger.CorDebug.dll' (Managed): Loaded 'C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.2\Assemblies\le\Microsoft.SPOT.TinyCore.dll', Symbols loaded.
'Microsoft.SPOT.Debugger.CorDebug.dll' (Managed): Loaded 'C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.2\Assemblies\le\Microsoft.SPOT.IO.dll', Symbols loaded.
'Microsoft.SPOT.Debugger.CorDebug.dll' (Managed): Loaded 'C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.2\Assemblies\le\System.IO.dll', Symbols loaded.
'Microsoft.SPOT.Debugger.CorDebug.dll' (Managed): Loaded 'C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.2\Assemblies\le\Microsoft.SPOT.Hardware.Usb.dll', Symbols loaded.
'Microsoft.SPOT.Debugger.CorDebug.dll' (Managed): Loaded 'C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.2\Assemblies\le\Microsoft.SPOT.Hardware.SerialPort.dll', Symbols loaded.
'Microsoft.SPOT.Debugger.CorDebug.dll' (Managed): Loaded 'C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.2\Assemblies\le\Microsoft.SPOT.Touch.dll', Symbols loaded.
'Microsoft.SPOT.Debugger.CorDebug.dll' (Managed): Loaded 'C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.2\Assemblies\le\Microsoft.SPOT.Ink.dll', Symbols loaded.
'Microsoft.SPOT.Debugger.CorDebug.dll' (Managed): Loaded 'C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.2\Assemblies\le\Microsoft.SPOT.Hardware.PWM.dll', Symbols loaded.
'Microsoft.SPOT.Debugger.CorDebug.dll' (Managed): Loaded 'C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.2\Assemblies\le\Microsoft.SPOT.Hardware.OneWire.dll', Symbols loaded.
'Microsoft.SPOT.Debugger.CorDebug.dll' (Managed): Loaded 'C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.2\Assemblies\le\System.Xml.dll', Symbols loaded.
'Microsoft.SPOT.Debugger.CorDebug.dll' (Managed): Loaded 'C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.2\Assemblies\le\Microsoft.SPOT.Time.dll', Symbols loaded.
'Microsoft.SPOT.Debugger.CorDebug.dll' (Managed): Loaded 'C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.2\Assemblies\le\Microsoft.SPOT.Net.dll', Symbols loaded.
'Microsoft.SPOT.Debugger.CorDebug.dll' (Managed): Loaded 'C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.2\Assemblies\le\System.dll', Symbols loaded.
'Microsoft.SPOT.Debugger.CorDebug.dll' (Managed): Loaded 'C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.2\Assemblies\le\Microsoft.SPOT.Net.Security.dll', Symbols loaded.
'Microsoft.SPOT.Debugger.CorDebug.dll' (Managed): Loaded 'C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.2\Assemblies\le\System.Net.Security.dll', Symbols loaded.
'Microsoft.SPOT.Debugger.CorDebug.dll' (Managed): Loaded 'c:\users\thom\documents\visual studio 2010\Projects\MFConsoleApplication1\MFConsoleApplication1\bin\Release\le\MFConsoleApplication1.exe', Symbols loaded.
The thread '<No Name>' (0x2) has exited with code 0 (0x0).
GC: 1msec 299448 bytes used, 5991684 bytes available
Type 0F (STRING              ):    276 bytes
Type 11 (CLASS               ):   1656 bytes
Type 12 (VALUETYPE           ):     72 bytes
Type 13 (SZARRAY             ):    960 bytes
  Type 03 (U1                  ):    156 bytes
  Type 04 (CHAR                ):    276 bytes
  Type 07 (I4                  ):     36 bytes
  Type 11 (CLASS               ):    492 bytes
Type 15 (FREEBLOCK           ): 5991684 bytes
Type 16 (CACHEDBLOCK         ):     72 bytes
Type 17 (ASSEMBLY            ):  21756 bytes
Type 18 (WEAKCLASS           ):     48 bytes
Type 19 (REFLECTION          ):    144 bytes
Type 1B (DELEGATE_HEAD       ):     72 bytes
Type 1D (OBJECT_TO_EVENT     ):     24 bytes
Type 1E (BINARY_BLOB_HEAD    ): 271404 bytes
Type 1F (THREAD              ):    384 bytes
Type 20 (SUBTHREAD           ):     48 bytes
Type 21 (STACK_FRAME         ):    408 bytes
Type 27 (FINALIZER_HEAD      ):     24 bytes
Type 31 (IO_PORT             ):     36 bytes
Type 34 (APPDOMAIN_HEAD      ):     72 bytes
Type 36 (APPDOMAIN_ASSEMBLY  ):   1992 bytes
GC: performing heap compaction...
FREE RAM: 5991684

Is there any way to lose some of this bloat? So little memory makes my device sad.

1 Like

There is
custom heap region
Execute region
System ram
Video ram

Gus, ah ok. I had thought about the LCD area RAM last night. Help me understand the free RAM I’m seeing.

Custom heap doesn’t show as free even if you’re not using it? Is that because it gets set aside and then used as needed and available by large blobs? If so is there anyway to know how much of the heap is free?

Execute RAM is where the program is being loaded, yes? I would have thought with an app that small it wouldn’t take up much at all. Or is it not dynamic? Is the max size already set aside and not useable no matter what?

Don’t get me wrong 5MB is still a LOT of RAM for an embedded device; I just thought what was there according to specs was getting eaten way too much and had assigned blame to NETMF / Gadgeteer bloat.

Basically I’m ok with only having 5.7 of the 16 MB free I’m just trying to understand where the rest is going.

This is not an over head, “custom heap” is 4MB that is free but it will not show when you get the “heap” free size.

Either way, the overhead is the same independent from the RAM size or you application size.

The question is, why do you need more than 2MB for whatever you are doing? Just curious.

Oh I don’t. I was actually just graphing the free vs total RAM last night as part of a project and said “whoa, where is it all”. Knowing the 4MB is allotted to custom heap and doesn’t show in the total free makes me feel a lot better about knowing where the RAM is.

5.7 Free + 1 RLPlite + 4 custom heap = 10.7 of 16 and I can justify 1/3 of RAM on an embedded device going to system in my mind. :slight_smile:

Also keep in mind that the Hydra has a serial flash chip and NETMF can’t execute in place from serial flash, only from NOR flash. Thus the whole NETMF must be copied to ram at start up. That acounts for another meg or two.

Or am I wrong Gus?

That is correct and I’m fine with that, I was just looking to find where it all went.

This mean No large (>640x480) Image processing available 8(

That is what custom heap is for.

1 Like

Please mark the answer to your question.

I had marked your first reply the answer as soon as you made it. Might want to have josh check if editin the initial post undoes answer selection.