 | build 3.0.0.201402161939 |
| build 3.0.0.201402161939 |
Kinetis is a Freescale microcontroller family based on the ARM Cortex-M4 core. The family consists of subfamilies: K10, K20, K30, K40, K50, K60 and K70 that gradually add-on performance and features.
The Kinetis variant HAL provides generic support for hardware found on some or all Kinetis members. The variant package CYGPKG_HAL_CORTEXM_KINETIS provides configurable components that aim to support the complete set of options found in the Kinetis family.
The current Kinetis software includes a Kinetis variant HAL, some Platform BSPs, as well as DMA, UART, Wallclock, Ethernet and SPI support.
Kinetis is a set of families of micro-controllers packed with highly configurable components. In order to facilitate system configuration for the user, the CDL configuration items are organized as a set of expert components. Typically, for a given peripheral, the user chooses the required hardware options and desirable parameters, and the respective CDL configuration options and settings are calculated from these. If it is not possible to achieve exact values, the configurator attempts to provide approximate settings, then the user can manually do the fine tuning.
Within a family and/or across families the chips are further differentiated by their features such as: optional FPU, amount of memory, etc. The family member options are reflected in the controller naming scheme (see respective Freescale Kinetis product brief(s) and reference manual(s)). The Kinetis part builder CYGHWR_HAL_CORTEXM_KINETIS, respects this naming scheme and enables the user to interactively configure eCos for the desired part by selecting the requested part name segments. Based on user input, the CDL computes the part-specific eCos configuration. This includes calculation of on-chip FLASH and SRAM layout as well as the activation/deactivation of options such as FPU and Ethernet.
Kinetis is packed with a rich set of clocking options provided by the Multipurpose Clock Generator - MCG. Dependent on the part, MCG can have outlets for one or two external frequency reference sources OSC and OSC1 and one or two PLL oscillators PLL and PLL1. Each of the external frequency reference sources can be either a crystal or external oscillator and associated with either or both PLL oscillators. OSC can also be a reference source for the FLL oscillator. Besides OSC and OSC1, there are additional clock sources including two RC oscillators and a (battery backed) RTC clock with it's own 32768 Hz crystal oscillator. MCG gives the user a wide choice of system and peripheral clock source(s) that can be external clock(s), internal clocks, a PLL or the FLL. An external or on-chip oscillator can be used as a system clock or as a reference for PLL/FLL oscillator(s).
Note: In the documentation of Kinetis parts with two oscillators, OSC and PLL are described as OSC0 and PLL0 respectively.
Clocking component CYGHWR_HAL_CORTEXM_KINETIS_CLOCKING provides some expert functionality in order to facilitate clock system configuration. Normally, the user sets requirements: clock source, clock reference, desired core frequency and upper limits for peripheral clock frequencies. The component automatically calculates MCG and other peripheral register settings in order to achieve the required clock frequencies. This setting is not always perfect but fits (exactly or close) for commonly used frequencies. If necessary, the user can fine tune the clock settings interactively using the eCos Configuration Tool. The two clock sources are named:
The clock source that provides the clock for the Cortex-M core. It may also provide the clock for some peripherals.
This is optional and may provide a clock for peripherals but not for the Cortex-M core.
The user can select which source is the system clock. The choices for system clock are: PLL, FLL, External reference clock and, when available, PLL1. The auxiliary clock, when available is: PLL if PLL1 is selected for system the clock or PLL1 if any other source is selected for the system clock.
The memory layouts and startup types which don't employ external memory should be applicable to all Kinetis platforms so they are defined and maintained at the variant level. This is somewhat different than common eCos practice but has some advantages brought by universal, single copy linker scripts for single chip configurations. The linker scripts are further enhanced/generalized by utilization of macros provided by CDL and calculated on the basis of the selected Kinetis part.
Variant linker scripts are found at: hal/kinetis/var/<version>/include/pkgconf
Linker script file names are composed of segments mlt_kinetis_<NVM>_<SRAM>_<STARTUP>[_<PLF>].ldi where PLF is an optional extension for platform specific scripts and other segments have meanings as described in the following table.
Table 1. Linker script name segments
| Segment | Description | Values |
|---|---|---|
| NVM | Kinetis non-volatile memory configuration | flash, flexnvm |
| SRAM | SRAM memory sectioning | unisram, sram2s |
| STARTUP | Startup type | rom, sram |
Note: Never attempt to flash Kinetis with an image for SRAM startup. SRAM startup images do not contain a .flash_conf section so random contents may be written in flash protection area and lock your Kinetis device. This lock-out can be permanent.
Platforms, if needed, can provide their own layouts in addition to the variant ones. Typically they will cover systems with external memory. The startup type implicitly determines whether variant and platform defined layout shall be used.
Kinetis on chip SRAM memory consists of two equal banks that occupy consecutive locations anchored below and above 0x20000000. This fact is reflected in memory layout scripts. There are linker scripts that treat SRAM as a single section (unisram) or as 2 separate sections (sram2s).
Kinetis on-chip flash contains a special area [0x400-0x40F] that holds the flash security configuration. In order to preserve this area from accidental writing and at the same time provide regular access, a custom linker section .flash_conf is created. In addition, in order to utilize the FLASH pool below 0x400 the USER_SECTION .kinetis_misc is defined. This section typically contains code parts from kinetis_misc.c.
Kinetis members with operating frequencies of 120 MHz and 150 MHz are equipped with cache memory. Due to the Harvard architecture, there are two cache memories connected to code - PC and system - PS buses respectively. Although both modules can cache both instructions and data (unified caches), with the provided memory they act as instruction (PC) and data (PS) caches.
A common caching issue is sharing memory resources with bus masters such as DMA, Ethernet controller, etc. In order to keep shared data such as buffers and transfer control descriptors consistent, cached data have to be flushed and/or invalidated. An alternative approach, used here is usage of non-cachable memory for shared data. CYGHWR_HAL_NON_CACHABLE provides for the configuration of non-cachable memory. If some bus masters have provision for non-cache able memory, such configuration options can be parenthed by CYGHWR_HAL_NON_CACHABLE.
There are two levels of startup type:
This is always present and provides startup types for systems without external memory.
This is optional and is provided by a platform package. Typically it provides startup types for systems that employ external memory.
When present, the platform startup overloads the variant startup and has precedence over it. User can activate the variant startup by setting platform startup to ByVariant.
The following startup types are provided for Kinetis at the variant level:
Normal startup for stand-alone operation. eCos image has to be flashed in internal flash;
Image is loaded in internal SRAM by means of JTAG/SWD and executed under debugger control.
Note: (IMPORTANT) Never, ever attempt to flash Kinetis with an image for SRAM startup. SRAM startup images do not contain a .flash_conf section so random contents may be written to the flash protection area and lock your Kinetis device. This lock-out can be permanent.
In case of multiple simultaneous interrupts, interrupt service request resolution is based on a relative comparison of interrupt priorities, rather than on individual interrupt priority values. Interrupt priority scheme gives a consolidated overview and control of priorities of all interrupt sources. Interrupt priorities can be provided by either variant CYGHWR_HAL_DEVS_IRQ_PRIO_SCHEME_VAR or platform CYGHWR_HAL_DEVS_IRQ_PRIO_SCHEME.