Correct heap region calculation for Maxim targets

GPIO: Use uintptr_t for gpio_irq_api context ...

The HAL gpio_irq_api stores object IDs, which serve as a form of context
for the dispatch of the interrupt handler in the drivers level
InterruptIn Class. The way this is achieved is that the InterruptIn
Class casts its address to uint32_t, which is stored as the ID.
This results in compilation failure when the size of an object pointer
is greater than uint32_t, for example when building on a PC for unit
testing.

In order to allow Unit Testing of the InterruptIn Class, we replace the
use of uint32_t with uintptr_t (type capable of holding a pointer),
which allows portability and expresses intentions more clearly.
In aid of this latter goal, we also replace the use of the name "id"
with "context", to improve clarity - these are addresses of the context
related to that callback.

Fix ARM toolchain #L6803W Relocation warnings ...

While building with ARM toolchain relocation warnings appears
This commit will fix it for MAX32625/30 targets.

The system interrupt function is defined as weak in startup file
and its overvides in other files, Becuase of the functions is overrites
while calling it in startup modile by B XXXXX probably compiler give
info purpose warnings... By using using . instead function name it says
go existing point to the compiler.
Warning detail:
https://www.keil.com/support/man/docs/armerr/armerr_dom1365073159742.htm

Signed-off-by: Sadik.Ozer <Sadik.Ozer@maximintegrated.com>

Merge pull request #14465 from harmut01/baremetal_maxim ...

Maxim: Add bare metal support to targets

Refactor definition of heap load region start

Maxim: Add bare metal support to targets ...

Add heap load region to scatter file and update `targets.json` to
provide baremetal support to the following targets: SDT32620B,
SDT32625B, MAX32620FTHR, MAX32625MBED, MAX32625PICO, and MAX32630FTHR.

typo

Update UART pin names & add MBED_CONF_TARGET_STDIO_UART overrides

Add standard pin-names validation script & tests

MAX32625: Fix CMake build ...

* Correct board CMake target name to match board name
* Make MAX32625 depend on MAXIM CMake target to inherit its include dirs
* Correct path to linker files

Apply suggestions from code review ...

Co-authored-by: Hugues Kamba-Mpiana <41612201+hugueskamba@users.noreply.github.com>

CMake Maxim: fix some errors with renames

CMake Maxim: fix targets naming ...

Add boot no-boot targets for max32625. This should be cleaned up better once we get
the folder structure enforced by the old tools fixed.

Gate ticker (timer0) clock on deepsleep

CMake: Add support for Maxim MAX32625 targets ...

Add CMakeLists.txt file to for the target family source files.

Merge pull request #13724 from harmut01/license_refactor ...

Add license notice to Arm copyrighted source files

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.

Prevent warnings during compilations for MAX32625 ...

In Mbed OS 5.12.0 mbed_toolchain.py has been introduced, that automatically defines the macro TARGET_NAME (on line 241). This leads to a high number of generating the following warning: 'TARGET_NAME' macro redefined while compiling code for MAX32625 on Mbed OS 5.12 and above. This patch fixes it, while it keeps the definition in place for lower versions that lack mbed_toolchain.py

Merge pull request #13492 from talorion/fix-PwmOut-resets-after-suspend ...

Fix pwm out resets after suspend

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

pwmout - MAX32625 - add read methods for period and pulsewidth

Remove MAX32625NEXPAQ target

Merge pull request #10924 from ghseb/free-serial-resources-2 ...

Free serial resources if not needed anymore

Add serial_free definition

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.

HAL I2C: adds missing DEVICE_I2C guards

Target_Maxim: Setup heap limit and size

Add HAL API for spi pinmap ...

Add the functions to get spi pinmaps to all targets.

Add HAL API for serial pinmap ...

Add the functions serial_tx_pinmap, serial_rx_pinmap, serial_cts_pinmap
and serial_rts_pinmap to all targets.