Setup
Prev Chapter 291. Freescale TWR-K60N512 and TWR-K60D100M Platform HAL Next

Name

Setup — Preparing the TWR-K60N512/TWR-K60D100M Board for eCos Development

Overview

Since the target motherboard provides a built-in hardware debug solution, it is expected that the most common development method when targeting the CPU is to use this hardware debug interface (instead of GDB stubs or RedBoot) for development. This will either be by loading smaller applications into on-chip SRAM, or by programming larger applications directly into on-chip flash. In the first case, eCos applications should be configured for the variant JTAG startup type, and in the second case for the variant ROM startup type.

Nevertheless, it is still possible to program RedBoot or a GDB stub ROM image into on-chip flash and download and debug via a serial UART, if pins for the UART are available. In that case, eCos applications are configured for a variant RAM startup and then downloaded and run on the board via the debugger arm-eabi-gdb, or via the Eclipse IDE. For serial communications, all versions run with 8 bits, no parity, and 1 stop bit at 38400 baud. This rate can be changed in the eCos configuration used for building the RedBoot or GDB stub ROM image.

HAL Startup Types

For the twr_k60n512 and twr_k60d100m platforms the Kinetis variant HAL support provides some common startup types. The following variant HAL provided startup types may be selected for applications:

ConfigurationDescription
ROMStand-alone programs running from internal FLASH
SRAMPrograms loading via hardware debugger into on-chip SRAM, but expecting RedBoot or GDB stub ROM
RAMPrograms loading via RedBoot or GDB stub ROM into on-chip SRAM
JTAGStand-alone programs running from on-chip SRAM, loaded via hardware debugger

Further details are available later in this manual.

Preparing OSJTAG interface

The support for using the on-chip OSJTAG interface for hardware debugging and diagnostic output requires that the OSJTAG firmware is at least version v30.21. The firmware for the OSJTAG interface can be checked, and updated if needed, using the relevant firmware updater tool available for download via the Freescale website. Unfortunately the official firmware updater is only available for the Windows platform at the moment.

Programming ROM images

To program ROM startup applications into flash, including the GDB stub ROM or RedBoot, a hardware debugger that understands the Kinetis flash may be used. For example, the Ronetix PEEDI provides suitable support.

[Warning]Warning

Due to a security feature of the Kinetis CPUs care should be taken to avoid completely erasing the flash to ensure the required FSEC value in the flash configuration field is not lost. For example when using the PEEDI the user should NOT use the “erase” suffix to the flash program command. The Kinetis aware flash erase chip should be executed to erase the flash prior to using the flash program command.

Programming ROM images with a Ronetix PEEDI

This section describes how to program ROM images using a Ronetix PEEDI debugger.

The PEEDI must be configured to allow communication with your local network, and configured with the parameters for interfacing with the target board. It must then be used to download and program the ROM image into the internal flash. The following steps give a typical outline for doing this. Consult the PEEDI documentation for alternative approaches, such as using FTP or HTTP instead of TFTP.

Preparing the Ronetix PEEDI JTAG debugger

  1. Prepare a PC to act as a host and start a TFTP server on it.
  2. Connect the PEEDI JTAG debugger via both serial and ethernet to the host PC and power it on. Use the serial cable supplied with the PEEDI (straight through, not null modem).
  3. Verify the PEEDI is using up-to-date firmware, of version 12.3.0 or later. Older PEEDI firmware does not support the Kinetis family correctly, particularly if wishing to use the PEEDI's own 'flash' commands to modify the on-chip flash. If the firmware is not recent enough, follow the PEEDI User Manual's instructions which describe how to update the PEEDI firmware.
  4. Locate the PEEDI configuration file peedi_twr_k60n512.cfg within the eCos platform HAL package in the source repository. This will be in the directory packages/hal/cortexm/kinetis/twr_k60n512/VERSION/misc relative to the root of your eCos installation.
  5. Place the PEEDI configuration file in a location on the PC accessible to the TFTP server. Later you will configure the PEEDI to load this file via TFTP as its configuration file.
  6. Open peedi_twr_k60n512.cfg in an editor such as emacs or notepad and insert your own license information in the [LICENSE] section.
  7. Install and configure the PEEDI in line with the PEEDI Quick Start Guide or User's Manual, especially configuring PEEDI's RedBoot with the network information. Configure it to use the peedi_twr_k60n512.cfg target configuration file on the TFTP server at the appropriate point of the config process, for example with a path such as: tftp://192.168.7.9/peedi_twr_k60n512.cfg
  8. Reset the PEEDI.

  9. Connect to the PEEDI's CLI interface via TCP/IP on the standard telnet port 23. The telnet application is suitable for this. You should see output similar to the following: 

    $ telnet 192.168.7.225
Trying 192.168.7.225...
Connected to 192.168.7.225.
Escape character is '^]'.

PEEDI - Powerful Embedded Ethernet Debug Interface
Copyright (c) 2005-2011 www.ronetix.at - All rights reserved
Hw:1.2, L:JTAG v1.6 Fw:13.3.0, SN: PD-XXXX-XXXX-XXXX
------------------------------------------------------------

twr_k60n512>

Preparing the TWR-K60N512/TWR-K60D100M board for programming with PEEDI

Follow the steps in this section in order to allow communication between the board and the host PC, and between the board and the PEEDI device.

