On-chip Subsystems and Peripherals — Hardware Support
The Freescale Kinetis parts include on-chip SRAM, and on-chip FLASH. The SRAM and FLASH can vary in size depending on the model. There is also support in some models for external memory, which eCos may use where available.
Typically, an eCos platform HAL port will expect a GDB stub ROM monitor or RedBoot image to be programmed into the Kinetis on-chip FLASH memory for development, and the board would boot this image from reset. The stub ROM/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 JTAG interface may also be used for development if a suitable JTAG device is available. If RedBoot is present it may also be used to manage the on-chip and external flash memory. For production purposes, applications are programmed into external or on-chip FLASH and will be self-booting.
FLASH memory support”) provides a driver for the on-chip flash. This
driver conforms to the Version 2 flash driver API, and is
automatically enabled if the generic “Flash device drivers”
CYGPKG_IO_FLASH) package is included in the eCos
configuration. The driver will configure itself automatically for the
size and parameters of the specific Kinetis variant which has been
selected in the eCos configuration.
The variant HAL supplies
file to describe cache support to the generic eCos code. Some Kinetis
K series parts have access to a Cortex-M4 core cache
CYGINT_HAL_CACHE will be defined by the
platform if appropriate). If the configured part does not provide a
cache then the header will supply null macros for the required
When a cache is available the HAL currently supports a 16KiB cache, split into a 8KiB data cache and a 8KiB instruction cache.
The architecture HAL also defines a macro
which acts to synchronize the pipeline, delaying execution until all
previous operations, including all pending writes, are complete. This
will usually be necessary when interacting with devices that access
The use of the default Cortex-M
The Kinetis variant HAL supports basic polled HAL diagnostic I/O over
any of the on-chip serial devices. There is also a fully
interrupt-driven serial device driver suitable for eCos applications
for all on-chip serial devices. The serial driver consists of an eCos
provides all support for the Kinetis on-chip serial devices. Using
the HAL diagnostic I/O support, any of these devices can be used by
the ROM monitor or RedBoot for communication with GDB. If a device is
needed by the application, either directly or via the serial driver,
then it cannot also be used for GDB communication using the HAL I/O
support. An alternative serial port should be used instead.
The HAL defines CDL
CYGINT_HAL_FREESCALE_UART5 for each of the
available UARTs. The platform HAL CDL should contain
an implements directive for each such UART that is
available for use on the board. This will enable use of the UART for
The Kinetis UARTs provide
RX data lines plus hardware flow control
CTS for those UARTs
that have the signals available on the platform hardware.
The Kinetis HAL relies on the architectural HAL to provide support for
the interrupts directly routed to the
header defines the vector mapping for these.
The variant HAL provides support for packaging the configuration of a GPIO line into a single 32-bit descriptor that can then be used with macros to configure the pin and set and read its value. This is useful to drivers and other packages that need to configure and use different I/O lines for different devices.
A descriptor is created with
macro, where the parameters required are:
This identifies the GPIO port to which the pin is attached. Ports are
identified by the letters from
This gives the bit or pin number within the port. These are numbered
This paramater specifies how the pin should be used, and should be in
7. The value
0corresponds to the pin being disabled (Analog), with
1used to specify GPIO control. The other values
7are used to indicate alternative function mappings as defined by the CPU variant.
This option allows explicit Port Control register configuration
settings to be specified. The bits as held in
cnfvalue are defined as per the relevant Kinetis Reference Manual.
CYGHWR_HAL_KINETIS_PIN_NONE may be used
in place of a pin descriptor and has a value that no valid descriptor
can take. It may therefore be used as a placeholder where no GPIO pin
is present or to be used. This can be useful when defining pin
configurations for a series of instances of a peripheral (e.g. UART
ports), but where not all instances support all the same pins
(e.g. hardware flow control lines).
the pin according to the descriptor and must be called before other
GPIO operations are performed on the pin.
The macros to manipulate GPIO state all take a suitably constructed
GPIO pin descriptor as an argument.
It is recommended to consult the header
(also present in the
subdirectory of the Kinetis variant HAL package within the eCos source
repository), for the complete list if needed.
eCos includes a RTC (known in eCos as a wallclock) device driver for
the on-chip RTC in the Kinetis family. This is located in the
The Kinetis HAL contains support for gprof-based
profiling using a sampling timer. The default timer used
PIT0, which is one of the basic periodic
interrupt timers, leaving the more complex timers for application
code. The timer used is selected by
configuration option. This timer is only enabled when the gprof
profiling package (
included and enabled in the eCos configuration, otherwise it remains
available for application use.
The CDL section
contains many options to configure the various Kinetis on-chip clocks,
based on platform supplied default values. The CDL will calculate the
frequency value, which in turn is used in conjunction with the
configured clock divider values to set the frequencies of the relevant
The actual calculated values of the main clocks, in Hz, are stored in
the global variables
hal_kinetis_busclk. The clock supplied to the
Cortex-M SysTick timer,
HCLK/8, is also assigned to
hal_cortexm_systick_clock. These variables
are used, rather than configuration options, in anticipation of future
support for power management by varying the system clock rate.
Note that when changing or configuring any of these clock settings, you should consult the relevant processor datasheet as there may be both upper and lower constraints on the frequencies of some clock signals, including intermediate clocks. There are also some clocks where, while there is no strict constraint, clock stability is improved if values are chosen wisely. Finally, be aware that increasing clock speeds using this package may have an effect on platform specific properties, such as memory timings which may have to be adjusted accordingly.
|2019-09-17||eCosPro Non-Commercial Public License|