[STM32L4] Update ARM_MICRO startup files

[bcostm]

Fix issue #1348

[0xc0170]

Why this removal for uLib STD?

[0xc0170]

MY question could be answered by describing the change in the commit. I can see here removal of Stack_size, Stack_mem, adjusting heap size and changing heap_limit calculation. PLease add more details for this changeset - why, how..

[bcostm]

This change has been done to fix some issues with the stack/heap. I just checked that it worked but I didn't do this modification. @betzw can you please answer to Martin ? Because I also asked myself how is it possible to remove the stack size and heap limit in this file without problem...

[betzw]

Regarding heap,
with the old startup file the result after linking looked like this:

   __heap_limit                             0x10007c00   Number         0  startup_stm32l476xx.o ABSOLUTE
   __initial_sp                             0x10008000   Number         0  startup_stm32l476xx.o ABSOLUTE

...

   __heap_base                              0x20002e68   Data           0  startup_stm32l476xx.o(HEAP)

so the _heap_limit was below the __heap_baseand even in a different memory bank, which for sure was a mistake. Furthermore the limit seemed to be a constant number while the base seemed to be a variable of size zero, which somehow also looked odd to me too.

Regarding stack,
considering the above numbers I was wondering how to specify for the ARM_TOOLSETs correctly something like: 32K of heap somewhere in the RAM bank starting at 0x20000000 and 16K stack at the end of RAM bank starting at 0x10000000. The result of my investigations is reflected by the changes in this PR made to file startup_stm32l476xx.s: where both heap-limit & heap-base are calculated by the linker (and to me somehow "magically" put in the RAM bank starting at 0x20000000) while I calculated the value of the initial stack pointer as the same constant value as in the old startup file. Regarding the stack size I didn't actually know what exactly to do and exactly which effect the definition of a

Stack_Mem       SPACE   Stack_Size

would have actually had (above all with respect to linking) ... If it actually would reserve Stack_Size of memory at the end of the RAM bank starting at 0x10000000 then we should obviously add the removed lines back to the startup file (but with a stack size of 0x4000, i.e. 16K).

[betzw]

Any feedback?

cc @screamerbg

[0xc0170]

Sorry for the delay, we should look at this changeset for this release (the issue 1561)

cc @sg-

[sg-]

Does this device really have 1M flash and if so why support uARM? http://www.st.com/web/catalog/mmc/FM141/SC1169/SS1580/LN1840/PF260095?icmp=pf260095_pron_pr_feb2015&sc=stm32l476-pr

Please see this proposal #1536

[betzw]

Not sure if your proposal #1536 is about which tool-sets need to be supported (i.e. are required) or just about which tool-set should be the default one.
Currently, this PR is urgent for any of our users who try to use this platform with the online-compiler, so pls. do not let us loose time in useless discussions and lets merge it.
We can always adapt afterwards to any decision you will take regarding required and/or default tool-sets.

cc @nikapov-ST

[sg-]

Why is uARM used by default for a MCU with 1M of flash?

[betzw]

This is not the crucial question here!
It might be just because nobody really cared when starting the port but @bcostm might know better.
@sg- if you want to change the default tool-set for this platform, pls. send a respective PR!
@screamerbg could you pls. help us to get this PR finally merged!

[bcostm]

Since the beginning I use uARM because this is also the default we use in the examples delivered in the STM32Cube packages. We can change it later if it is required.

[star297]

Sam, is it possible to incorporate a selectable drop down on the on-line compiler IDE for the user to select uARM or Standard? Would be quite a nice touch.

[0xc0170]

@sg- if you want to change the default tool-set for this platform, pls. send a respective PR!

We should, as you proposed not as part of this PR.

I'll merge this now, as based on the above comments and the description provided http://www.keil.com/support/docs/3340.htm. Thanks @betzw for providing details.

[betzw]

Thanks a lot @0xc0170

[helmut64]

@betzw I resumed my work on the STM32L4 Disco and Nucleo boards using the mbed online compiler. The current configuration has a 32k heap limit, more memory cannot be alloced via new or malloc. I believe the error is the following line in TOOLCHAIN_ARM_MICRO/startup_stm32l476xx.s for the Disco and Nucleo mbed libraries.
Heap_Size EQU 0x8000 ; 32KB

The correct size should be:
Heap_Size EQU 0x18000 ; 96KB

Regards Helmut