Name

On-chip Subsystems and Peripherals — Hardware Support

Hardware support

On-chip memory

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.

On-chip FLASH

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.

Cache Handling

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 HAL_MEMORY_BARRIER() 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 memory directly.

[Note]Note

The use of the default Cortex-M architecture HAL_MEMORY_BARRIER macro 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.

Serial I/O

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 package: CYGPKG_IO_SERIAL_FREESCALE_UART which 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]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.

Interrupts

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.

GPIO

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 the CYGHWR_HAL_KINETIS_PIN(port,bit,mux,cnf) macro, where the parameters required are:

port
This identifies the GPIO port to which the pin is attached. Ports are identified by the letters from A to F.
bit
This gives the bit or pin number within the port. These are numbered from 0 to 31.
mux
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.
cnf
This option allows explicit Port Control register configuration settings to be specified. The bits as held in the cnf value 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 function hal_set_pin_function(pin) configures 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.

RTC/Wallclock

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 package CYGPKG_DEVICES_WALLCLOCK_KINETIS_RTC (“Real-time clock”).

Profiling Support

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.

Clock Control

The CDL section CYGHWR_HAL_CORTEXM_KINETIS_CLOCKING contains many options to configure the various Kinetis on-chip clocks, based on platform supplied default values. The CDL will calculate the main CYGNUM_HAL_CORTEXM_KINETIS_MCGOUT_FREQ frequency value, which in turn is used in conjunction with the configured clock divider values to set the frequencies of the relevant subsystems.

The actual calculated values of the main clocks, in Hz, are stored in the global variables hal_kinetis_sysclk and hal_kinetis_busclk. The clock supplied to the Cortex-M SysTick timer, HCLK/8, is also assigned to the global variable 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.