| Configuration | ||
|---|---|---|
 | Chapter 249. IAR KickStart Card Support |  |
Name
Configuration — Platform-specific Configuration Options
Overview
The IAR KickStart platform HAL package is loaded automatically when eCos is
configured for a target which uses it. The target names include the LPC2xxx
model in use. At this time the only target supported is the
iar_kickstart_lpc2106 target. It should never be
necessary to load this platform HAL package explicitly. Unloading the
package should only happen as a side effect of switching target hardware.
Startup
The IAR KickStart platform HAL package supports three separate startup types:
- ROM
- This startup type can be used for finished applications which will be programmed into internal flash at location 0x0. The application will be self-contained with no dependencies on services provided by other software. eCos startup code will perform all necessary hardware initialization. On targets with less than 64Kbytes of SRAM, this is the startup type normally used.
- RAM
- This is the startup type which is normally used during application development on targets with 64Kbytes of SRAM or greater. The board has the GDB stubrom or RedBoot programmed into flash at location 0x0 in internal on-chip Flash and boots from that location. arm-eabi-gdb is then used to load a RAM startup application into memory and debug it. It is assumed that the hardware has already been initialized by the ROM monitor. By default the application will use the eCos virtual vectors mechanism to obtain certain services from the ROM monitor, including diagnostic output. Larger applications may not fit into the available SRAM, in which case ROM startup may be required.
- JTAG
-
This is an alternative development startup type. The application is
loaded into RAM via a JTAG device and is run and debugged from
there. The application will be self-contained with no dependencies on
services provided by other software. It is expected that hardware
setup will have been performed via the JTAG device prior to loading.
Some sample configuration and initialisation scripts for a number
of JTAG debugging solutions may be found in the
miscsubdirectory of the platform HAL package within the component repository.
The ROM Monitor and Virtual Vectors
If the application is intended to act as a ROM monitor, providing
services for other applications, then the configuration option
CYGSEM_HAL_ROM_MONITOR should be set. Typically
this option is set only when building the GDB Stubrom or RedBoot.
If the application is supposed to make use of services provided by a
ROM monitor, via the eCos virtual vector mechanism, then the
configuration option CYGSEM_HAL_USE_ROM_MONITOR
should be set. By default this option is enabled when building for a
RAM startup, disabled otherwise. It can be manually disabled for a RAM
startup, making the application self-contained, or as a testing step
before switching to ROM startup. Virtual vector support is usually
only required for RAM startup applications or ROM monitors. The
CDL option CYGFUN_HAL_LPC2XXX_VIRTUAL_VECTOR_SUPPORT
within the LPC2xxx variant HAL allows manual control of this facility.
If the application does not rely on a ROM monitor for diagnostic services
then by default serial port UART0 will be claimed for HAL diagnostics. If
using the Prototype Board, it becomes possible to use UART1 as well, and in
order to allow its selection as a potential debug or diagnostic channel, the
number of communications channels can be increased from 1 to 2 with the
option CYGNUM_HAL_VIRTUAL_VECTOR_COMM_CHANNELS. To
specify which serial port is used for diagnostics, the configuration
option CYGNUM_HAL_VIRTUAL_VECTOR_CONSOLE_CHANNEL may be
set accordingly, and its baud rate configured with
CYGNUM_HAL_VIRTUAL_VECTOR_CONSOLE_CHANNEL_BAUD.
System Clock
By default, the system clock interrupts once every 10ms, corresponding to a
100Hz clock. This can be changed by the configuration option
CYGNUM_HAL_RTC_DENOMINATOR which corresponds to the clock
frequency. Other clock-related settings are recalculated automatically if
the denominator is changed. The PLL multiplier may be configured to allow a
core clock (CCLK) speed of up to 60MHz. The description of the clock-related
CDL options may be found in the LPC2xxx variant HAL documentation. Note
there are frequency constraints on the Current Controlled Oscillator (CCO)
within the LPC2xxx, and the datasheet should be consulted to ensure the
required specifications are not exceeded.
Compiler Flags
The platform HAL defines 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.
However there are two flags that are used if Thumb mode is to be supported:
-
-mthumb -
The arm-eabi-gcc compiler will compile
C and C++ files into the Thumb instruction set when this option is used.
To build eCos in Thumb mode, enable the
CYGHWR_THUMBconfiguration option in the ARM architecture HAL. -
-mthumb-interwork -
This option allows programs to be created that mix ARM and Thumb instruction
sets. For example, allowing a Thumb application to be used with eCos built in
normal ARM mode. Without this option, some memory can be saved. This option should
be used if -mthumb is used. eCos may be built with Thumb interworking
support by enabling the
CYGBLD_ARM_ENABLE_THUMB_INTERWORKCDL option in the ARM architecture HAL. Use of the LPC2xxx Flash driver requires Thumb interworking support to be enabled as the calls into the IAP firmware are must be made allowing a switch to Thumb mode.
| |  | |
| Setup |  | The HAL Port |
| 2024-12-10 | eCosPro Non-Commercial Public License |