Debug.GC(true) hangs

[WilliamAtSamraksh]

eMote v. 15 release (Build Date May 11 2016 13:56:02, Software ID: 10d7bd34c03d6059721646a59262566ff70f24b4-clean by: Chris)

The program is attached to the comment below.

The program uses OMAC, in case that's relevant. The following code is in the ADC callback of the program "Fence Node 1.5.sln". On the second callback it hangs after the first Debug.Print.

Debug.Print("* ADC callback"); Debug.Print("Free = " + Debug.GC(true) + ".");

A callback might be a bad place to put a call to GC; but it was working with v. 14 & CSMA. (I had put it in because the amount of memory available was very low and string concatenation kept throwing exceptions.)

[WilliamAtSamraksh]

Something went wrong with the upload. Here it is. 2016.05.12 Managed Virtual Fence.zip

[ChrisAtSamraksh]

This problem occurred earlier because of a lack of memory.The Debug.Prints can use a lot of memory but we don't even have a classifier running yet. I think we need to see what we can do to gain a lot more memory again.

[Nathan-Stohs]

This problem occurred earlier because of a lack of memory.The Debug.Prints can use a lot of memory but we don't even have a classifier running yet. I think we need to see what we can do to gain a lot more memory again.

To put some numbers to it, from latest Master build (release):

$ arm-none-eabi-size tinyclr.axf
   text    data     bss     dec     hex filename
 465868    3636   30900  500404   7a2b4 tinyclr.axf

TinyCLR+OMAC uses 458.5 kB flash memory and 33.7 kB of SRAM statically allocated.

From the last time I took a snapshot (about a year ago):

$ arm-none-eabi-size tinyclr.axf
   text    data     bss     dec     hex filename
 415668    2692   32952  451312   6e2f0 tinyclr.axf

TinyCLR uses 408.5 kB flash and 34.8 kB SRAM statically allocated.

So our static SRAM usage is actually down a bit compared to last time I checked. Unless OMAC is using dynamic memory (i.e. malloc)?. Although the extra 50 kB of code seems a little bloat-y.

Chris, did you implement the #define RUNTIME_MEMORY_PROFILE__small change that I suggested? If so that should have freed up 10 kB or so, unless OMAC ate that so we're back where we started. Possible that these problems are related to new setting.

[ChrisAtSamraksh]

Yeah, OMAC basically used up all the memory savings we got from using the small runtime memory. We are doing away with an 8kB arctan lookup table so that will free up a good chunk of memory and hopefully that gets us enough to have the classifier working.

The problem is not the garbage collection though and hopefully we freed up enough memory for the short term at least.

[Nathan-Stohs]

We are doing away with an 8kB arctan lookup table so that will free up a good chunk of memory and hopefully that gets us enough to have the classifier working.

The arctan table would not have consumed any RAM if it was done in native and declared 'const', which I think it was. So don't hope for any savings there. Different story if comparing to managed code.

[ChrisAtSamraksh]

It wasn't in native and it was passed from C#.