STM32L4 Stack and Heap overlap problem

[helmut64]

For the new STM32L4 I found out a major problem, the first 4k of the heap overlap with the stack!
More details here: https://developer.mbed.org/questions/60933/STM32L4-Stack-and-Heap-overlap-Disco/

I believe the problem is in startup_stm32l476xx.s (Disco & Nucleo)

The following line must be inserted/changed: (TOOLCHAIN_ARM_STD + TOOLCHAIN_ARM_MIKRO) initial_sp EQU 0x20018000 ; Top of RAM1 96k

This would at least enable the 96k of RAM1, however there is another 32k SRAM2 at 0x10000000-0x10008000. My preference would be use the SRAM2 for the stack and HEAP, and add the SRAM1 for additional HEAP.
Regards Helmut

[0xc0170]

Thanks for reporting. I just referenced the issue in PR which is now for review. Please review

[helmut64]

The change looks good. However, at present I have no local ARM compiler setup for local testing, I will test it on mbed.org when available.

[helmut64]

I found another problem in the stm32l476xx.sct config files (Nucleo abd Disco)
TOOLCHAIN_ARM_STD and TOOLCHAIN_ARM_MICRO:
old: RW_IRAM1 (0x20000000+0x188) (0x20000-0x188) { ; RW data
new: RW_IRAM1 (0x20000000+0x188) (0x18000-0x188) { ; RW data
TOOLCHAIN_GCC_ARM: STM32L476XX.ld
old: RAM (rwx) : ORIGIN = 0x20000188, LENGTH = 128K - 0x188
new: RAM (rwx) : ORIGIN = 0x20000188, LENGTH = 96K - 0x188

[0xc0170]

@helmut64 Can you send a pull request?

cc @bcostm

[helmut64]

The stack problem is now fixed with my previous checkins, the Nucleo L4 board works fine, the stack is correct however there are remaining problems/limitations: ( I am using the mbed.org online compiler)
a) The Disco L4 board crashes (it looks like before main)

b) The Nucleo L4 board works fine, however the main memory heap/data region be mapped to 0x2000000 and should be mapped to 0x1000000 as defined in the .sct file.

c) Allocating memory (in 4k blocks) it crashes after 84k (via malloc). I was expecting a NULL return instead of a crash. I am also to be able to alloc about 124k before I get can malloc error.

Could it be that the mbed.org compiler has somewhere a linker file which needs to be updated?
Any ideas?

[0xc0170]

@helmut64 Still having problems with L4 and allocations?
The linker file should use the same as in here (if using mbed-src), or at least with the fixes you sent, they are in the latest mbed library release.

You can test the your example using sources from this repo to compare results.

[helmut64]

@MartinKojtal, the problem is not fully resolved.

• The stack localtion problem is resolved.
  On The L4 Nuceo it works, no stack craches, correct stack address,
• However there are still memory size problems.
• On The L4 Disco it craches before main.
  I got a new Keil uVision this week which supports the L4, my plan was to investigate further, using a the debugger, however the next 14 days my time is very limited.

The intention is that the data/heap memory gets first used from the SRAM2 at 0x10000000 (32k) and further used from the SRAM1 at 0x20000000, once the SRAM2 is used up until the stack starts. I configured this is the .sct files however data/heap starts at 0x20000000 (SRAM1). So somewhere is a different config which results into problems:

• Once 96k (SRAM) are used my malloc (4K blocks), the last malloc craches, exspected are the total of 128k (32k+96+) (less stack, data, etc.)

Regards
Helmut

Is there still some problem with the STM32L4 memory configuration?
I have a NUCLEO-L476RG board and I made some tests with it.

• Using the online compiler I build the blinky example, but no blinking on the board.
• I cloned the mbed-src and build it for my board, then build the blinky example, but no blinking.
• I modified the linker script so that the heap and stack are placed on SRAM1 and rebuild. It blinks!

The toolchain used for the offline builds was GCC ARM.
I have not tested with any other toolchain. Also I cannot say if this is a valid fix for an issue or just a workaround that happens to hide a real issue underneath.

[MarceloSalazar]

@0xc0170 could you please have a look into this?

[0xc0170]

@melomaa Using the latest master? This issue was for uvision , which was supposed to be fixed. We shall have a look at GCC ARM linker script file. can you point out what exactly you have changed?

cc @bcostm @adustm

[helmut64]

I have not worked on this for some time. I verifyed today via the online compiler using the STM32L3 Nucleo board which works ok, the STM32L Discovery still crashes before main. My comment above from "Oct 4, 2015" is still valid. My testing belongs to the mbed online compiler.

My plan was to debug it using the uvision IDE or gcc/gdb, which I have no done so far. For the gcc/gdb I am still looking for setup options on my Mac. I got uvision running on my Windows box, however I may need to purchase an unlimited copy because the free version has a 32k limit.

@0xc0170
I was using the release 111.

In the linker script file the memories are defined
SRAM2 (rwx) : ORIGIN = 0x10000188, LENGTH = 32k - 0x188
SRAM1 (rwx) : ORIGIN = 0x20000000, LENGTH = 96k

I changed for heap and stack sections:

• } > SRAM2

• } > SRAM1

and then the stack top definition

• __StackTop = ORIGIN(SRAM2) + LENGTH(SRAM2);

• __StackTop = ORIGIN(SRAM1) + LENGTH(SRAM1);

[helmut64]

@melomaa,

Below is a little test I wrote to verify the memory locations. Please note that when I call the MaxMemoryBlockAvailable (enable it first) the system hangs at the end of the memory, however it should give a NULL return which works fine on the STM32L1. Second we should get almost 128 kb 32+96 (minus stack) which is not the case. Third starting with the 32kb SRAM 2 and keeping the stack on the top os SRAM 2 has a major advantage we can disable SRAM 1 in deep sleep mode which allows further sleep modes and energy savings. I am available to discuss this further.

Regards Helmut

#include "mbed.h"
#include

DigitalOut myled(LED1);

Serial *bs;

void SunFunc() {
uint32_t temp[16];
bs->printf("stackSunFunc=0x%x\r\n", &temp);
}

size_t
MaxMemoryBlockAvailable(bool print)
{
int i = 0;

for (i = 1; i < 1024; i++) {
    char *p = new (std::nothrow) char[i*1024];
    if (p)
         delete[] p;
    else {
        i--;
        break;
    }
}
bs->printf("MaxMemoryBlockAvailable: %d kB\r\n", i);
return i * 1024;

}

int main() {
uint32_t temp = 0;
bs = new Serial(USBTX, USBRX);
bs->baud(115200);

printf("Hello\r\n");
printf("Hello2\r\n");
// MaxMemoryBlockAvailable(true);

char *p1 = new  char[4096];

memset(p1, 0, 4096);


bs->printf(" main=0x%x\r\n", &main);
bs->printf(" data=0x%x\r\n", &bs);
bs->printf("stack=0x%x\r\n", &temp);
bs->printf("   p1=0x%x-0x%x\r\n", p1, p1+4096);
SunFunc();

for (int i = 0; i < 5; i++)
    bs->printf("Hello(%d) ", i);
bs->printf("\r\n");

for (int i = 0; i < 21; i++) {
    void *t = malloc(4096);
    memset(t, 0, 4096);

    if (t == NULL) {
        bs->printf("malloc: Out of memory\r\n");
        break;
    }
    bs->printf(" data%d=0x%x\r\n", i, t);

}

while(1) {
    myled = 1; // LED is ON
    wait(0.2); // 200 ms
    myled = 0; // LED is OFF
    wait(1.0); // 1 sec
}

}