If programming a RedBoot, GDB stub ROM, or an application, which uses serial output, you should first:

  1. If OSJTAG firmware 30.21 or later is installed then the motherboard J13 USB provides a standard CDC-ACM virtual serial connection to the host computer. The alternative is to connect a null modem cable between the DB9 RS232 connector on the TWR-SER daughterboard and the host computer.
  2. Start a suitable terminal emulator on the host computer such as minicom on Linux or PuTTY on Windows. Set the communication parameters to 38400 baud, 8 data bits, no parity bit and 1 stop bit with no flow control.

For all applications, you must:

  1. Connect the board to the PEEDI using an appropriate 20-pin cable from the JTAG interface connector to the Target port on the PEEDI. This will normally be a PEEDI-CORTEX20 adapter.
  2. Power up the TWR-K60N512/TWR-K60D100M board.
  3. Connect to the PEEDI's telnet CLI on port 23 as before.

  4. Confirm correct connection with the PEEDI with the reset reset command as follows: 

    twr_k60n512> reset reset
++ info: user reset
twr_k60n512>
++ info: RESET and TRST asserted
++ info: TRST released
++ info: TAP : IDCODE = 0x2BA01477, Cortex M3 SWD
++ info: RESET released
++ info: core connected

CORE0 -> CortexM4 - stopped by breakpoint
         PC=0x1FFF0006, xPSR=0x01000000

core #0 stopped
++ info: core 0: initialized

twr_k60n512>

Installation into flash

The following describes the procedure for installing a ROM application into on-chip flash, using the GDB stub ROM image as an example of such an application.

  1. Use arm-eabi-objcopy to convert the linked application, in ELF format, into binary format. For example: 

    $ arm-eabi-objcopy -O binary programname programname.bin
  2. Copy the binary file (.bin file) into a location on the host computer accessible to its TFTP server.

  3. Connect to the PEEDI's telnet interface, and program the image into flash with the following commands, replacing TFTP_SERVER with the address of the TFTP server and /BINPATH with the location of the .bin file relative to the TFTP server root directory. For example for a RedBoot ROM image: 

    twr_k60n512> flash erase chip

erasing chip at 0x00000000
done.

++ info: successfully erased 1 byte in 0.33 sec

twr_k60n512> flash program tftp://TFTP_SERVER/BINPATH/redboot.bin bin 0x00000000
++ info: Programming image file: tftp://TFTP_SERVER/redboot.bin
++ info: Programming directly
++ info: At absolute address:    0x00000000
programming at 0x00000000
programming at 0x00001000
programming at 0x00002000
programming at 0x00003000
programming at 0x00004000
programming at 0x00005000
programming at 0x00006000
programming at 0x00007000
programming at 0x00008000
programming at 0x00009000
programming at 0x0000A000
programming at 0x0000B000
programming at 0x0000C000
programming at 0x0000D000
programming at 0x0000E000
programming at 0x0000F000
programming at 0x00010000
programming at 0x00011000
programming at 0x00012000
programming at 0x00013000
programming at 0x00014000
programming at 0x00015000

++ info: successfully programmed 88.00 KB in 0.74 sec

twr_k60n512>

The installation into flash is now complete. For applications which print output on startup to the USART3 RS232 serial port, such as the GDB stub ROM application, this can easily by tested by powering off the board, disconnecting the JTAG, and then powering on the board again. In the case of the GDB stub ROM image, output similar to the following should be visible (although specific numbers may differ): 

$T050f:72250008;0d:f0ff0120;#8a

RedBoot Installation

Only the ROM_VAR RedBoot configuration is supported. This is for RedBoot running from internal FLASH, using on-chip SRAM. For serial communications this uses 8 bits, no parity, and 1 stop bit at 38400 baud. This rate can be changed using the RedBoot baud command, or in the eCos configuration used for building RedBoot.

Rebuilding RedBoot

Should it prove necessary to rebuild a RedBoot binary, this is done most conveniently at the command line. The steps needed to rebuild the ROM version of RedBoot for the TWR-K60N512 are: 

$ mkdir redboot_twr_k60n512_rom
$ cd redboot_twr_k60n512_rom
$ ecosconfig new twr_k60n512 redboot
[ … ecosconfig output elided … ]
$ ecosconfig import $ECOS_REPOSITORY/hal/cortexm/kinetis/twr_k60n512/VERSION/misc/redboot_ROM_VAR.ecm
$ ecosconfig tree
$ make

At the end of the build the install/bin subdirectory should contain the file redboot.bin. This may be programmed to the board using the above procedure, or by using RedBoot's own flash update mechanisms.

The other versions of RedBoot - RAM, ROM_FPU, ROM_VAR - may be similarly built by choosing the appropriate alternative .ecm file.

Initializing RedBoot flash Configuration

RedBoot manages the internal flash for the storage of application programs and configuration data. The flash needs to be initialized with the following commands: 

RedBoot> fis init
About to initialize [format] FLASH image system - continue (y/n)? y
*** Initialize FLASH Image System
... Erase from 0x0007f800-0x0007ffff: .
... Program from 0x2000e800-0x2000f000 to 0x0007f800: .
RedBoot> fconfig -i
Initialize non-volatile configuration - continue (y/n)? y
Run script at boot: false
Console baud rate: 115200
Update RedBoot non-volatile configuration - continue (y/n)? y
... Erase from 0x0007f800-0x0007ffff: .
... Program from 0x2000e800-0x2000f000 to 0x0007f800: .
RedBoot>

Issue the reset command to RedBoot, and verify the the target board comes up as expected with the correct settings.

You may also need to run the fconfig -i command if you have updated your RedBoot from a previous version with a different configuration which might not have any new config fields used by the newly programmed RedBoot.

Prev Up Next
Freescale TWR-K60N512/TWR-K60D100M Platform HAL Home Configuration