The heap size was incorrectly calculated.
This fixes it by subtracting the Stack size, any memory chunks allocated
before the start of the application (for vectors and/or crash report), and
finally the size of the application from the total RAM size.
mbed-os consists of mbed-core and mbed-rtos
mbed-baremetal consists of mbed-core
The main change is for mbed-core. Changing from object library to be interface. This way it allows us to do the above to have 2 main targets for users to use.
This should be backward compatible change as mbed-os target we used contains the same files/options as previously set.
Directories that start with special prefixes (TARGET_, FEATURE_, COMPONENT_) are added to the build based on Mbed target configuration from targets.json instead of calling utility function mbed_add_cmake_directory_if_labels().
Add license identifier to files which Arm owns the copyright to,
and contain either BSD-3 or Apache-2.0 licenses. This is to address
license errors raised by scancode analysis.
Workaround a bug where the boot stack size configuration option is not
passed on to armlink, the Arm Compiler's linker. Prefer
MBED_CONF_TARGET_BOOT_STACK_SIZE if present, as this is what the
configuration system should provide. Fall back to MBED_BOOT_STACK_SIZE
if MBED_CONF_TARGET_BOOT_STACK_SIZE is not defined, as in the case of
buggy tools. If both MBED_CONF_TARGET_BOOT_STACK_SIZE and
MBED_BOOT_STACK_SIZE are not defined, then we fall back to a hard-coded
value provided by the linkerscript. See
https://github.com/ARMmbed/mbed-os/issues/13474 for more information.
To allow overriding of the boot stack size from the Mbed configuration
system, consistently use MBED_CONF_TARGET_BOOT_STACK_SIZE rather than
MBED_BOOT_STACK_SIZE.
Fixes#10319
All targets must implement soft_- and hard_power_on/off() functions which are practically same what onboard_modem_api offered.
These were seen as a duplicate features and therefore we removed this.
All targets involved have been updated to reflect the changes
Remove lwIP reliant networking and BLE tests for baremetal
Mbed OS 5 ported lwIP in its OS mode and uses threads. Networking
that rely on lwIP needs to be removed so it can be compiled with the
baremetal profile.
The BLE cordio Greentea tests are also disabled given that the feature
is not supported without an RTOS.
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.
Instead of user defined symbols in assembly files or C files,
use linker scripts to add heap and stack - this is inconsistent
with ARM std linker scripts
Stefan Staub
jeromecoutant
Hugues Kamba
Martin Kojtal
Rajkumar Kanagaraj
Rajkumar Kanagaraj
Harrison Mutai
Jaeden Amero
MarceloSalazar
Antti Kauppila
hamza-ubx
Kevin Bracey
mahanthgouda
aqib-ublox
Vincent Veron
Deepika
Ashok Rao
Jan Jongboom
Cruz Monrreal