Options -- Configuring the Cortex-M Architectural HAL Package
Description
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.
CYGINT_HAL_CORTEXM_BIGENDIAN
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.
CYGHWR_HAL_CORTEXM_BIGENDIAN
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.
CYGHWR_HAL_CORTEXM
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 (not yet
supported). This option should be set using a
requires command in the variant HAL to
indicate which CPU variant is in use.
CYGNUM_HAL_CORTEXM_PRIORITY_MAX
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.
Compiler Flags
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.
Linker Scripts
The linker script, supplied by either the variant or platform
HALs, must define some symbols that the architecture HAL depends
on:
hal_vsr_table
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.
hal_virtual_vector_table
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.
hal_startup_stack
This defines the location of the startup stack. 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 at the top of memory. It is usually
placed at the top of internal SRAM since it will be accessed
before any external RAM is initialized. For RAM applications,
which are loaded after initialization is complete, it can be
placed at the top of external RAM.
