Name
Configuration — Platform-specific Configuration Options
Overview
The mcb2387 platform HAL package is loaded automatically when eCos is
configured for an mcb2387
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 mcb2387 platform HAL package supports three separate startup types:
- JTAG
- This is the startup type which is normally used during JTAG based application development. arm-eabi-gdb is then used to connect to the JTAG device and load a JTAG startup application into memory and debug it. It is assumed that the basic hardware has already been initialized via the JTAG device's initialization script. Otherwise the application is entirly self contained and should contain drivers for all hardware used.
- RAM
- This is the startup type which is normally used during stubrom based application development. The board has the stubrom 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 basic 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 stubrom, including diagnostic output.
- 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.
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 stubrom.
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.
If the application does not rely on a ROM monitor for diagnostic services then serial port UART0 will be claimed for HAL diagnostics.
Flash Driver
The
CYGPKG_DEVS_FLASH_LPC2XXX
package contains
all the code necessary to support the on-chip flash.
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 multipliers and
dividers may be configured to allow a core clock (CCLK) speed of up to
72MHz. However, the platform HAL currently sets the clock to 48MHz,
duplicating the configuration in the supplied example code as a
consequence of CPU errata affecting various revisions of the LPC2387.
Setting the CPU revision with the
CYGHWR_HAL_ARM_LPC2XXX_MCB2387_CPU_REVISION
configuration option can be used to provide default clock settings
appropriate to the CPU revision in use. If the CPU revision cannot be
guaranteed it should be left as "Initial". The description of the
clock-related CDL options may be found in the LPC2xxx variant HAL
documentation.
I²C Bus Configuration
The on-chip I²C devices are supported by a driver in the variant HAL package. Each bus for this driver needs to be configured in the platform HAL with the following options:
-
CYGPKG_HAL_ARM_LPC2XXX_I2CX
- 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.
-
CYGPKG_HAL_ARM_LPC2XXX_I2CX_CLOCK
- Bus clock speed in Hz. Usually frequencies of either 100kHz or 400kHz are chosen, the latter sometimes known as fast mode.
-
CYGPKG_HAL_ARM_LPC2XXX_I2CX_SDA
- 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 LPC2387 user manual for details of which pins may be used by each bus.
-
CYGPKG_HAL_ARM_LPC2XXX_I2CX_SCL
- 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". By default the platform HAL does not enable any I²C buses since there are no on-board devices.
SPI Bus Configuration
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:
-
CYGPKG_HAL_ARM_LPC2XXX_SPI
-
This is the master component, enabling this activates all the
other configuration options. It also causes
mcb2387_spi.c
to be compiled, which contains descriptions of the devices on the SPI buses. -
CYGPKG_HAL_ARM_LPC2XXX_SPIX
- This is the master component for each bus. Enabling this activates the other configuration options for this bus, and causes the driver to support this bus.
-
CYGPKG_HAL_ARM_LPC2XXX_SPIX_SCLK
- 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 LPC2387 user manual for details."
-
CYGPKG_HAL_ARM_LPC2XXX_SPIX_MISO
- This option describes the pin used for MISO on SPIX. Like SCLK it takes the form of a call to __LPC2XXX_PINSEL_FUNC.
-
CYGPKG_HAL_ARM_LPC2XXX_SPIX_MOSI
- This option describes the pin used for MOSI on SPIX. Like SCLK it takes the form of a call to __LPC2XXX_PINSEL_FUNC.
-
CYGPKG_HAL_ARM_LPC2XXX_SPIX_CS_PINS
-
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". By default the platform HAL does not enable any SPI busses since there are on on-chip devices.
MCI peripheral configuration
The on-chip Multimedia Card Interface (MCI) is supported to allow access
to Multimedia Cards (MMC) or Secure Digital (SD) cards using the socket
on the board. This support is provided in conjunction with the
generic MMC/SD driver package (CYGPKG_DEVS_DISK_MMC
),
the Primecell MCI driver package
(CYGPKG_DEVS_MMCSD_ARM_PRIMECELL_MCI
) and the LPC2xxx
variant HAL in order to provide some elements of the DMA support.
Documentation and configuration options within those packages should
also be consulted.
The following CDL configuration options are used to control the behaviour of the MMC/SD card support:
- MMC/SD card support (
CYGPKG_HAL_ARM_LPC2XXX_MCB2387_MCI
) -
This option allows the MMC/SD card support as a whole to be enabled or
disabled, although the generic disk device driver package
(
CYGPKG_IO_DISK
) must be loaded in order to enable the MMC/SD support. - Use on-chip USB memory for DMA (
CYGSEM_HAL_ARM_LPC2XXX_MCB2387_MCI_USE_USB_MEM_FOR_DMA
The LPC2387 cannot always keep up with the data transfer requirements, especially at slower CPU clock speeds. This is because the DMA controller runs at the speed of the CPU clock (CCLK) along with the fact that some LPC2387 have errata which decreases their achievable CPU clock frequency.
Using on-chip memory dedicated to USB helps reduce or remove these problems, depending on CPU frequency. Clearly this option must be disabled if the on-chip USB peripheral is to be used. It is also desirable to disable this option if the CPU frequency is high enough, in order to remove an extra copy on every data transfer, thus improving performance. The USB memory used is 512 bytes at the start of the USB memory space (0x7FD00000).
If this option is disabled and the DMA is not able to proceed quickly enough, this will be visible in the form of I/O errors. In that case, if it is not possible to enable this option it is recommended to adjust the
CYGDAT_HAL_ARM_LPC2XXX_MCB2387_MCI_BUS_SPEED_LIMIT
configuration option.- Lock AHB bus during DMA transfer (
CYGSEM_HAL_ARM_LPC2XXX_MCB2387_MCI_DMA_LOCKS_AHB
) The AMBA Hardware Bus (AHB) is used to connect AMBA peripherals within the LPC2387, including the ARM core, DMA controller and memory controllers. When this option is enabled, the AHB is locked for the duration of MCI DMA transfer bursts. If another AMBA host needs to make a transfer it may be delayed as a result, which may not be desirable.
Disabling this option allows the AHB arbiter to permit other AHB hosts to perform transfers. Of course this may mean the MCI DMA transfers can in turn themselves get delayed, risking data overruns or underruns in MCI transfers, resulting in I/O errors during block reads or writes. This is particularly likely on processors running at slower clock speeds where there may already be difficulties with the DMA servicing data transfers quickly enough.
- MMC/SD bus frequency limit (
CYGNUM_HAL_ARM_LPC2XXX_MCB2387_MCI_BUS_SPEED_LIMIT
) The LPC2387 cannot always keep up with the data transfer requirements, especially at slower CPU clock speeds. This is because the DMA controller runs at the speed of the CPU clock (CCLK) along with the fact that some LPC2387 have errata which decreases their achievable CPU clock frequency. The adjacent options to use on-chip USB memory and to lock the AHB bus can help prevent this, but sometimes they are insufficient to prevent data overruns or underruns resulting in I/O errors during block reads or writes. In which case the only remaining recourse is to reduce the required data transfer rate between the MCI and the card.
This option can be used to impose an upper limit on the MMC/SD bus frequency. The value used in this option is measured in Hertz, and the use of 4-bit mode with SD cards is not a factor - this option provides the bus frequency, so a 4-bit bus will transfer four times the amount of data as a 1-bit bus in the same time period.
Note that this option provides a limit, and does not mean the card bus will operate at that frequency. The frequency is also governed by what the card will support, and the resolution of the clock used to derive the MMC/SD clock signal, and how it can be divided down.
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.
-
-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.
2024-03-18 | eCosPro Non-Commercial Public License |