Arduino 101 SRAM inaccesible

I have come across some strange findings concerning the SRAM on the Arduino 101 and wanted to see if anyone knew what was causing the strange behaviors I found.

I was trying to verify exactly how much SRAM is accessible to the user on the Arduino 101 because I was going to work with rather large arrays and didn't want to run out of memory. I wrote a simple program to test how much memory I could allocate, and found it fell far short of the 24kB specified on the product page. The program simply allocates an array, and I changed the size to find how large a block I could allocate. 2188 floats was the cutoff. Here is the program I used:

float a[2188];

void setup() {
  a[0] = 1;
}

void loop() {
  // put your main code here, to run repeatedly:
}

With 4 being the size of a float, I calculated that I was able to use just under 9kB, not anything close to 24. (2188*4 = 8752). It doesn't make sense to me why so little would be available.

I also saw on the product page for the Intel Curie (which I understand to be used on the Arduino 101) claims to have 80kB of SRAM and 384kB of flash storage (as opposed to 196kB of flash on the 101).

Does anyone know why the Arduino 101 does not share the same memory quantities as the Intel Curie and why less than half of the SRAM can be utilized?

Cheers, -MF

Hi Mos_Fett, the Curie module contains two cores (x86 and ARC) which share the resources (both RAM and flash). The x86 core runs an RTOS and occupies most of them, hence the 24kB vs 80kB free RAM. However, your problem seems different, since it looks like the linker is using DCCM instead than SRAM section (https://github.com/01org/corelibs-arduino101/blob/master/variants/arduino_101/linker_scripts/flash.ld#L40). Would you mind opening an issue on Intel's github?

Thanks M

If you don't know what DCCM is:

http://semiengineering.com/remove-the-bus-from-your-embedded-system/

Short summary: memory that is closer to the ARC cpu and not across the bus that connects the several (Quark and Arc) processors in the Cure.

facchinm: you just guessed since 2k*4 bytes per float = 8k, which is the size of the DCCM ? Or can you read the output of the compiler/linker to know it is trying to assign memory to the DCCM?

The linker script reserves 8192 bytes for heap and 2560 bytes for stack. That leaves 13824 bytes for data and bss sections.

[color=maroon]> arc-elf32-size -A sketch_jun15a.ino.elf[/color]
sketch_jun15a.ino.elf  :
section            size         addr
text              13176   1073954816
ctors                12   1073967992
rodata              436   1073968004
[color=blue]datas              3196   2818629632
bss               10668   2818632828[/color]
[color=red]heap               8192   2818643496
stack              2560   2818651688[/color]
.debug_info       70784            0
.debug_abbrev     15823            0
.debug_loc        22069            0
.debug_aranges     2848            0
.debug_ranges      2992            0
.debug_line       21276            0
.debug_str        17405            0
.comment            149            0
.debug_frame       9628            0
Total            201214

Normally the ELF file is removed on error; that can be prevented with option -Wl,--noinhibit-exec.

Thank you all for your replies. I started a new issue on Intel's github per facchinm's suggestion (https://github.com/01org/corelibs-arduino101/issues/212). If I find an answer I will post it here for completeness. That's interesting that it could be a linker issue. I am not too familiar with the 101's architecture or how code is uploaded to it aside from on a macroscopic scale. Would there be a simple way to fix this potential bug in the linker?

I read the response to your issue. I think it says there is probably no problem in the linker.

How knowledgeable are you about assembler and the linker? I don't have recent knowledge. I think your array and other static variables go in the .data section, your executable code (the sketch, any libraries, and the core?) in the. bss, the .heap is reserved for dynamically allocated memory, and the stack is reserved for the stack of frames representing function calls.

You might be able to change some (Arduino defined?) file and change the reserved heap and stack. For example, if you know your program is not dynamically allocating memory. But you would need to know whether the Arduino libraries and internals were allocating dynamic memory.

When you account for what is needed for the stack, the heap, and for Arduino, your sketch gets much less than the advertised 24k memory.

bootchk yes, as I stated in my response in the issue tracker, you could decrease the default heap size and the default stack size (See my response for details https://github.com/01org/corelibs-arduino101/issues/212).

In addition to the stack and the heap (executable code goes in .text, not .bss, so ends up in Flash rather than SRAM), all of the data for corelibs code takes up about 5k of .bss and .data, which also goes into SRAM. I'm currently looking at reducing this 5k (there's some low-hanging fruit like struct alignments that will make a considerable difference).

It makes sense that space allocated for things other than the heap would be taking up the remaining SRAM, but I don't think I would have figured that out. If I end up modifying the linker script to allocate more SRAM for the heap I will be sure to let you guys know. Thanks again for the help, I really appreciate it.