Options — Configuring the Cortex-M Architectural HAL Package
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_BIGENDIANis 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
requirescommand 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_D16when 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_FPUis 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_FPUis 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_BITSmust 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
Serialsupport being left to the variant or platform HAL.
However, if the variant provides the on-chip ITM then selecting
ITMfor 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.
discardoption 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.
|2019-09-17||eCosPro Non-Commercial Public License|