Is there a first steps guide with kinetis microcontrollers

[olivergonzalez]

Hello all.

I have worked with the 8 bits freescale microcontrollers and the codewarrior like 7 years ago.

Now I want to program the kinetis K70 for a project but I have no idea how and where to start.

Is there a tutorial, introduction, sample projects from the very beginning like blinking a led or so?

I have searched in the datasheet, this community, blogs, the freescale page and I can't see something basic to start with, all sample projects include fancy functions and complex code for me.

I know this microcontroller has graphics capabilities and the project I am working with includes a display that's why we selected this microcontroller but no document shows something from the very beginning.

Please help me.

Thanks.

[mjbcswitzerland]

Hi Olivier

Here is a guide to starting: http://www.utasker.com/docs/KINETIS/uTaskerV1.4_Kinetis_demo.pdf but it mays still be too involved for the very first step.

You can also get a very simple start to the K70 with the uTasker project: µTasker Kinetis support since it allows the K70 to be run (out-of-the-box) without any hardware (you just need VisualStudio - the free Express edition is adequate); there is a tutorial here: http://www.utasker.com/docs/KINETIS/uTaskerV1.4_Kinetis.pdf Again the tutorial may be much more that you want for the first steps, but it does also allows the simplest things to be done so that you get a good understanding and can then build projects with a variety of tools (CodeWarrior, IAR, Keil etc.) for hardware operation.

Assuming you use the uTasker project with VisualStudio here is a step by step guide to a blinking LED. The blinking LED that it uses is a task that is called once every 200ms. Although the project may be doing many other things in parallel it is nevertheless possible to just concentrate on the parts that you are initially interested in. The first document link also included various practical HW details concerning peripheral modules in its appendix, so anything below needing a little more clarification should be available there:

1. In config.h select the Kinetis family that you will use (KINETIS_K70) and the board that you would like to use (eg. TWR_K70F120M) (custom boards can be added later).

