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 CYGPKG_IO_WALLCLOCK 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 package, 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 variant HAL contains a driver for the on-chip I²C bus devices. Platform HALs need to define the clock speed and lines to be used for SDA and SCL using the following options:
This is the master component, enabling this activates all the other configuration options and causes the driver to create the data structures to access this bus.
Bus clock speed in Hz. Usually frequencies of either 100kHz or 400kHz are chosen, the latter sometimes known as fast mode.
This option describes the pin used for SDA on this bus. This takes the form of an invocation of the macro __LPC2XXX_PINSEL_FUNC. Parameters are the port number, pin within that port, and the alternate select function for the pin. See the LPC2468 user manual for details of which pins may be used by each bus.
This option describes the pin used for SCL on this bus. Like SDA this takes the form of a call to __LPC2XXX_PINSEL_FUNC.
Note that "I2CX" is a placeholder for a given bus instance: "I2C0", "I2C1" or "I2C2".
The on-chip SSP SPI devices (not the Legacy SPI device) are supported by the NXPSSP driver package, CYGPKG_DEVS_SPI_ARM_NXPSSP. This needs some configuration in the platform HAL:
This is the master component, enabling this activates all the other configuration options. It also causes ea_lpc2468_spi.c to be compiled, which contains descriptions of the devices on the SPI buses.
This is the master component for each bus. Enabling thi activates the other configuration options for this bus, and causes the driver to support this bus.
This option describes the pin used for SCLK on SPIX. It takes the form of an invocation of __LPC2XXX_PINSEL_FUNC. The parameters are the port number, pin within that port, and the alternate select function for the pin. See the LPC2468 user manual for details."
This option describes the pin used for MISO on SPIX. Like SCLK it takes the form of a call to __LPC2XXX_PINSEL_FUNC.
This option describes the pin used for MOSI on SPIX. Like SCLK it takes the form of a call to __LPC2XXX_PINSEL_FUNC.
This defines the pins to be uses as chip selects for this bus. It is a comma separated list of GPIO pin names, the first for device 0, the second for device 1, and so on. Pin names are defined in the var_io.h header in the LPC2xxx variant HAL.
Note that "SPIX" is a placeholder for a given bus instance: "SPI0" or "SPI1".