The AT91SAM7S-EK platform HAL package is loaded automatically when eCos is
configured for the at91sam7sek
target. It should never be
necessary to load this package explicitly. Unloading the package
should only happen as a side effect of switching target hardware.
Startup
The platform HAL package supports three separate startup types:
RAM
This is the startup type which is normally used during application
development. The board has GDB stubs programmed into flash
and boots into that initially.
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 stubs. By default the
application will use the eCos virtual vectors mechanism to obtain certain
services from the stubs, including diagnostic output.
ROM
This startup type can be used for finished applications which will
be programmed into flash at physical address 0x00100000. The application will
be self-contained with no dependencies on services provided by other
software. eCos startup code will perform all necessary hardware
initialization.
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.
GDB Stubs 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 Stubs.
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, as a testing step
before switching to ROM startup.
If the application does not rely on a ROM monitor for diagnostic
services then the serial port will be claimed for HAL
diagnostics.
Flash Driver
The AT91SAM7S-EK board contains a quantity of on-chip flash memory.
The CYGPKG_DEVS_FLASH_AT91 package contains all the
code and data definitions necessary to support this part. This driver
is not active until the generic Flash support package,
CYGPKG_IO_FLASH, is included in the configuration.
Watchdog Driver
The AT91SAM7S-EK board use the AT91SAM7S's internal watchdog support. The
CYGPKG_DEVICES_WATCHDOG_ARM_AT91WDTC package contains all the
code necessary to support this device. Within that package the
CYGNUM_DEVS_WATCHDOG_ARM_AT91WDTC_DESIRED_TIMEOUT_MS
configuration option controls the watchdog timeout, and by default will
force a reset of the board upon timeout. This driver is not active until the
generic watchdog device support package,
CYGPKG_IO_WATCHDOG, is included in the configuration.
Note that on the AT91, the on-chip watchdog peripheral always starts running
immediately, and so in configurations that do not include the watchdog
driver, it is always disabled via its write-once register. In configurations
which include the watchdog driver obviously the watchdog is not disabled
otherwise it could not be subsequently re-enabled, and so the application
must start and periodically reset the watchdog from the very beginning of
execution.
USART Serial Driver
The AT91SAM7S-EK board use the AT91SAM7S's internal USART serial support
as described in the AT91 processor HAL documentation. Two serial ports are
available: the serial debug port which is mapped to virtual vector channel 0
in the HAL diagnostic driver or "/dev/dbg" in the
interrupt-driven driver; and USART 0 which is mapped to virtual vector channel
1 and "/dev/ser0". Only USART 0 supports modem control
signals such as those used for hardware flow control.
Compiler Flags
The SAM7 variant 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. There are just three flags specific to this port:
-mcpu=arm7tdmi
The arm-eabi-gcc compiler supports many
variants of the ARM architecture.
A -m option should be used to select the specific
variant in use, and with current tools -mcpu=arm7tdmi is the
correct option for the ARM7TDMI processor in the SAM7S.
-mthumb
The arm-eabi-gcc compiler will compile
C and C++ files into the Thumb instruction set when this option is used.
The best way to build eCos in Thumb mode is to enable the configuration
option CYGHWR_THUMB.
-mthumb-interwork
This option allows programs to be created that mix ARM and Thumb instruction
sets. Without this option, some memory can be saved. This option should
be used if -mthumb is used. The best way to build eCos with Thumb interworking
is to enable the configuration option
CYGBLD_ARM_ENABLE_THUMB_INTERWORK.