2. Build the project (since it runs in this environment and doesn't need HW or downloading beforehand it simplifies things greatly for the first steps).

3. Run the project - you will see an LED blinking at 2.5Hz. The code steps to see how this was configured and how it operates can then be followed:

- 3a. Stop the program

- 3b. Set a break point in kinetis.c in the routine _LowLevelInit() and restart the program. There breaqkpoint is immediately hit and you can step the initialisation code (on the HW this is not possible since the watchdog needs to be configured within 256 clock cycles, otherwise it will reset - see the document link 1 for details). Watch how the watchdog is either disabled or configured - this is the first important step in any code.

- 3b. Step further to watch the CPU clock (source and PLL) being configured. Out of reset the chip is clocked from an internal RC oscillator until its clock is selected. The bus clock rate, flex bus and flash clock rates are also selected (in case of any rules, such as to maximum rates are not being respected the simulator will generate appropriate errors).

- 3c. Step further to watch the interrupt vectors being set to default values (and the NVIC's table offset). The project code later sets up the Cortex SYSTICK to generate a 50ms interrupt, which is explained in section 4.

- 3d. Set a breakpoint in the file application.c when the routine fnInitialisePorts() is called. Let the code run so that the breakpoint is hit. Step into this function to watch some inputs and outputs being configured. Notice that each port is powered up before use (as is the case with all peripheral modules - if access is performed to an un-powered module there would be an exception generated). You will soon reach a lines of code like this:

_CONFIG_PORT_OUTPUT(A, ulPortBit, PORT_SRE_SLOW);

which is configuring a port as an output with certain characteristics. Search for the macro _CONFIG_PORT_OUTPUT() [in kinetis.h] to see how the port registers are used to accomplish this and also to find various other macros for controlling ports, as well as the characteristics that are accepted. Since the LED doesn't need to be fast, a slow output drive is being set to avoid generating interference due to unnecessarily fast edges.
- 3e. Now set a breakpoint in the file Watchdog.c at the line fnRetriggerWatchdog() and let the project continue to run. This line will be hit every 200ms. Step into the code to see how the watchdog is retriggered to avoid it from firing when all is well.
Here you will also see that there is a line of code TOGGLE_WATCHDOG_LED(); which is defines in app_hw_kinetis.h to toggle the LED output that we saw:

_TOGGLE_PORT(A, BLINK_LED); Again check the port macro to see which registers are being used.

4. This example does use a timer interrupt so it is worth understanding the basics here too. If you want to watch it being configured (for analysis) restart the project with a breakpoint in the routine fnStartTick() in kinetis.c. Here you will see how the SYSTICK is configured; this is a timer that belongs to the Cortex core and not Kinetis peripherals and so is identical in all such processors. You will see that an interrupt priority is entered for its interrupt, the interrupt source is enabled and the timer's reload value set to correspond to the required TICK rate (configurable with TICK_RESOLUTION in config.h). The timer's interrupt handler is entered into the interrupt vector table - in this case it is called _RealTimeInterrupt().
- 4a. You can set a breakpoint in the SYSTICK interrupt (_RealTimeInterrupt()) in the same file and this will be hit every 50ms. In the interrupt handler you will see that the pending interrupt flag is cleared each time.
The actual code then calls resources that then defining the rate of the watchdog timer task that was seen in 3, but these are general software details and not really Kinetis related.

The above should make first steps in understanding the Kinetis operations quite simple. The same steps can then be performed on real hardware (apart for the first as noted above due to HW constraints). You should see the same behaviour but without the need to have first cross-compiled and loaded code to the HW with a suitable debugger etc.

There is maybe one further thing that should be understood, which is not really visible - neither when simulating nor on the HW. This concerns the reset vector and Flash configuration. The reset vector is always at the Flash address 0x00000000 and is made up of two 32 bit address values. The first at 0x00000000 is the initial stack pointer value which is loaded to the SP  immediataly after the chip resets; It is normally set to the top of internal SRAM. The second at 0x00000004 is the initial program counter. It is loaded to the PC so that execution starts there.

The Flash values stored in the area 0x400..0x40f are loaded on reset to the Flash controller. These determine whether Flash blocks are protected from being deleted, whether the chip is in secured mode,etc. It is in fact possible to disable the JTAG interface so that the chip can not be debugged in case certain values are set - so it is important to ensure that code loaded to the device puts sensible values here.

The uTasker proejct makes this simple by not using assembler code and also not using values from linker script files to control these details, but instead using project configuration defines as show below:

const _RESET_VECTOR __attribute__((section(".vectors"))) reset_vect

= {        

    (void *)(RAM_START_ADDRESS + (SIZE_OF_RAM - 4)),                     // stack pointer to top of RAM

    (void (*)(void))START_CODE,                                          // start address

};

const KINETIS_FLASH_CONFIGURATION __attribute__((section(".f_config"))) flash_config

= {

    KINETIS_FLASH_CONFIGURATION_BACKDOOR_KEY,

    KINETIS_FLASH_CONFIGURATION_PROGRAM_PROTECTION,

    KINETIS_FLASH_CONFIGURATION_SECURITY,

    KINETIS_FLASH_CONFIGURATION_NONVOL_OPTION,

    KINETIS_FLASH_CONFIGURATION_EEPROM_PROT,

    KINETIS_FLASH_CONFIGURATION_DATAFLASH_PROT

};

Here the reset vector details are automatically set with the chip's details and the user can simply control special flash settings if needed - the defaults would not protect anything and not secure the device.

For the K70 (1Meg Flash and 128k SRAM) you will find that

SIZE_OF_RAM is (128 * 1024) and RAM_START_ADDRESS is (0x20000000 - (SIZE_OF_RAM/2)) [due to the fact that SRAM is symmetrically located around the address 0x20000000]

START_CODE is always 0x00000000.

For first steps that should be all that needs to be known. The project then automatically contains almost all support that is required to complete entire projects, which can be learned in such simple steps in the same efficient environment. The complete project is available from http://www.utasker.com/forum/index.php?topic=1721.0

Regards

Mark