STM32WB: improve FLASH size ...

Default BLE FW in ST boards is stm32wb5x_BLE_Stack_full_fw.bin
 and gives 808K available FLASH to application

stm32wb5x_BLE_HCILayer_fw.bin
 gives 896K available FLASH to application

STM32WB : TARGET_STM32WB_V1.11.1

STM32WB : change subfamily name ...

STM32WB50xx => STM32WB50xG
STM32WB55xx => STM32WB55xG
STM32WB5Mxx => STM32WB5MxG

STM32WB - New directory structure

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.

STM32WB 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

Merge pull request #10570 from jeromecoutant/PR_ASTYLE ...

STM32 astyle updates

STM32 astyle updates

Typo fix for MBED_APP_SIZE

Update FLASH_SIZE backup value ...

By default, FLASH_SIZE should be read from HW.
In case this is not the case, we define it here, as the size of FLASH
that is available to the application running on M4.

STM32WB: Update Flash size ...

the flash is shared and split between cortex-M4 that
runs (mbed-os) application and the cortex-M0+ that
runs the BLE firmware.

The 512K allocated to the application was a
conservative that can now be updated.

With recent up-to-date BLE firmware flashed @ 0x080CB000,
there should be 812K available to application.

But there are boards out there that don't have an up-to-date
firmware, so we're keeping an intermediate, safer,
application size of 768K.

STM32WB: Only configure default peripherals in SetSysClock ...

Typically the RTC clock is configured by RTC driver itself.

RNG on the other hand is shared with M0+ core and it is expected that
M4 turns it on at boot time.

STM32WB: update deep sleep sequence ...

Review HSE clock initialization to match with latest CUBE firmware.
Also there is no need to set the full clock tree again after deep sleep exit.

With this change we get a stable deep sleep mode (when allowed by CORDIO stack).

STM32WB: update GCC linker script to match with master

STM32WB: Add SPDX identifier to new files ...

also update the copyright year when needed

STM32WB: ARM linker script update ...

There is no need to add FIRST attribute to MAPPING_TABLE as the default
ordering is alphabetical order.

With this change, we don't have any warning with MBED2 and the sections
are properly ordered anyway in BLE cases.

STM32WB: Fix ARM link error in mbed2 ...

In case of mbed2, BLE feature is not built.

As there is a MAPPING_TABLE in BLE feature which is not compiled in case
of mbed2, the linker reported the below error

[ERROR] "C:/Data/Workspace/mbed/BUILD/test/NUCLEO_WB55RG/ARM/MBED_2/
.link_script.sct", line 65 (column 6): Error: L6236E:
No section matches selector - no section to be FIRST/LAST.

Solution is to check whether BLE is enabled.

fixup! NUCLEO_WB55RG: add SDK files

NUCLEO_WB55RG: Rework Clock and sleep support ...

- move hw_conf.h file to targets/TARGET_STM/TARGET_STM32WB directory as
this is used also out of BLE feature.
- create a dedicated hal_deepsleep function as the behavior in WB is a lot
different from other existing STM32 targets
- update clock tree configuration to directly clock the entire tree @ 32MHz
out of HSE. This is needed as we want to let the M0 core running without
any change on M0-side of clocks when M4 enters /exits deep sleep.

NUCLEO_WB55RG: HAL API updates to get SLEEP, RTC and LPTICKER OK ...

- astyle OK
- file alignment with other families
- HSE, MSI, HSI clock support
- LPTICKER with RTC and LPTIM tested

NUCLEO_WB55RG: update STM common files ...

- Include RTC ll file from hal as in other families
- STM32WB: update Flash API driver

NUCLEO_WB55RG: IAR, ARM and GCC linker files alignment ...

Align all scatter BLE shared memory declarations.

NUCLEO_WB55RG: add SDK files ...

- Contains files from STM32Cube_FW_WB_V1.0.0