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.
The package CYGPKG_DEVS_FLASH_KINETIS (“Kinetis
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 the cyg/hal/hal_cache.h header file to describe cache support to the generic eCos code. Some Kinetis K series parts have access to a Cortex-M4 core cache (the 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 functions.
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
Note: The use of the default Cortex-M architecture
HAL_MEMORY_BARRIERmacro requires that the CPU core supports the barrier instructions (ID_ISAR4[19..16] is not 0). This is the case for the Freescale Kinetis family.
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 interfaces, CYGINT_HAL_FREESCALE_UART0 to 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 diagnostic use.
The Kinetis UARTs provide TX and RX data lines plus hardware flow control using RTS/CTS for those UARTs that have the signals available on the platform hardware.
Note: The UART0 and UART1 devices are clocked from the main core clock, with the remaining UARTs clocked from the bus clock. This can affect baud rate accuracy at higher configured speeds depending on the main CPU clock configuration, and the physical UART being used.
The Kinetis HAL relies on the architectural HAL to provide support for the interrupts directly routed to the NVIC. The cyg/hal/var_intr.h 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 A to F.
This gives the bit or pin number within the port. These are numbered from 0 to 31.
This paramater specifies how the pin should be used, and should be in the range 0 to 7. The value 0 corresponds to the pin being disabled (Analog), with 1 used to specify GPIO control. The other values 2 to 7 are 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 the
cnfvalue are defined as per the relevant Kinetis Reference Manual.
The macro 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 file <cyg/hal/var_io_gpio.h> (also present in the include 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 is PIT0, which is one of the basic periodic interrupt timers, leaving the more complex timers for application code. The timer used is selected by the CYGHWR_HAL_CORTEXM_KINETIS_PROFILE_PIT_CHANNEL configuration option. This timer is only enabled when the gprof profiling package (CYGPKG_PROFILE_GPROF) is 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.