EFM32 initial stackpointer for (u)ARM is wrong

[Sissors]

@stevew817 (At least I assume I should bother you with it)

If you look at random other target, the initial stack pointer is set to top of the RAM: https://developer.mbed.org/users/mbed_official/code/mbed-src/file/53297373a894/targets/cmsis/TARGET_Freescale/TARGET_KLXX/TARGET_KL25Z/TOOLCHAIN_ARM_MICRO/startup_MKL25Z4.S

For all EFM32 targets I checked it is not explicitly set, and I have no idea how the compiler handles it exactly: https://developer.mbed.org/users/mbed_official/code/mbed-src/file/53297373a894/targets/cmsis/TARGET_Silicon_Labs/TARGET_EFM32/TARGET_EFM32WG_STK3800/TOOLCHAIN_ARM_STD/startup_efm32wg.S

What is the result? The zero gecko has, as long as it fits within compile time, ALWAYS 300-400B of memory to use at runtime. If you have an empty program, it has 300-400B available. If you define a global array of 1kB, it still has 300-400B available. This means you can allocate only an extremly limited amount of data at runtime.

For the wonder gecko a quick test showed me about 4kB of data, which is still way short of the amount of RAM it has.

A simple program which iterates until it crashes because it filled its own stack could do 21 runs on a zero gecko, while on an LPC812 it did 222 runs. Also the first 4 bytes of the flash are always the initial stackpointer, and that shows that that is indeed the problem.

And in addition to that there is the much higher memory usage at compile time than for other similar targets, any idea what causes that?

[stevew817]

@Sissors yes, I'm the one you should be bothering :)

Thanks for your keen eye. This indeed looks like an oversight during the ARMCC startup file creation. The files were copied over from what we provide our customers for their custom applications, where you might not want to hard-define the stack top, and so you rely on the customer overriding the stack size. This also makes for more predictable code, since the stack size will be the same after every compile.

However, I agree that for mbed use it might be better to define the stack as big as possible by setting the initial stack pointer to the top of RAM. I will make the edits and push them to mbed.

Do you have any figures you are willing to share about the 'much higher memory usage'?

Thanks,
--Steven

[stevew817]

For clarification, the way __initial_sp is set:

Looking into the startup file, you see the following:

Stack_Size      EQU     0x00000400

                AREA    STACK, NOINIT, READWRITE, ALIGN=3
Stack_Mem       SPACE   Stack_Size
__initial_sp

Taking it line-for-line, the first line says AREA STACK, NOINIT, READWRITE, ALIGN=3, which tells the build system that all memory that is defined next goes into the stack region (which the build system automatically places as the last region towards the top of RAM), it doesn't need to initialize it on startup, and it needs to go into RAM (R/W property).

Next, it defines a memory block of size 'Stack_Size', here defined as 0x400 bytes.

The third line exports the current address (i.e. the start address of the stack region + the size of the declared memory block) as __initial_sp. It's just shorthand for __initial_sp EQU . The dot is the current address variable, which gets updated by the linker as it starts placing regions into memory.

[Sissors]

Thanks for the extra clarification how that part works. Regarding the much higher memory usage, lets compare the following program:

#include "mbed.h"
DigitalOut led(LED1);

int main()
{
    printf("Test = %d\r\n", &led);
    while(1) {
        led = !led;
        wait(0.5);
    }
}

It is a standard blinky program: The only reason I added that random printf is to force all targets to have the same stdio part included (it doesn't really matter, but this way there can be no confusion).

Then I compare the Zero Gecko, LPC812 and KL05: Three MCUs from three vendors, all with 4kB RAM, so mbed is always a tight fit and the best use of the RAM needs to be made. (Especially when you add for example the memory LCD lib for the Zero Gecko, which requires frame buffer in SRAM).

Compiled with online compiler, regular mbed lib
Zero Gecko: 0.8kB SRAM usage (actually more with mbed-src)
KL05z: 0.2kB SRAM
LPC812: 0.2kB SRAM

F030: 0.4kB SRAM (smallest Nucleo I have myself, it has 8kB SRAM so the extra 200B is alot less of an issue).

The difference is in the ZI data. Since for some reason my local mbed copy doesn't compile anymore, and there is not yet a keil exporter (I see you are working on it :) ), I haven't been able to figure out where it is going to exactly. What I did do was in the online compiler delete the API, the common, the hal and the targets/hal folders. In addition I removed all toplevel includes from the relevant file in cmsis folder, and there also emptied nvic.c + system.c functions. Main program was just while(1). And still it used 500B SRAM.

Summarized: Compared to others with similar memories you are losing 600B SRAM. I did also check it in Simplicity studio, there it was less. On top of my head it consumed 500B there. But comparing between compilers is harder always.

[stevew817]

Off the top of my head, I can think of two things:

• The implementation on EFM32, because it supports async operations, must be able to dynamically adjust the interrupt vectors. This means the vector table gets relocated to RAM instead of flash. On Zero Gecko, this accounts for 32 vectors * 4 bytes per address = 128 bytes.
• The asynchronous serial/SPI/I2C APIs can make use of DMA to do background transfers. The DMA peripheral is one that is licensed from ARM, and it requires the channel descriptors to be located in RAM (it doesn't have enough registers to cover all settings). On Zero Gecko, with 4 DMA channels, this equals 128 bytes of DMA configuration data.
• Another requirement for DMA is that the configuration block is aligned on a 256-byte boundary, and the linker can be pretty dumb about this. If stars align really miserably, you could be losing up to 255 bytes to alignment. This is an issue I am in the process of trying to find a fix for through adjusting the linker scripts. I have one ready to go for GCC, but ARMCC is giving me issues.

So, together these already account for anywhere between .25 and .49kB... I will see how quickly I can test the Keil exporters and update you when it happens.

[Sissors]

All mbed targets are capable of dynamically relocating the interrupt vectors (it is a requirement), so thats equal. InterruptIn depending on implementation can also take quite a bit (storage for possible handlers), but also there I would assume Gecko isn't really different.

DMA would indeed be significant. Still with the significant difference and the limitted RAM I think it would be useful to find out where it is all going compared to other targets. When it can be exported to Keil that should be able to give more information regarding its memory usage (hopefully).

[ciarmcom]

ARM Internal Ref: IOTMORF-247

[sg-]

@Sissors looks like the issue as reported resolved?