Delete STM32F401XE.ld ...

Duplicate file causing collisions when cloning the repo on a case-insensitive OS (e.g. Windows).

STM32F4: standard pin names

Updated TARGET_STM32 PeripheralPins.c and PeripheralPinMaps.h Replaced GPIO_PULLUP with GPIO_NOPULL in PinMap_PWM table

Update UART pin names & add MBED_CONF_TARGET_STDIO_UART overrides

Add standard pin-names validation script & tests

STM32F4: STM32Cube_FW_F4_V1.26.0 - Subfamilies

STM32F4: license header alignment

STM32F4: move common files

CMake STM32: fix missing mbed for some nucleo targets

CMake STM32: fix targets naming ...

Follow the naming for other CMake targets, using prefix mbed-, lower case with dashes

cmake: Refactor ST targets ...

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.

CMake: add STM32F4 targets

CMake: add mbed-os and mbed-baremetal targets ...

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.

CMake: Rename CMake targets ...

* mbed-os renamed mbed-core
* mbed-os-<COMPONENT> renamed mbed-<COMPONENT>

CMake: replace usage of the mbed_add_cmake_directory_if_labels() function (#13754) ...

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().

CMake: Add support for NUCLEO_F401RE

Add SPDX license identifier to Arm files ...

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.

stack: armc: Workaround config passing bug ...

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.

Use boot stack size from config system ...

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

STM32F4 baremetal support

STM32 rename TOOLCHAIN_ARM_STD into TOOLCHAIN_ARM

STM32F4 code cleaning

ST Boards: Remove uARM tooolchain support ...

For NUCLEO_F401RE, NUCLEO_F411RE, NUCLEO_F303RE, and DISCO_L475VG_IOT01A:
* Ensure the scatter files for the ARM toolchain use 2 region memory model.
  The scatter files changes affects the following boards:
    * NUCLEO_F401RE, STEVAL_3DP001V1 (stm32f401xe.sct)
    * NUCLEO_F411RE, MTS_MDOT_F411RE, MTS_DRAGONFLY_F411RE, MTB_MTS_DRAGONFLY, SAKURAIO_EVB_01 (stm32f411re.sct)
    * NUCLEO_F303RE, NUCLEO_F303ZE (stm32f303xe.sct)
    * DISCO_L475VG_IOT01A, MTB_STM_L475 (stm32l475xx.sct)
* Remove the TOOLCHAIN_ARM_MICRO directories.
* Remove release_version as not necessary and as the targets can also run
  Mbed OS 6.
* Remove uARM support for all FAMILY_STM32 targets.

STM32F4 V1.19.0 -> V1.25.0 : adaptation

STM32F4 restructuration for better maintenance

Merge pull request #11675 from jeromecoutant/PR_USB_STEP1 ...

STM32 USB update step 1

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.

STM32F4 USB pins addition

TARGET_STM: Add DEVICE_SPI_COUNT to use SPIs without interference ...

Extend to all STM targets the work done on PR10752.

Signed-off-by: Vincent Veron <vincent.veron@st.com>

STM32: common cmsis.h and device.h