Refactor all Nuvoton targets to be CMake buildsystem targets. This removes
the need for checking MBED_TARGET_LABELS repeatedly and allows us to be
more flexible in the way we include MBED_TARGET source in the build.
A side effect of this is it will allow us to support custom targets
without breaking the build for 'standard' targets, as we use CMake's
standard mechanism for adding build rules to the build system, rather
than implementing our own layer of logic to exclude files not needed for
the target being built. Using this approach, if an MBED_TARGET is not
linked to using `target_link_libraries` its source files will not be
added to the build. This means custom target source can be added to the
user's application CMakeLists.txt without polluting the build system
when trying to compile for a standard MBED_TARGET.
Refactor all GigaDevice targets to be CMake buildsystem targets. This removes
the need for checking MBED_TARGET_LABELS repeatedly and allows us to be
more flexible in the way we include MBED_TARGET source in the build.
A side effect of this is it will allow us to support custom targets
without breaking the build for 'standard' targets, as we use CMake's
standard mechanism for adding build rules to the build system, rather
than implementing our own layer of logic to exclude files not needed for
the target being built. Using this approach, if an MBED_TARGET is not
linked to using `target_link_libraries` its source files will not be
added to the build. This means custom target source can be added to the
user's application CMakeLists.txt without polluting the build system
when trying to compile for a standard MBED_TARGET.
Ensure WICED is included for Mbed targets that require it.
This also removes the need for checking MBED_TARGET_LABELS repeatedly and
allows us to be more flexible in the way we include MBED_TARGET
source in the build.
A side effect of this is it will allow us to support custom targets
without breaking the build for 'standard' targets, as we use CMake's
standard mechanism for adding build rules to the build system, rather
than implementing our own layer of logic to exclude files not needed for
the target being built. Using this approach, if an MBED_TARGET is not
linked to using `target_link_libraries` its source files will not be
added to the build. This means custom target source can be added to the
user's application CMakeLists.txt without polluting the build system
when trying to compile for a standard MBED_TARGET.
Refactor all Silicon Laboratories targets to be CMake buildsystem targets. This removes
the need for checking MBED_TARGET_LABELS repeatedly and allows us to be
more flexible in the way we include MBED_TARGET source in the build.
A side effect of this is it will allow us to support custom targets
without breaking the build for 'standard' targets, as we use CMake's
standard mechanism for adding build rules to the build system, rather
than implementing our own layer of logic to exclude files not needed for
the target being built. Using this approach, if an MBED_TARGET is not
linked to using `target_link_libraries` its source files will not be
added to the build. This means custom target source can be added to the
user's application CMakeLists.txt without polluting the build system
when trying to compile for a standard MBED_TARGET.
Refactor all Samsung targets to be CMake buildsystem targets. This removes
the need for checking MBED_TARGET_LABELS repeatedly and allows us to be
more flexible in the way we include MBED_TARGET source in the build.
A side effect of this is it will allow us to support custom targets
without breaking the build for 'standard' targets, as we use CMake's
standard mechanism for adding build rules to the build system, rather
than implementing our own layer of logic to exclude files not needed for
the target being built. Using this approach, if an MBED_TARGET is not
linked to using `target_link_libraries` its source files will not be
added to the build. This means custom target source can be added to the
user's application CMakeLists.txt without polluting the build system
when trying to compile for a standard MBED_TARGET.
The Appollo3 targets require dummy sections in stack and heap regions.
The stack dummy section does not contain any symbols. It is only used
for the linker to calculate the size of the stack sections and assign
values to stack symbols later.
The heap dummy region is used to identify the beginning of available dynamic memory.
A CMake custom target, mbed-post-build, is added as a dependency of the
application CMake target if a Mbed target adds a CMake custom target
named mbed-post-build-bin. mbed-post-build-bin is added as a dependency
of mbed-post-build. mbed-post-build-bin depends on the application binary.
This is done so a CMake custom command that executes post-build can be added.
The Python scripts that implement the operations have been modified to add
CLI entry points so they can be called from CMake. Dependency on the old
tool has been removed on those scripts by passing them exactly what they
require instead of passing old tool Python objects. A consequence of that
was to slightly amend how the old tool calls some of those Python modules.
Support has only been added for Mbed targets that currently have a requirement
for post build operations. This includes: LPC1114, LPC1768, ARCH_PRO, LPC54114,
LPC546XX, FF_LPC546XX, CY8CKIT064B0S2_4343W, CYTFM_064B0S2_4343W, CYSBSYSKIT_01
The following targets are not supported as TFM support is not yet included:
ARM_MUSCA_B1, ARM_MUSCA_B1_NS, ARM_MUSCA_S1, ARM_MUSCA_S1_NS.
Refactor all Toshiba targets to be CMake buildsystem targets. This removes
the need for checking MBED_TARGET_LABELS repeatedly and allows us to be
more flexible in the way we include MBED_TARGET source in the build.
A side effect of this is it will allow us to support custom targets
without breaking the build for 'standard' targets, as we use CMake's
standard mechanism for adding build rules to the build system, rather
than implementing our own layer of logic to exclude files not needed for
the target being built. Using this approach, if an MBED_TARGET is not
linked to using `target_link_libraries` its source files will not be
added to the build. This means custom target source can be added to the
user's application CMakeLists.txt without polluting the build system
when trying to compile for a standard MBED_TARGET.
Refactor all Freescale targets to be CMake buildsystem targets. This removes
the need for checking MBED_TARGET_LABELS repeatedly and allows us to be
more flexible in the way we include MBED_TARGET source in the build.
A side effect of this is it will allow us to support custom targets
without breaking the build for 'standard' targets, as we use CMake's
standard mechanism for adding build rules to the build system, rather
than implementing our own layer of logic to exclude files not needed for
the target being built. Using this approach, if an MBED_TARGET is not
linked to using `target_link_libraries` its source files will not be
added to the build. This means custom target source can be added to the
user's application CMakeLists.txt without polluting the build system
when trying to compile for a standard MBED_TARGET.
This removes the need for checking MBED_TARGET_LABELS repeatedly and allows us to be
more flexible in the way we include MBED_TARGET source in the build.
A side effect of this is it will allow us to support custom targets
without breaking the build for 'standard' targets, as we use CMake's
standard mechanism for adding build rules to the build system, rather
than implementing our own layer of logic to exclude files not needed for
the target being built. Using this approach, if an MBED_TARGET is not
linked to using target_link_libraries its source files will not be
added to the build. This means custom target source can be added to the
user's application CMakeLists.txt without polluting the build system
when trying to compile for a standard MBED_TARGET.
Refactor all NXP targets to be CMake build system targets. This removes
the need for checking MBED_TARGET_LABELS repeatedly and allows us to be
more flexible in the way we include MBED_TARGET source in the build.
A side effect of this is it will allow us to support custom targets
without breaking the build for 'standard' targets, as we use CMake's
standard mechanism for adding build rules to the build system, rather
than implementing our own layer of logic to exclude files not needed for
the target being built. Using this approach, if an MBED_TARGET is not
linked to using target_link_libraries its source files will not be
added to the build. This means custom target source can be added to the
user's application CMakeLists.txt without polluting the build system
when trying to compile for a standard MBED_TARGET.
Refactor all Renesas targets to be CMake buildsystem targets. This removes
the need for checking MBED_TARGET_LABELS repeatedly and allows us to be
more flexible in the way we include MBED_TARGET source in the build.
A side effect of this is it will allow us to support custom targets
without breaking the build for 'standard' targets, as we use CMake's
standard mechanism for adding build rules to the build system, rather
than implementing our own layer of logic to exclude files not needed for
the target being built. Using this approach, if an MBED_TARGET is not
linked to using `target_link_libraries` its source files will not be
added to the build. This means custom target source can be added to the
user's application CMakeLists.txt without polluting the build system
when trying to compile for a standard MBED_TARGET.
Add code concerning all STM32WL55JC platforms
- system clock, pin and peripheral definition
mbedtools make file
Modify CmakeList to adapt to mbedtools evolution
Add code concerning all STM32WL55xC platforms
- Scatter loader and start-up files for
ARM, GCC and IAR compilers.
- cmsis file
- Update CMakeLists.txt due to mbtools evolution
Refactor all ST targets to be CMake buildsystem targets. This removes
the need for checking MBED_TARGET_LABELS repeatedly and allows us to be
more flexible in the way we include MBED_TARGET source in the build.
A side effect of this is it will allow us to support custom targets
without breaking the build for 'standard' targets, as we use CMake's
standard mechanism for adding build rules to the build system, rather
than implementing our own layer of logic to exclude files not needed for
the target being built. Using this approach, if an MBED_TARGET is not
linked to using `target_link_libraries` its source files will not be
added to the build. This means custom target source can be added to the
user's application CMakeLists.txt without polluting the build system
when trying to compile for a standard MBED_TARGET.
they have two RAMs at two distinct locations:
RAM1 (address: MBED_RAM_START, size: MBED_RAM_SIZE):
* stack
* heap
* some part of static memory
RAM2 (address: MBED_IRAM2_START, size: MBED_IRAM2_SIZE):
* remaining part of static memory starting at MBED_IRAM2_START
* crash report
* vector
The heapsize 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.
The stack start address should be the top of the RAM which is also fixed.
Each variant now has its own system_clock.c file.
Therefore ensure the correct one is added for each variant.
Also reduce the number of CMakeLists.txt file as each
variant does not have significant number of files.
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.
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.
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.
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.
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.
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.
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
#13474 for more information.
Targets that inherit from this target will have the defines necessary to
place the WiFi firmware in external storage and enable use of the
external WiFi firmware reserved region block device.
Currently, the only target inheriting from this new target is
CY8CPROTO-062S3-4343W.
This change allows external memory to be used for other purposes while
the WiFi firmware is stored in it by interacting with it via the
reserved region block device.
Given an underlying block device and the size of the reserved region, a
CyReservedRegionBlockDevice will act as the underlying block device but
operating only outside of the reserved region. It also allows reading
from the reserved region. The reserved region is assumed to start at
address 0 in the underlying block device.
In some toolchains, in order to use linker symbols referring to the
start and end of a region, the region name must not contain a '.'
character. These changes allow those symbols to be used for the cy_xip
region by renaming it. They also create explicit start and end symbols
for GCC.
Add targets subdirectory to high level CMake configuration file and
create new configurations for MCUs and individual targets. Change the
interpreter in the ARM scatter file to armclang, which is required for
CMake. Remove private and public interfaces in emac target
configuration. Ensure that all targets build on the arm gcc compiler and
arm compiler.
* Fix CMake syntax errors
* Fix indentation
* List directories and source files in alpahabetical order with spaces between files located in different directories
* Create STARTUP_FILE variable as done for all other targets
Add configuration files for targets and individual MCUs. Add include
paths and sources to mbed-core link library and specify linker and
startup scripts.
MicroLib is the lightweight C lib for the Arm toolchain and
used as the default C lib on bare metal builds with the Arm
toolchain. It requires two separate memory regions for stack
and heap.
The change is based on nRF52840.sct.
The clock source selection of LPUART depends on System clocks but also on
the serial baudrate. There is a specific computation done in serial driver
targets/target_STM/serial_api.c
At first start-up the LPUART1 clock selected in SetSysClock was anyway
overridden by the serial driver, so this was of no effect. But in case
of deep sleep SetSysClock is called again, while the driver isn't, so
SetSyClock was corrupting the serial clock configuration.
So let's remove these few lines of code which are causing trouble.
For targets L496 and L5.
Taking into account device TRNG in L5 configuration