mbed-os/targets/TARGET_STM/TARGET_STM32F4/TARGET_MTS_DRAGONFLY_F411RE
Kevin Bracey fb6aa3ef4f Clean up ARM toolchain heap+stack setup in targets
ARM Compiler 6.13 testing revealed linker errors pointing out
conflicting use of `__user_setup_stackheap` and
`__user_initial_stackheap` in some targets. Remove the unwanted
`__user_initial_stackheap` from the targets - the setup is
centralised in the common platform code.

Looking into this, a number of other issues were highlighted

* Almost all targets had `__initial_sp` hardcoded in assembler,
  rather than getting it from the scatter file. This was behind
  issue #11313. Fix this generally.
* A few targets' `__initial_sp` values did not match the scatter
  file layout, in some cases meaning they were overlapping heap
  space. They now all use the area reserved in the scatter file.
  If any problems are seen, then there is an error in the
  scatter file.
* A number of targets were reserving unneeded space for heap and
  stack in their startup assembler, on top of the space reserved in
  the scatter file, so wasting a few K. A couple were using that
  space for the stack, rather than the space in the scatter file.

To clarify expected behaviour:

* Each scatter file contains empty regions `ARM_LIB_HEAP` and
  `ARM_LIB_STACK` to reserve space. `ARM_LIB_STACK` is sized
  by the macro `MBED_BOOT_STACK_SIZE`, which is set by the tools.
  `ARM_LIB_HEAP` is generally the space left over after static
  RAM and stack.
* The address of the end of `ARM_LIB_STACK` is written into the
  vector table and on reset the CPU sets MSP to that address.
* The common platform code in Mbed OS provides `__user_setup_stackheap`
  for the ARM library. The ARM library calls this during startup, and
  it calls `__mbed_user_setup_stackheap`.
* The default weak definition of `__mbed_user_setup_stackheap` does not
  modify SP, so we remain on the boot stack, and the heap is set to
  the region described by `ARM_LIB_HEAP`. If `ARM_LIB_HEAP` doesn't
  exist, then the heap is the space from the end of the used data in
  `RW_IRAM1` to the start of `ARM_LIB_STACK`.
* Targets can override `__mbed_user_setup_stackheap` if they want.
  Currently only Renesas (ARMv7-A class) devices do.
* If microlib is in use, then it doesn't call `__user_setup_stackheap`.
  Instead it just finds and uses `ARM_LIB_STACK` and `ARM_LIB_HEAP`
  itself.
2019-10-23 14:53:49 +03:00
..
device Clean up ARM toolchain heap+stack setup in targets 2019-10-23 14:53:49 +03:00
ONBOARD_TELIT_HE910.cpp Cellular: fix onboard modems powering failure 2019-02-14 12:39:37 +02:00
ONBOARD_TELIT_HE910.h Cellular: Power API updated to match onboard_modem_api 2019-01-22 02:24:45 -08:00
PeripheralNames.h TARGET_STM: Add DEVICE_SPI_COUNT to use SPIs without interference 2019-06-14 14:15:56 +02:00
PeripheralPins.c STM32F4 Internal ADC channels rework 2017-04-11 10:12:25 +02:00
PinNames.h TARGET_STM32F4 astyle 2018-06-27 14:42:28 +02:00
objects.h STM32: Analogin - define handle in object not as a global 2017-07-17 13:23:45 +02:00
onboard_modem_api.c Replace deprecated wait calls 2019-07-15 10:13:50 +03:00