The NXP LPC2xxx parts include a small amount of on-chip SRAM, and a limited amount of on-chip Flash. Specific capacities vary between parts. The SRAM is generally too small to be useful to RedBoot and some form of external RAM is employed if remote debugging is required, although some limited applications can be run if a GDB stub ROM image is programmed to internal Flash instead. Otherwise for processor models with no external RAM, applications must be programmed directly to internal Flash. The platform HAL may opt to use the SRAM to store the interrupt vectors mapped to address 0, or as a buffer for reprogramming internal flash when using the LPC2xxx Flash driver. The on-chip Flash is generally sufficient to include RedBoot or a GDB stub ROM image, although the on-chip SRAM may not be - again consult the platform HAL documentation. At this time, there is no support for initial programming of the on-chip Flash and so the NXP LPC2000 Flash Utility, Flash Magic or a JTAG/ICE is generally used for this.
Typically, an eCos platform HAL port will expect a RedBoot image to be programmed into the LPC2xxx on-chip Flash memory for development, and the board would boot this image from reset. RedBoot provides gdb stub functionality so it is then possible to download and debug stand-alone and eCos applications via the gdb debugger using serial interfaces or other debug channels.
The LPC2xxx variant HAL supports basic polled HAL diagnostic I/O over either of the
two on-chip serial devices. There is also a fully interrupt-driven serial device driver
suitable for eCos applications for both on-chip serial devices.
The serial driver consists of two eCos packages:
CYGPKG_IO_SERIAL_GENERIC_16X5X which is a “generic”
package for 16x5x compatible serial devices; and
CYGPKG_IO_SERIAL_ARM_LPC2XXX which provides more
specific definitions for the LPC2xxx on-chip serial devices.
Using the HAL diagnostic I/O support, either of these devices
can be used by RedBoot for communication with the host. If you are only using
UART 0, a small amount of memory can be saved by reducing the number of
communication channels with the CDL option
CYGNUM_HAL_VIRTUAL_VECTOR_COMM_CHANNELS from 2 to 1 if the platform
HAL permits this. It is not possible to enable UART 1 but not UART 0 at this time.
If a serial device is needed by the application, either directly or via the serial
driver, then it cannot also be used for RedBoot communication with the HAL
I/O support. The alternative serial port should be used instead, if available
on the platform. The serial driver supports the line status and modem control
(including hardware handshaking) lines on UART 1 only.
A device driver is included for the on-chip watchdog device. This driver
allows the use of the standard eCos watchdog API accessible with the
CYGPKG_IO_WATCHDOG eCos package. If the watchdog is
not reset within a time period defined in the watchdog device driver CDL,
an interrupt is generated and a user-supplied function called. Alternatively
it may be configured to automatically reset the system.
The watchdog device is also used to implement reset functionality, such as required by the RedBoot reset command. It may also be called directly by applications using the following function:
#include <cyg/hal/hal_diag.h> extern void hal_lpc2xxx_reset_cpu(void);
Support is provided for the on-chip RTC (wallclock) device. This allows the
use of the standard eCos wallclock API accessible with the
eCos package. The wallclock is also used by other eCos subsystems such as the
C library and POSIX compatibility layer to provide calendar time functionality.
eCos manages the on-chip Vectored Interrupt Controller (VIC). The VIC is only configured to use interrupts in non-vectored mode.
Timer 0 is used to implement the eCos system clock. If the gprof
CYGPKG_PROFILE_GPROF, is included in the
configuration, then timer 1 is reserved for use by the profiler.
Any remaining timers are available for application use.
The on-chip I²C bus devices are supported by the NXPI2C driver
CYGPKG_DEVS_I2C_NXPI2C. Platform HALs need
to enable the attached buses and define the clock speed and lines to
be used for SDA and SCL.
The on-chip SSP SPI devices (not the Legacy SPI device) are supported
by the PL022 driver package,
CYGPKG_DEVS_SPI_ARM_PL022. This needs some
configuration in the platform HAL to enable the attached buses and
define the GPIO lines used for chip select.