The Cortex-M architectural HAL is included in all ecos.db entries for Cortex-M targets, so the package will be loaded automatically when creating a configuration. It should never be necessary to load the package explicitly or to unload it.
The Cortex-M architectural HAL contains a number of configuration points. Few of these should be altered by the user, they are mainly present for the variant and platform HALs to select different architectural features.
This interface controls whether the CPU is run in big endian mode. It should be implemented by either the variant or platform HAL to reflect the setting of the hardware.
This option is active only if CYGINT_HAL_CORTEXM_BIGENDIAN is implemented. It provides the main test point for HAL, eCos and application code to test for a big endian target.
The Cortex-M architecture has two main variants at present. The M1 is based on the ARMV6 architecture specification and executes an extended variant of the Thumb instruction set and has some differences in the interrupt controller. The M3 and M4 are based on the ARMV7 architecture specification and execute the Thumb2 instruction set. The M4 is an extended M3 family providing hardware FPU and DSP extensions. This option should be set using a requires command in the variant HAL to indicate which CPU variant is in use.
This interface controls whether the CPU is capable of supporting a hardware FPU (Floating Point Unit). It is the “common” FPU marker and is implemented whan either the variant or platform HAL in turn implements a supported FPU type.
For example, a Cortex-M4F target may define CYGINT_HAL_FPV4_SP_D16 when it provides the ARMv7 VFPv4-D16 architecture floating point unit.
On targets which are capable of hardware FPU operation, this option is used to select whether soft or hard floating point operation is desired. It provides the main test point for HAL, eCos and application code to test for a hard-FP target. It is inactive if CYGINT_HAL_CORTEXM_FPU is not implemented.
Even though an architecture may provide a hardware FPU, it is not always suitable for all applications. For example, there is the associated scheduler and RAM cost in preserving FPU contect for multi-threaded applications. If CYGHWR_HAL_ARM_FPU is enabled then some further configuration options are made available:
Most Cortex-M variants do not implement the full range of priorities defined by the architecture. Instead they only implement a few of the most significant bits of the 8 bit priority range. The option CYGNUM_HAL_CORTEXM_PRIORITY_LEVEL_BITS must be defined by the variant HAL to give this number. This option then uses that value to calculate the maximum allowable priority for interrupts.
By default the architectural HAL does not implement diagnostic support, with the default Serial support being left to the variant or platform HAL.
However, if the variant provides the on-chip ITM then selecting ITM for this option will configure the system to use the generic architectural HAL ITM stimulus port diagnostic output. Accessing ITM diagnostic output will require corresponding support from the SWD host tools being used to connect to the hardware.
The discard option configures the system so that all diagnostic output is discarded. This can be used when no I/O channel is available for diagnostics.
If the variant includes ITM support then this option can be enabled to allow configuration of the stimulus ports to be used for HAL diagnostics or instrumentation as required.
It is normally the responsibility of the platform HAL to define the default compiler and linker flags for all packages, although it is possible to override these on a per-package basis. Most of the flags used are the same as for other architectures supported by eCos. For all Cortex-M3 targets the options "-mcpu=cortex-m3" and "-mthumb" must always be defined.
When hardware floating point support is to be used, additional flags are required, as discussed later.
The linker script, supplied by either the variant or platform HALs, must define some symbols that the architecture HAL depends on:
This defines the location of the VSR table. The address must obey the rules for locating the CPU vector table defined in the Cortex-M architecture specification. Usually it should be placed at the base of internal SRAM, at 0x20000000. The size of the table depends on the CPU variant in use.
This defines the location of the virtual vector table used to communicate between an ROM monitor and an eCos application. This table needs to be word aligned. It is usually placed in internal SRAM just after the VSR table, perhaps aligned to a convenient boundary.
This defines the location of the interrupt stack, and is assigned to the CPU's MSP register. The stack grows down so it should be placed at the top of memory. It is usually placed at the top of internal SRAM. For RAM applications, which are loaded after initialization is complete, it can be placed in external RAM.
This defines the location of the startup stack and is assiged to the CPU's PSP register. This value will be installed in slot zero of the initial vector table to be loaded automatically by the CPU on reset. The stack grows down so it should be placed near the top of memory. It is usually placed near top of internal SRAM, just below the interrupt stack. The default is to initially place this stack at the halfway point of the space allocated for the interrupt stack. This avoids allocating a unique space for it, and when the application starts it will usually move the PSP to another location, leaving all of the interrupt stack space available for the interrupts. For RAM applications, which are loaded after initialization is complete, it can be placed near the top of external RAM.