User Guide of The J-Link RDI Interface For J-Link ARM Emulator

J-Link ARM RDI
User guide of the J-Link RDI Interface

for J-Link ARM Emulator
Software Version 4.08

Manual Rev. 0
Date: August 6, 2009
Document: UM08004
A product of SEGGER Microcontroller GmbH & Co. KG
www.segger.com
2
Disclaimer
Specifications written in this document are believed to be accurate, but are not guar-
anteed to be entirely free of error. The information in this manual is subject to
change for functional or performance improvements without notice. Please make sure
your manual is the latest edition. While the information herein is assumed to be
accurate, SEGGER Microcontroller GmbH & Co. KG (the manufacturer) assumes no
responsibility for any errors or omissions. The manufacturer makes and you receive
no warranties or conditions, express, implied, statutory or in any communication with
you. The manufacturer specifically disclaims any implied warranty of merchantability
or fitness for a particular purpose.
Copyright notice
You may not extract portions of this manual or modify the PDF file in any way without
the prior written permission of the manufacturer. The software described in this doc-
ument is furnished under a license and may only be used or copied in accordance
with the terms of such a license.
© 2002 - 2008 SEGGER Microcontroller GmbH & Co. KG, Hilden / Germany
Trademarks
Names mentioned in this manual may be trademarks of their respective companies.
Brand and product names are trademarks or registered trademarks of their respec-
tive holders.
Contact address
SEGGER Microcontroller GmbH & Co. KG
In den Weiden 11
D-40721 Hilden
Germany
Tel.+49 2103-2878-0
Fax.+49 2103-2878-28
Email: support@segger.com
Internet: http://www.segger.com
Manual versions
This manual describes the latest software version. If any error occurs, please inform
us and we will try to assist you as soon as possible.
For further information on topics or routines not yet specified, please contact us.
Manual version Date By Explanation

Chapter "Using J-Link RDI with different debuggers"
3.91 Rev. 0 080826 AG
* Section "IAR Embedded Workbench IDE" updated.
Chapter "Flash download":
3.90 Rev. 0 080811 AG
* Section "Supported flash devices" updated.
Chapter "Flash download" updated.
3.86 Rev. 0 080630 AG
Chapter "Breakpoints in flash memory" updated.
3.80 Rev. 0 080307 AG Chapter "Licensing" added.
Chapter "Configuration":
9 070919 SK
* Section"Configuration file JLinkRDI.ini" included.
Chapter "Using J-Link RDI with different debuggers":
8 070803 SK
* Section"ARM’s RVDS" updated.
Chapter "Using J-Link RDI with different debuggers":
* Section "KEIL µVision3 IDE" added.
Chapter "Configuration":
7 070115 SK * Some changes in chapter structure.
* Section "Location of Config file" renamed to
"Config file"
* Section "Config file" enhanced.
6 061221 SK Preface: Company description added.
J-Link RDI(UM08004) © 2004-2009 SEGGER Microcontroller GmbH & Co. KG

3
Manual version Date By Explanation

Section "Using GHS Multi" added.
5 061106 SK
Section "License (J-Link RDI License managment)" added.
4 060801 TQ Updated list of supported flash devices.
3 060703 OO Section "Reset strategy": Added listing of available reset types.
2 051111 TQ Adding description of adaptive clocking. Minor corrections.
1 051028 OO Initial version.
Software versions
Refers to Release.html for information about the changes of the software versions.

4

5
About this document
Assumptions
This document assumes that you already have a solid knowledge of the following:
• The software tools used for building your application (assembler, linker, C com-
piler)
• The C programming language
• The target processor
• DOS command line.
If you feel that your knowledge of C is not sufficient, we recommend The C Program-
ming Language by Kernighan and Richie (ISBN 0-13-1103628), which describes the
standard in C-programming and, in newer editions, also covers the ANSI C standard.
How to use this manual
This document describes J-Link RDI. It provides an overview over the major features
of J-Link RDI, gives you some background information about Flash breakpoints and
configuration in general and describes using RDI compliant debuggers with J-Link
RDI. Finally, the chapter Support on page 83 helps to troubleshoot common prob-
lems.
Typographic conventions for syntax
This manual uses the following typographic conventions:
Style Used for
Body Body text.
Text that you enter at the command-prompt or that appears on the

Keyword
display (that is system functions, file- or pathnames).
Parameter Parameters in API functions.

Sample Sample code in program examples.
Reference Reference to chapters, tables and figures or other documents.
GUIElement Buttons, dialog boxes, menu names, menu commands.
Emphasis Very important sections

Table 1.1: Typographic conventions

6
SEGGER Microcontroller GmbH & Co. KG develops

and distributes software development tools and ANSI
C software components (middleware) for embedded
systems in several industries such as telecom, medi-
cal technology, consumer electronics, automotive
industry and industrial automation.
SEGGER’s intention is to cut software development-
time for embedded applications by offering compact flexible and easy to use middleware,
allowing developers to concentrate on their application.
Our most popular products are emWin, a universal graphic software package for embed-
ded applications, and embOS, a small yet efficent real-time kernel. emWin, written
entirely in ANSI C, can easily be used on any CPU and most any display. It is comple-
mented by the available PC tools: Bitmap Converter, Font Converter, Simulator and
Viewer. embOS supports most 8/16/32-bit CPUs. Its small memory footprint makes it
suitable for single-chip applications.
Apart from its main focus on software tools, SEGGER developes and produces program-
ming tools for flash microcontrollers, as well as J-Link, a JTAG emulator to assist in devel-
opment, debugging and production, which has rapidly become the industry standard for
debug access to ARM cores.
Corporate Office: United States Office:

http://www.segger.com http://www.segger-us.com
EMBEDDED SOFTWARE SEGGER TOOLS

(Middleware)
emWin Flasher
Graphics software and GUI Flash programmer
emWin is designed to provide an effi- Flash Programming tool primarily for microcon-
cient, processor- and display control- trollers.
ler-independent graphical user
interface (GUI) for any application that J-Link
operates with a graphical display. JTAG emulator for ARM cores
Starterkits, eval- and trial-versions are USB driven JTAG interface for ARM cores.
available.
J-Trace
embOS JTAG emulator with trace
Real Time Operating System USB driven JTAG interface for ARM cores with
embOS is an RTOS designed to offer Trace memory. supporting the ARM ETM (Embed-
the benefits of a complete multitasking ded Trace Macrocell).
system for hard real time applications
with minimal resources. The profiling J-Link / J-Trace Related Software
PC tool embOSView is included. Add-on software to be used with SEGGER’s indus-
try standard JTAG emulator, this includes flash
emFile programming software and flash breakpoints.
File system
emFile is an embedded file system with
FAT12, FAT16 and FAT32 support.
emFile has been optimized for mini-
mum memory consumption in RAM and
ROM while maintaining high speed.
Various Device drivers, e.g. for NAND
and NOR flashes, SD/MMC and Com-
pactFlash cards, are available.
emUSB
USB device stack
A USB stack designed to work on any
embedded system with a USB client
controller. Bulk communication and
most standard device classes are sup-
ported.

7
Table of Contents
1 Introduction ....................................................................................................................11
1.1 What is RDI?........................................................................................... 12
1.1.1 Features of J-Link RDI .............................................................................. 12
1.2 Requirements.......................................................................................... 12
1.3 Basic principles ....................................................................................... 13
1.4 Purchase ................................................................................................ 13
1.5 Required licenses..................................................................................... 13
2 Licensing........................................................................................................................15
2.1 Introduction............................................................................................ 16
2.2 Software components requiring a license .................................................... 16
2.3 License types .......................................................................................... 16
2.3.1 Built-in license ........................................................................................ 17
2.3.2 Key-based license.................................................................................... 17
2.3.3 Device-based license................................................................................ 17
3 Using J-Link RDI with different debuggers.....................................................................21

3.1 IAR Embedded Workbench IDE .................................................................. 22
3.1.1 Software version ..................................................................................... 22
3.1.2 Configuring to use J-Link RDI .................................................................... 22
3.1.3 Limitations.............................................................................................. 24
3.2 ARM’s AXD (ARM Developer Suite, ADS) ..................................................... 24
3.2.3 Limitations.............................................................................................. 26
3.3 ARM’s RVDS (RealView developer suite)...................................................... 27
3.3.3 Limitations.............................................................................................. 32
3.4 GHS MULTI ............................................................................................. 33
3.4.3 Limitations.............................................................................................. 35
3.5 KEIL µVision IDE ..................................................................................... 36
3.5.3 Limitations.............................................................................................. 39
4 Configuration..................................................................................................................41
4.1 Overview ................................................................................................ 42
4.1.1 Configuration file JLinkRDI.ini.................................................................... 42
4.1.2 Using different configurations .................................................................... 42
4.1.3 Using mutliple J-Links simulatenously......................................................... 42
4.2 Configuration dialog ................................................................................. 43
4.2.1 General .................................................................................................. 43
4.2.2 Init ........................................................................................................ 45
4.2.3 Comands in the macro file ........................................................................ 46
4.2.4 Example of macro file............................................................................... 46
4.2.5 JTAG...................................................................................................... 47
4.2.6 Flash configuration .................................................................................. 48

8
4.2.7 Breakpoints ............................................................................................ 49

4.2.8 CPU....................................................................................................... 50
4.2.9 Log ....................................................................................................... 53
5 Flash download..............................................................................................................55
5.1 Overview ............................................................................................... 56
5.2 Why should I use RDI flash download? ....................................................... 56
5.3 Enabling flash download ........................................................................... 56
5.4 Supported flash devices ........................................................................... 56
6 Breakpoints in flash memory..........................................................................................57

6.1 Introduction ........................................................................................... 58
6.2 How do breakpoints work?........................................................................ 58
6.3 What is special about software breakpoints in
flash? .................................................................................................... 58
6.4 How does this work?................................................................................ 58
6.5 What performance can I expect? ............................................................... 58
6.6 How is this performance achieved? ............................................................ 58
6.7 Setting up flash breakpoints ..................................................................... 59
7 Device specifics .............................................................................................................61

7.1 Analog Devices ....................................................................................... 62
7.1.1 ADuC7xxx .............................................................................................. 62
7.2 ATMEL ................................................................................................... 63
7.2.1 AT91SAM7 ............................................................................................. 63
7.3 NXP....................................................................................................... 64
7.3.1 LPC2xxx ................................................................................................ 64
7.4 OKI ....................................................................................................... 65
7.4.1 ML67Q40x.............................................................................................. 65
7.5 ST Microelectronics.................................................................................. 66
7.5.1 STR 71x................................................................................................. 66
7.5.2 STR 73x................................................................................................. 66
7.5.3 STR 75x................................................................................................. 66
7.5.4 STR91x.................................................................................................. 66
7.6 Texas Instruments .................................................................................. 67
7.6.1 TMS470 ................................................................................................. 67
8 Semihosting ...................................................................................................................69
8.1 Overview ............................................................................................... 70
8.2 The SWI interface ................................................................................... 70
8.2.1 Changing the semihosting SWI numbers .................................................... 71
8.3 Implementation of semihosting in J-Link RDI .............................................. 71
8.3.1 DCC semihosting..................................................................................... 71
8.4 Semihosting with AXD.............................................................................. 71
8.4.1 Using SWIs in your application .................................................................. 71
8.5 Unexpected / unhandled SWIs .................................................................. 72
9 Background information .................................................................................................73

9.1 JTAG ..................................................................................................... 74
9.1.1 Test access port (TAP) ............................................................................. 74
9.1.2 Data registers......................................................................................... 74
9.1.3 Instruction register.................................................................................. 74
9.1.4 The TAP controller ................................................................................... 75
9.2 The ARM core ......................................................................................... 76
9.2.1 Processor modes ..................................................................................... 77
9.2.2 Registers of the CPU core ......................................................................... 77
9.2.3 ARM /Thumb instruction set...................................................................... 78
9.3 EmbeddedICE ......................................................................................... 78
9.3.1 Breakpoints and watchpoints .................................................................... 78

9
9.3.2 The ICE registers ..................................................................................... 79

9.4 Flash programming .................................................................................. 79
9.4.1 How does flash programming via J-Link ARM work ? ..................................... 79
9.4.2 Available options for flash programming ..................................................... 80
10 FAQs............................................................................................................................81
10.1 FAQs...................................................................................................... 82
11 Support ........................................................................................................................83
11.1 Troubleshooting ...................................................................................... 84
11.1.1 General procedure ................................................................................... 84
11.1.2 Typical problem scenarios ......................................................................... 84
11.2 Contacting support .................................................................................. 84
12 Glossary.......................................................................................................................85
J-Flash ARM User Guide (UM08003) (UM08004) © 2002 - 2008 SEGGER Microcontroller GmbH & Co. KG
10

11
Chapter 1
Introduction
This chapter gives a short overview about the use of J-Link RDI, flash breakpoints
and flash download.

12 CHAPTER 1 Introduction
1.1 What is RDI?

Remote Debug Interface (RDI) is an Application Programming Interface (API) that
defines a standard set of data structures and functions that abstract hardware for
debugging purposes. J-Link RDI mainly consists of a DLL designed for ARM cores to
be used with any RDI compliant debugger. J-Link RDI offers features like flash break-
points and flash download.
Host (PC)
RDI compliant + Data

File
Debugger (e.g. elf)
elf.gif
J-Link RDI DLL
USB
J-Link
JTAG
ARM
1.1.1 Features of J-Link RDI

• Usable with every RDI compliant debugger
• Supports more than 2 breakpoints when debugging in flash by using the flash
breakpoints feature (add. license required)
• Offers download into flash without the need for a flash loader
(add. license required)
• Instruction set simulation (improves debugging performance)
• Any core supported by J-Link ARM (ARM7 / ARM9)
• Easy to use
1.2 Requirements
Host System
In order to use J-Link RDI you need a host system running Windows 2000 or Win-
dows XP with SEGGER’s J-Link USB driver and a RDI compliant debugger.
Target System
An ARM7 or ARM9 target system is required. The system should have a 20-pin con-
nector as defined by ARM Ltd. Please note that Segger offers an optional adapter to
use J-Link ARM with targets using 14 pin 0.1" mating JTAG connectors.

13
1.3 Basic principles

The EmbeddedICE logic and the ARM processor debug extensions enable J-Link ARM
to debug software running on an ARM processor. The EmbeddedICE is accessed via
the JTAG port and described in detail in the technical reference manuals available
from ARM. Some basic information can be found in the chapter Background informa-
tion on page 73.
1.4 Purchase
The J-Link ARM software and documentation pack includes the J-Link RDI software.
You can download the J-Link ARM software and documentation pack from:
http://www.segger.com/downloads.html
1.5 Required licenses

The software is licensed on a per J-Link basis. It requires different licenses for differ-
ent parts of the software. In general, the following items are required to use the soft-
ware:
1. J-Link ARM
2. RDI license
In addidtion to that, "flash download" and "flash breakpoints" are not part of the
standard RDI software and require add. licenses. For more information about the
license types and licensing in general, please refer to Chapter 2 Licensing.
Free trial licenses are avaliable upon request from www.segger.com.

14 CHAPTER 1 Introduction

15
Chapter 2
Licensing
This chapter describes the licensing requirements and options of the software.

16 CHAPTER 2 Licensing
2.1 Introduction
J-Link functionality can be enhanced by the features RDI, flash download and flash
breakpoints. These features do not come with J-Link and need additional licenses. In
this chapter the licensing options of the software will be explained.
2.2 Software components requiring a license

There are three software components which need an additional license:
• J-Link RDI
• Flash download
• Flash breakpoints
The RDI license is essential for using the RDI feature. A license for flash download
and flash breakpoints is optional, but both of them require a RDI license in order to
use them.
2.3 License types

For each of the software components which require an additional license (RDI, flash
download, flash breakpoints), there are three types of licenses:
Built-in License
This type of license is easiest to use. The customer does not need to deal with a
license key. The software automatically finds out that the connected J-Link contains
the built-in license(s). This is the type of license you get if you order J-Link and the
license at the same time, typically in a bundle.
Key-based license
This type of license is used if you already have a J-Link, but want to enhance its func-
tionality by using RDI, flash download and flash breakpoints. In addition to that, the
key-based license is used for trial licenses. To enable this type of license you need to
obtain a license key from SEGGER. Free trial licenses are available upon request from
www.segger.com This license key has to be added to the RDI license management.
How to enter a license key is described in detail in the section Key-based license on
page 17. Every license can be used on different PCs, but only with the J-Link the
license is for. This means that if you want to use J-Link RDI, flash download and/or
flash breakpoints with other J-Links, every J-Link needs a license.
Device-based license
The device-based license comes with the J-Link software and is currently available
for NXP LPC devices from LPC21xx to LPC24xx. It includes a license for RDI, flash
download and flash breakpoints. The device-based license has to be enabled by the
customer via the J-Link RDI configuration dialog. How to enable a device-based
license is described in detail in the section Device-based license on page 17.

17
2.3.1 Built-in license

This type of license is easiest to use. The customer does not need to deal with a
license key. The software automatically finds out that the connected J-Link contains
the built-in license(s). To check what licenses the used J-Link have, simply open the
J-Link commander (JLink.exe). The J-Link commander finds and lists all of the J-
Link’s licenses automatically, as can be seen in the screenshot below.
This J-Link for example, has built-in licenses for RDI, flash download (FlashDL ) and
flash breakpoints ( FlashBP ).
2.3.2 Key-based license

When using a key-based license, a license key is required in order to enable the J-
Link features RDI, flash download and flash breakpoints. License keys can be added
via the RDI license management. The RDI license management can be found in the
RDI configuration dialog. For more information about how to use the RDI license
management, please refer to chapter License (J-Link RDI License managment) on
page 44. Like the built-in license, the key-based license is only valid for one J-Link,
so if another J-Link is used it needs a separate license.
When using RDI and no license is found by the software, it will ask for a key. The
error dialog should look like in the screenshot below.
If Enter license is chosen, the RDI license management dialog opens and the license
key can be added as described in chapter License (J-Link RDI License managment)
on page 44.
If one of the features flash download and flash breakpoints is used and no license is
found, an appropriate error dialog appears.
2.3.3 Device-based license

The device-based license is a free license, available for NXP LPC devices from
LPC21xx to LPC24xx. It’s already included in the J-Link RDI software, so no keys are
necessary to enable this license type. To activate a device based license, a supported
device needs to be selected. The device-based license includes a valid license for
RDI, flash download and flash breakpoints.

2.3.3.1 Enabling a device-based license

In order to enable a device-based license, flash programming has to be enabled and
the appropriate device has to be selected. For example if the device-based license for
RDI and flash download for a NXP LPC2378 shall be enabled, the J-Link RDI configu-
ration dialog should look like in the screenshot below.
For more information about the J-Link RDI configuration dialog, please refer to chap-
ter Configuration dialog on page 43.
2.3.3.2 Device list

The following list contains all NXP LPC devices which are supported by the device-
based license.
Manufacturer Name
NXP LPC2101
NXP LPC2102
NXP LPC2103
NXP LPC2104
NXP LPC2105
NXP LPC2106
NXP LPC2109
NXP LPC2114
NXP LPC2119
NXP LPC2124
NXP LPC2129
NXP LPC2131
NXP LPC2132
NXP LPC2134
NXP LPC2136
NXP LPC2138
NXP LPC2141
NXP LPC2142
NXP LPC2144
NXP LPC2146
Table 2.1: Device list

19
Manufacturer Name
NXP LPC2148
NXP LPC2194
NXP LPC2212
NXP LPC2214
NXP LPC2292
NXP LPC2294
NXP LPC2364
NXP LPC2366
NXP LPC2368
NXP LPC2378
NXP LPC2468
NXP LPC2478
Table 2.1: Device list


21
Chapter 3
Using J-Link RDI with different

debuggers
This chapter describes how to use J-Link ARM with different debuggers via RDI.
The J-Link RDI software is an ARM Remote Debug Interface (RDI) for J-Link ARM. It
makes it possible to use J-Link ARM with any RDI compliant debugger. The package
consists of 2 DLLs, which need to be copied to the same folder. In order to use these
DLLs, they need to be selected in the debugger. J-Link RDI is a separate item and not
included in the J-Link ARM software.

22 CHAPTER 3 Using J-Link RDI with different debuggers
3.1 IAR Embedded Workbench IDE

3.1.1 Software version
The JLinkRDI.dll has been tested with IAR Embedded Workbench IDE version 4.40.
There should be no problems with other versions of IAR Embedded Workbench IDE.
All screenshots are taken from IAR Embedded Workbench version 4.40.
3.1.2 Configuring to use J-Link RDI

1. Start the IAR Embedded Workbench and open the tutor example project or your
desired project. This tutor project has been preconfigured to use the simulator driver.
In order to run the J-Link RDI you must change the driver.

23
2. Choose Project | Options and select the Debugger category. Change the
Driver option to RDI.
3. Go to the RDI page of the Debugger options, select the manufacturer driver
( JLinkRDI.dll ) and click OK .
4. Now an extra menu, RDI, has been added to the menu bar.
Choose RDI | Configure to configure the J-Link. For details refer to the configu-
ration chapter.
J-Link may also be selected directly in the debugger of the IAR Embedded Workbench
IDE; RDI can be used, but is not necessary to use the IAR Embedded Workbench IDE
with J-Link ARM unless you want to use one of the features offered by J-Link RDI
(e.g. flash breakpoints or flash download).
Debugging on Cortex-M3 devices
The RDI protocol has only been specified by ARM for ARM 7/9 cores. For Cortex-M3
there is no official extension of the RDI protocol regarding the register assignement,
that has been approved by ARM. Since IAR EWARM version 5.11 it is possible to use

J-Link RDI for Cortex-M3 devices because SEGGER and IAR have been come to an
agreement regarding the RDI register assignment for Cortex-M3. The following table
lists the register assignment for RDI and Cortex-M3:
Register
Assigned register
Index
0 R0
1 R1
2 R2
3 R3
4 R4
5 R5
6 R6
7 R7
8 R8
9 R9
10 R10
11 R11
12 R12
13 MSP / PSP (depending on mode)
14 R14 (LR)
16 R15 (PC)
17 XPSR
18 APSR
19 IPSR
20 EPSR
21 IAPSR
22 EAPSR
23 IEPSR
24 PRIMASK
25 FAULTMASK
26 BASEPRI
27 BASEPRI_MAX
28 CFBP (CONTROL/FAULT/BASEPRI/PRIMASK)
Table 3.1:
Flash download and flash breakpoints are also available for RDI with Cortex-M3, but
each needs an additional license.
3.1.3 Limitations
Their are no known limitations. All features including download into flash (add.
license) and breakpoints in flash memory (add. license) can be used.
3.2 ARM’s AXD (ARM Developer Suite, ADS)

The JLinkRDI.dll has been tested with ARM’s AXD version 1.2.0 and 1.2.1.
There should be no problems with other versions of ARM’s AXD.
All screenshots are taken from ARM’s AXD version 1.2.0.

25

1. Start the ARM debugger and select Options | Configure Target.... This opens the
Choose Target dialog box:
2. Press the Add Button to add the JLinkRDI.dll .

3. Now the J-Link RDI is in the Target Environments list.
4. Select J-Link and press OK to connect to the target via J-Link ARM. To configure
J-Link RDI refer to the chapter Configuration on page 41. After downloading an
image to the target board, the debugger window looks as follows:
3.2.3 Limitations

27
3.3 ARM’s RVDS (RealView developer suite)

The JLinkRDI.dll has been tested with ARM’s RVDS version 2.1 and 3.0. There
should be no problems with earlier versions of RVDS (up to version v3.0.1). RVDS
version 3.1 does not longer support RDI protocol to communicate with the debugger.
All screenshots are taken from ARM’s RVDS version 2.1.

1. Start the Real View debugger:

2. Select File | Connection | Connect to Target .
3. In the Connection Control dialog use the right mouse click on the first item and
select Add/Remove/Edit Devices

29
4. Now select Add DLL to add the JLinkRDI.dll . Select the installation path of the
software, for example:
C:\Program Files\SEGGER\JLinkARM_V350g\JLinkRDI.dll
5. After adding the DLL, an additional Dialog opens and asks for description: (These
values are voluntary, if you do not want change them, just click OK ) Use the fol-
lowing values and click on OK , Short Name: JLinkRDI Description: J-Link
ARM RDI Interface .

6. Back in the RDI Target List Dialog

Select JLink-RDI and click Configure. For configuration details refer to chapter
Configuration on page 41.
7. Click the OK button in the configuration dialog. Now close the RDI Target List
dialog. Be sure your target hardware is already connected to J-Link.

31
8. In the Connection control dialog, expand the JLink ARM RDI Interface and
select the ARM_0 Processor. Close the Connection Control Window.
9. Now the RealView Debugger is connected to J-Link.

10. A project or an image is needed for debugging. After downloading, J-Link is used
to debug the target.
3.3.3 Limitations

33
3.4 GHS MULTI

The JLinkRDI.dll has been tested with GHS MULTI version 4.07. There should be no
problems with other versions of GHS MULTI.
All screenshots are taken from GHS MULTI version 4.07.

1. Start Green Hills Software MULTI integrated development environment. Click Con-
nect | Connection Organizer to open the Connection Organizer.
2. Click Method | New in the Connection Organizer dialog.
3. The Create a new Connection Method will be opened. Enter a name for your
configuration in the Name field and select Custom in the Type list. Confirm your
choice with the Create... button.

4. The Connection Editor dialog will be opened. Enter rdiserv in the Server field
and enter the following values in the Arguments field:
-config -dll <FullPathToJLinkDLLs>
Note that JLinkRDI.dll and JLinkARM.dll must be stored in the same directory.
If you have used the standard J-Link installation path or another path that
includes spaces, enclose the path in quotation marks.
Example:
-config -dll "C:\Program Files\SEGGER\JLinkARM_V350g\JLinkRDI.dll"
Refer to GHS manual "MULTI: Configuring Connections for ARM Targets", chapter
"ARM Remote Debug Interface (rdiserv) Connections" for the complete list of
possible arguments.
5. Confirm your choices by clicking the Apply button and click afterwards the Con-
nect button.

35
6. The J-Link RDI Configuration dialog will be opened. J-Link RDI requires a valid
license. If you do not have entered your J-Link RDI license, click License and
add your license with the J-Link RDI License management . Refer to chapter
Configuration on page 41 for further information about the options of the J-Link
RDI Configuration dialog and the usage of the License Manager.
7. Click the OK button to connect to your target.

8. Build your project and start the debugger. Note that you have to perform at least
one action (for example step or run ) to initiate the download of your application
to the target.
3.4.3 Limitations

3.5 KEIL µVision IDE

The JLinkRDI.dll has been tested with KEIL µVision3 IDE version 3.34. There
should be no problems with other versions of KEIL µVision.
All screenshots are taken from KEIL µVision3 version 3.34.

Start KEIL uVision and open your project.

37
Select Project | Options for Target ’<NameOfYourTarget>’ to open the project

options dialog and select the Debug tab.
Choose RDI Interface Driver from the list as shown above and click the Settings
button. Select the location of JLinkRDI.dll in Browse for RDI Driver DLL field.
and click the Configure RDI Driver button.
The J-Link RDI Configuration dialog will be opened. For detailed information about
the confiiguration of J-Link RDI, refer to chapter Configuration on page 41.

After finishing configuration, you can build your project (Project | Build Target )
and start the debugger ( Debug | Start/Stop debug session ).

39
Configuring flash download via J-Link RDI

You can use the J-Link RDI flash download feature instead of the standard µVision-
flash loader.
Note: This feature requires an additional licence. A free trial license is avaliable
upon request from www.segger.com .
If you have the required licence and want to use J-Link RDI also for flash download,
select Flash | Configure Flash Tools and choose RDI Interface Driver from the
list in the Configure Flash Menu Command as shown below.
Click the Settings button and select J-Link Flash Programmer in the Select Flash
Programmer dialog. Confirm your choice with a click on the OK button.
Refer to subchapter Flash configuration on page 48 for detailed information about the
configuration of the flash programming feature.
3.5.3 Limitations


41
Chapter 4
Configuration
This chapter describes how to confgure J-Link RDI.

42 CHAPTER 4 Configuration
4.1 Overview
This chapter provides a short overview about the configuration abilities of J-Link RDI.
Normally, the default settings can be used.
4.1.1 Configuration file JLinkRDI.ini

All settings are stored in the file JLinkRDI.ini . This file is located in the same direc-
tory as JLinkRDI.dll.
4.1.2 Using different configurations

It can be desirable to use different configurations for different targets. If you intent
to do this, you should create a new folder and copy the JLinkARM.dll and the
JLinkRDI.dll into it. You can now have project A which uses the DLLs in the original
folder and project B which uses the DLLs in the newly created directory. Both projects
will use separate configuration files, stored in the same directory as the DLLs they
are using.
If your debugger allows using a project-relative path (such as IAR's EWARM: Use for
example $PROJ_DIR$\RDI\ ), it can make sense to create the directory for the DLLs
and configuration file in a subdirectory of the project.
4.1.3 Using mutliple J-Links simulatenously

This procedure can also be used to operate 2 J-Links with different settings on the
same host at the same time.

43
4.2 Configuration dialog

The configuration dialog consists of several tabs making the configuration of J-Link
RDI an easy step.
4.2.1 General
4.2.1.1 Connection to J-Link

This setting allows to configure if J-Link ARM is connected locally via USB or is con-
nected on a remote system and should be accessed by a given network address.
4.2.1.2 About
Opens the "About" window.

4.2.1.3 License (J-Link RDI License managment)

1. The License button opens the J-Link RDI License management dialog. J-Link
RDI requires a valid license.
2. Click the Add license button and enter your license. Confirm your input by click-
ing the OK button.
3. The J-Link RDI license is now added.

45
4.2.2 Init
4.2.2.1 Macro file

A macro file can be specified to load custom settings to configure J-Link RDI with
advanced commands for special chips or operations. For example a macro file can be
used to initialize a target system in just about any way required.

4.2.3 Comands in the macro file

Command Description
SetJTAGSpeed(x); Sets the JTAG speed, x = speed in kHz (0=Auto)
Waits a given time,
Delay(x);
x = delay in milliseconds
Resets the target,
Reset(x);
x = delay in milliseconds
Go(); Starts the ARM core
Halt(); Halts the ARM core
Read8(Addr);
Reads a 8/16/32 bit value,
Read16(Addr);
Addr = address to read (as hex value)
Read32(Addr);
Verify8(Addr, Data); Verifies a 8/16/32 bit value,
Verify16(Addr, Data); Addr = address to verify (as hex value)
Verify32(Addr, Data); Data = data to verify (as hex value)
Write8(Addr, Data); Writes a 8/16/32 bit value,
Write16(Addr, Data); Addr = address to write (as hex value)
Write32(Addr, Data); Data = data to write (as hex value)
WriteVerify8(Addr, Data); Writes and verifies a 8/16/32 bit value,
WriteVerify16(Addr, Data); Addr = address to write (as hex value)
WriteVerify32(Addr, Data); Data = data to write (as hex value)
WriteRegister(Reg, Data); Writes a register
WriteJTAG_IR(Cmd); Writes the JTAG instruction register
WriteJTAG_DR(nBits, Data); Writes the JTAG data register
Table 4.1: Macro file commands
4.2.4 Example of macro file

/*********************************************************************
*
* Macro file for J-LINK RDI
*
**********************************************************************
* File: LPC2294.setup
* Purpose: Setup for Philips LPC2294 chip
**********************************************************************
*/
SetJTAGSpeed(1000);
Reset(0);
Write32(0xE01FC040, 0x00000001); // Map User Flash into Vector area at (0-3f)
Write32(0xFFE00000, 0x20003CE3); // Setup CS0
Write32(0xE002C014, 0x0E6001E4); // Setup PINSEL2 Register
SetJTAGSpeed(2000);

47
4.2.5 JTAG
4.2.5.1 JTAG speed

This allows the selection of the JTAG speed. There are basically three types of speed
settings (which are explained below):
• Fixed JTAG speed
• Automatic JTAG speed
• Adaptive clocking
Fixed JTAG speed
The target is clocked at a fixed clock speed. The maximum JTAG speed the target can
handle depends on the target itself. In general ARM cores without JTAG synchroniza-
tion logic (such as ARM7-TDMI) can handle JTAG speeds up to the CPU speed, ARM
cores with JTAG synchronization logic (such as ARM7-TDMI-S, ARM946E-S,
ARM966EJ-S) can handle JTAG speeds up to 1/6 of the CPU speed. JTAG speeds of
more than 10 MHz are not recommended.
Automatic JTAG speed
Selects automatically the maximum JTAG speed handled by the TAP controller.
Note: On ARM cores without synchronization logic, this may not work reliably,
since the CPU core may be clocked slower than the maximum JTAG speed.
Adaptive clocking
If the target provides the RTCK signal, select the adaptive clocking function to syn-
chronize the clock to the processor clock outside the core. This ensures there are no
synchronization problems over the JTAG interface.

Note: If you use the adaptive clocking feature, transmission delays, gate delays,
and synchronization requirements result in a lower maximum clock frequency than
with non-adaptive clocking. Do not use adaptive clocking unless it is required by the
hardware design.
4.2.5.2 JTAG scan chain with multiple devices

The JTAG scan chain allows to specify the instruction register organization of the tar-
get system. This may be needed if there are more devices located on the target sys-
tem than the ARM chip you want to access or if more than one target system is
connected to one J-Link ARM at once.
4.2.6 Flash configuration
4.2.6.1 Enable flash programming

This checkbox enables flash programming. Flash programming is needed to use
either flash download or to use flash breakpoints.
If flash programming is enabled you must select the correct flash memory and flash
base address. Furthermore it is necessary for some chips to enter the correct CPU
clock frequence.
4.2.6.2 Cache flash contents

If enabled, the flash contents is cached by the J-Link RDI software to avoid reading
data twice and to speed up the transfer between debugger and target.

49
4.2.6.3 Allow flash download

This allows the J-Link RDI software to download program into flash. A small piece of
code will be downloaded and executed in the target RAM which then programs the
flash memory. This provides flash loading abilities even for debuggers without a
build-in flash loader.
An info window can be shown during download displaying the current operation.
Depending on your JTAG speed you may see the info window only very short.
4.2.7 Breakpoints
4.2.7.1 Use software breakpoints

This allows to set an unlimited number of breakpoints if the program is located in
RAM by setting and resetting breakpoints according to program code.
4.2.7.2 Use flash breakpoints

This allows to set an unlimited number of breakpoints if the program is located either
in RAM or in flash by setting and resetting breakpoints according to program code.

An info window can be displayed while flash breakpoints are used showing the cur-
rent operation. Depending on your JTAG speed the info window may only hardly to be
seen.
4.2.8 CPU
4.2.8.1 Instruction set simulation

This enables instruction set simulation which speeds up single stepping instructions
especially when using flash breakpoints.
4.2.8.2 Reset strategy

This defines the behavior how J-Link RDI should handle resets called by software.
J-Link supports different reset strategies. This is necessary because there is no single
way of resetting and halting an ARM core before it starts to execute instructions.
What is the problem if the core executes some instructions after RESET?
The instructions executed can cause various problems. Some cores can be completely
"confused", which means they can not be switched into debug mode (CPU can not be
halted). In other cases, the CPU may already have initialized some hardware compo-

51
nents, causing unexpected interrupts or worse, the hardware may have been initial-
ized with illegal values. In some of these cases, such as illegal PLL settings, the CPU
may be operated beyond specification, possibly locking the CPU.
Available reset strategies
The following reset strategies, described in detail below, are available:
• Hardware, halt after reset (normal)
• Hardware, halt after reset using WP
• Hardware, halt after reset using DBGRQ
• Hardware, halt with BP@
• Software, for Analog Devices ADuC7xxx MCUs
• No reset
Hardware, halt after reset (normal)
The hardware reset pin is used to reset the CPU. After reset release, J-Link continu-
ously tries to halt the CPU. This typically halts the CPU shortly after reset release;
the CPU can in most systems execute some instructions before it is halted. The num-
ber of instructions executed depends primarily on the JTAG speed: the higher the
JTAG speed, the faster the CPU can be halted.
Some CPUs can actually be halted before executing any instruction, because the start
of the CPU is delayed after reset release. If a pause has been specified, J-Link waits
for the specified time before trying to halt the CPU. This can be useful if a bootloader
which resides in flash or ROM needs to be started after reset.
Hardware, halt after reset using WP
The hardware RESET pin is used to reset the CPU. After reset release, J-Link continu-
the CPU can in most systems execute some instructions before it is halted.
The number of instructions executed depends primarily on the JTAG speed: the
higher the JTAG speed, the faster the CPU can be halted. Some CPUs can actually be
halted before executing any instruction, because the start of the CPU is delayed after
reset release.
Hardware, halt after reset using DBGRQ
The hardware RESET pin is used to reset the CPU. After reset release, J-Link continu-
the CPU can in most systems execute some instructions before it is halted.
The number of instructions executed depends primarily on the JTAG speed: the
higher the JTAG speed, the faster the CPU can be halted. Some CPUs can actually be
halted before executing any instruction, because the start of the CPU is delayed after
reset release.
Hardware, halt with BP@0
The hardware reset pin is used to reset the CPU. Before doing so, the ICE breaker is
programmed to halt program execution at address 0; effectively a breakpoint is set
at address 0. If this strategy works, the CPU is actually halted before executing a sin-
gle instruction.
This reset strategy does not work on all systems for two reasons:
• If nRESET and nTRST are coupled, either on the board or the CPU itself, reset
clears the breakpoint, which means the CPU is not stopped after reset.
• Some MCUs contain a bootloader program (sometimes called kernel), which
needs to be executed to enable JTAG access.
Software, for Analog Devices ADuC7xxx MCUs
The following sequence is executed:
• The CPU is halted
• A software reset sequence is downloaded to RAM

• A breakpoint at address 0 is set

• The software reset sequence is executed
This sequence performs a reset of CPU and peripherals and halts the CPU before exe-
cuting instructions of the user program. It is recommended reset sequence for Ana-
log Devices ADuC7xxx MCUs and works with these chips only.
No reset
No reset is performed.

53
4.2.9 Log
A log file can be generated for J-Link ARM and J-Link RDI. This log files may be useful
for debugging and evaluating. They may help you to solve a problem yourself but is
also needed by the support to help you with it.
Default path of the J-Link ARM log file: c:\JLinkARM.log
Default path of the J-Link RDI log file: c:\JLinkRDI.log
Example of logfile content:
060:028 (0000) Logging started @ 2005-10-28 07:36
060:028 (0000) DLL Compiled: Oct 4 2005 09:14:54
060:031 (0026) ARM_SetMaxSpeed - Testing speed 3F0F0F0F 3F0F0F0F 3F0F0F0F 3F0F0F0F
3F0F0F0F 3F0F0F0F 3F0F0F0F 3F0F0F0F 3F0F0F0F 3F0F0F0F 3F0F0F0F 3F0F0F0FAuto JTAG
speed: 4000 kHz
060:059 (0000) ARM_SetEndian(ARM_ENDIAN_LITTLE)
060:060 (0000) ARM_ResetPullsRESET(ON)
060:060 (0116) ARM_Reset(): SpeedIsFixed == 0 -> JTAGSpeed = 30kHz >48> >2EF>
060:176 (0000) ARM_WriteIceReg(0x02,00000000)
060:177 (0016) ARM_WriteMem(FFFFFC20,0004) -- Data: 01 06 00 00 - Writing 0x4 bytes
@ 0xFFFFFC20 >1D7>
060:194 (0014) ARM_WriteMem(FFFFFC2C,0004) -- Data: 05 1C 19 00 - Writing 0x4 bytes
@ 0xFFFFFC2C >195>
060:208 (0015) ARM_WriteMem(FFFFFC30,0004) -- Data: 07 00 00 00 - Writing 0x4 bytes
@ 0xFFFFFC30 >195>
060:223 (0002) ARM_ReadMem (00000000,0004)JTAG speed: 4000 kHz -- Data: 0C 00 00 EA
060:225 (0001) ARM_WriteMem(00000000,0004) -- Data: 0D 00 00 EA - Writing 0x4 bytes
@ 0x00000000 >195>
060:226 (0001) ARM_ReadMem (00000000,0004) -- Data: 0C 00 00 EA
060:227 (0001) ARM_WriteMem(FFFFFF00,0004) -- Data: 01 00 00 00 - Writing 0x4 bytes
@ 0xFFFFFF00 >195>
060:228 (0001) ARM_ReadMem (FFFFF240,0004) -- Data: 40 05 09 27
060:230 (0001) ARM_ReadMem (FFFFFF6C,0004) -- Data: 10 01 00 00
060:232 (0000) ARM_WriteMem(FFFFF124,0004) -- Data: FF FF FF FF - Writing 0x4 bytes
@ 0xFFFFF124 >195>
060:241 (0001) ARM_WriteMem(FFFFFD44,0004) -- Data: 00 80 00 00 - Writing 0x4 bytes
@ 0xFFFFFD44 >195>
060:277 (0000) ARM_WriteMem(00000000,0178) -- Data: 0F 00 00 EA FE FF FF EA ...
060:277 (0000) ARM_WriteMem(000003C4,0020) -- Data: 01 00 00 00 02 00 00 00 ... -
Writing 0x178 bytes @ 0x00000000
060:277 (0000) ARM_WriteMem(000001CC,00F4) -- Data: 30 B5 15 48 01 68 82 68 ... -
Writing 0x20 bytes @ 0x000003C4
060:277 (0000) ARM_WriteMem(000002C0,0002) -- Data: 00 47
060:278 (0000) ARM_WriteMem(000002C4,0068) -- Data: F0 B5 00 27 24 4C 34 4D ... -
Writing 0xF6 bytes @ 0x000001CC
060:278 (0000) ARM_WriteMem(0000032C,0002) -- Data: 00 47
060:278 (0000) ARM_WriteMem(00000330,0074) -- Data: 30 B5 00 24 A0 00 08 49 ... -
Writing 0x6A bytes @ 0x000002C4
060:278 (0000) ARM_WriteMem(000003B0,0014) -- Data: 00 00 00 00 0A 00 00 00 ... -
Writing 0x74 bytes @ 0x00000330
060:278 (0000) ARM_WriteMem(000003A4,000C) -- Data: 14 00 00 00 E4 03 00 00 ... -
Writing 0x14 bytes @ 0x000003B0
060:278 (0000) ARM_WriteMem(00000178,0054) -- Data: 12 4A 13 48 70 B4 81 B0 ... -
Writing 0xC bytes @ 0x000003A4
060:278 (0000) ARM_ResetPullsRESET(OFF)
060:278 (0009) ARM_Reset(): - Writing 0x54 bytes @ 0x00000178 >3E68>
060:287 (0001) ARM_Halt(): **** Warning: Chip has already been halted.
...


55
Chapter 5
Flash download
This chapter describes how to use flash download with J-Link RDI. It basically allows
a debugger to download program into flash even if the debugger does not have a
flash loader. This feature requires a separate license from SEGGER.

56 CHAPTER 5 Flash download
5.1 Overview
J-Link RDI flash download allows a debugger to download program into flash even if
the debugger does not have a flash loader. This way any RDI compliant debugger can
be used to download into any supported flash memory. From a debuggers perspec-
tive, the flash download works just like download to RAM; the flash programming is
handled completely by the J-Link RDI software.
Flash download is a feature of the J-Link RDI software, which requires a separate
license from SEGGER.
5.2 Why should I use RDI flash download?

Being able to download code directly into flash from the debugger or integrated IDE
significantly shortens the turn-around times when testing software. The flash loader
integrated into J-Link RDI is very efficient and allows fast flash programming. For
example, if a debugger splits the download image into several pieces, the flash
download software will collect the individual parts and perform the actual flash pro-
gramming right before program execution. This avoids repeated flash programming.
Once the setup of flash download is completed, flash breakpoints can be used with-
out additional configuration (if a license for this feature is present).
5.3 Enabling flash download

Before you can use flash download, some parameters need to be defined correctly
and the checkbox Enable flash programming needs to be checked. For a detailed
description please refer to the chapter Flash configuration on page 48.
5.4 Supported flash devices

For a list of all supported flash devices, please refer to the J-Link / J-Trace User
Guide (UM08001), chapter Flash download and flash breakpoints, section Supported
devices .

57
Chapter 6
Breakpoints in flash memory
This chapter describes how to configure and use breakpoints in flash memory.

58 CHAPTER 6 Breakpoints in flash memory
6.1 Introduction
The J-Link RDI software contains an additional feature, called flash breakpoints
(short FlashBPs). Flash breakpoints allow the user to set an unlimited number of
software breakpoints when debugging in flash memory, rather than just the 2 hard-
ware breakpoints. Setting the breakpoints in flash is executed very fast using a RAM
code specifically designed for this purpose; on chips with fast flash, the difference
between breakpoints in RAM and flash is unnoticeable. This feature requires an addi-
tional license from SEGGER.
6.2 How do breakpoints work?

There are basically 2 types of breakpoints in a computer system: Hard ones and soft
ones. Hardware breakpoints require a dedicate hardware unit for every breakpoint.
In other words, the hardware dictates how many hardware breakpoints can be set
simultaneously. ARM7 and ARM 9 cores have 2 breakpoint units (called "watchpoint
units" in ARM's documentation), allowing 2 hardware breakpoints to be set. Hardware
breakpoints do not require modification of the program code. Software breakpoints
are different: The debugger modifies the program and replaces the breakpointed
instruction with a special value. Additional software breakpoints do not require addi-
tional hardware units in the processor, since simply more instructions are replaced.
This is a standard procedure that most debuggers are capable of, however, it requires
the program to be located in RAM.
6.3 What is special about software breakpoints in

flash?
FlashBP allows you to set an unlimited number of breakpoints even if your application
program is not located in RAM, but in flash memory. This is a scenario which was very
rare before ARM-microcontrollers hit the market. This new technology makes very
powerful, yet inexpensive ARM microcontrollers available for systems, which required
external RAM before. The downside of this new technology is that it is not possible to
debug larger programs on these micros in RAM, since the RAM is not big enough to
hold program and data (typically, these chips contain about 4 times as much flash as
RAM), and therefore with standard debuggers, only 2 breakpoints can be set. The 2
breakpoint limit makes debugging very tough; a lot of times the debugger requires 2
breakpoints to simply step over a line of code. With software breakpoints in flash,
this limitation is gone.
6.4 How does this work?

Basically very simple:
The J-Link RDI software reprograms a sector of the flash to set or clear a breakpoint.
6.5 What performance can I expect?

A RAMCode, specially designed for this purpose, sets and clears flash breakpoints
extremely fast; on micros with fast flash the difference between breakpoints in RAM
and flash is hardly noticeable.
6.6 How is this performance achieved?

We have put a lot of effort in making flash breakpoints really usable and convenient.
Flash sectors are programmed only when necessary; this is usually the moment exe-
cution of the target program is started. A lot of times, more then one breakpoint is

59
located in the same flash sector, which allows programming multiple breakpoints by
programming just a single sector. The contents of program memory are cached,
avoiding time consuming reading of the flash sectors. A smart combination of soft-
ware and hardware breakpoints allows us to use hardware breakpoints a lot of times,
especially when the debugger is source level-stepping, avoiding reprogramming
flash in these situations. A built-in instruction set simulator further reduces the num-
ber of flash operations which need to be performed. This minimizes delays for the
user, maximizing the life time of the flash. All resources of the ARM micro are avail-
able to the application program, no memory is lost for debugging. All of the optimiza-
tions described above can be disabled.
6.7 Setting up flash breakpoints

1. Open the RDI configuration dialog box and click on the Flash tab.
2. Set the Enable flash programming checkbox and select your processor in the
Device list. Afterwards select the Breakpoint tab.

60 CHAPTER 6 Breakpoints in flash memory
3. Select Use software breakpoints as well as Use flash breakpoints . Then click
the OK button to close the J-Link RDI configuration dialog.
4. You can now use flash breakpoints with the debugger of your choice.

61
Chapter 7
Device specifics
This chapter gives some additional information about specific devices.

62 CHAPTER 7 Device specifics
7.1 Analog Devices

J-Link RDI flash programming supports the Analog Devices ADuC7xxx core family.
7.1.1 ADuC7xxx
J-Link RDI includes "ready-to-use" projects for all supported devices. For a complete
list of supported devices, open J-Link RDI configuration dialog and check the device
list of the Flash programming tab (refer to Flash configuration on page 48 for
detailed information). If you miss the support of a particular device, do not hesitate
to contact Segger.
Refer to J-Link / J-Trace User Guide for device specifics which are not related to flash
programming.

63
7.2 ATMEL
J-Link RDI flash programming supports the ATMEL AT91SAM7 core family.
7.2.1 AT91SAM7
to contact Segger.
programming.

7.3 NXP
J-Link RDI flash programming supports the NXP LPC core family.
7.3.1 LPC2xxx
to contact Segger.
Moreover J-Link RDI includes a device-based license for NXP LPC21xx-LPC24xx
devices which includes a free license for RDI, flash download and flash breakpoints.
For more information about the device-based license and how to enable it, please
refer to chapter Device-based license on page 17.
programming.

65
7.4 OKI
J-Link RDI flash programming supports the OKI ML67Q40x core family.
7.4.1 ML67Q40x
to contact Segger.
programming.

7.5 ST Microelectronics
J-Link RDI flash programming supports the ST Microelectronics STR71x, STR73x,
STR75x and the STR91x core families.
7.5.1 STR 71x

to contact Segger.
programming.
7.5.2 STR 73x

to contact Segger.
programming.
7.5.3 STR 75x

to contact Segger.
programming.
7.5.4 STR91x
to contact Segger.
programming.

67
7.6 Texas Instruments

J-Link RDI flash programming supports the TI TMS470 core family.
7.6.1 TMS470
to contact Segger.
programming.


69
Chapter 8
Semihosting
Semihosting is a mechanism for ARM targets to communicate input/output requests

from application code to a host computer running a debugger.
It effectively allows the target to do disk operations and console I/O and is used pri-
marily for flash loaders with ARM debuggers such as AXD.

70 CHAPTER 8 Semihosting
8.1 Overview
Semihosting
Semihosting is a mechanism for ARM targets to communicate input/output requests
from application code to a host computer running a debugger. This mechanism is
used, to allow functions in the C library, such as printf() and scanf() , to use the
screen and keyboard of the host rather than having a screen and keyboard on the
target system.
This is useful because development hardware often does not have all the input and
output facilities of the final system. Semihosting allows the host computer to provide
these facilities.
Semihosting is also used for Disk I/O and flash programming; a flash loader uses
semihosting to load the target program from disk.
Semihosting is implemented by a set of defined software interrupt (SWI) operations.
The application invokes the appropriate SWI and the debug agent then handles the
SWI exception. The debug agent provides the required communication with the host.
In many cases, the semihosting SWI will be invoked by code within library functions.
Usage of semihosting
The application can also invoke the semihosting SWI directly. Refer to the C library
descriptions in the ADS Compilers and Libraries Guide for more information on sup-
port for semihosting in the ARM C library.
Semihosting is not used by all tool chains; most modern tool chains (such as IAR)
use different mechanisms to achive the same goal.
Semihosting is used primarily by ARM’s tool chain and debuggers, such as AXD.
Since semihosting has been used primarily by ARM, documents published by ARM are
the best source of add. information.
For further information on semihosting and the C libraries, see the "C and C++
Libraries" chapter in ADS Compilers and Libraries Guide. Please see also the "Writing
Code for ROM" chapter in ADS Developer Guide.
8.2 The SWI interface

The ARM and Thumb SWI instructions contain a field that encodes the SWI number
used by the application code. This number can be decoded by the SWI handler in the
system. See the chapter on exception handling in ADS Developer Guide for more
information on SWI handlers.
Semihosting operations are requested using a single SWI number. This leaves the
other SWI numbers available for use by the application or operating system. The SWI
used for semihosting is:
0x123456 in ARM state
0xAB in Thumb state
The SWI number indicates to the debug agent that the SWI is a semihosting request.
In order to distinguish between operations, the operation type is passed in r0. All
other parameters are passed in a block that is pointed to by r1. The result is returned
in r0, either as an explicit return value or as a pointer to a data block. Even if no
result is returned, assume that r0 is corrupted.
The available semihosting operation numbers passed in r0 are allocated as follows:
0x00 to 0x31 These are used by ARM.
0x32 to 0xFF These are reserved for future use by ARM.
0x100 to 0x1FF Reserved for applications.

71
8.2.1 Changing the semihosting SWI numbers

It is strongly recommended that you do not change the semihosting SWI numbers
0x123456 (ARM) or 0xAB (Thumb). If you do so you must:
• change all the code in your system, including library code, to use the new SWI
number
• reconfigure your debugger to use the new SWI number.
8.3 Implementation of semihosting in J-Link RDI

When using J-Link RDI in default configuration, semihosting is implemented as fol-
lows:
• A breakpoint / vector catch is set on the SWI vector.
• When this breakpoint is hit, J-Link RDI examines the SWI number.
• If the SWI is recognized as a semihosting SWI, J-Link RDI emulates it and trans-
parently restarts execution of the application.
• If the SWI is not recognized as a semihosting SWI, J-Link RDI halts the processor
and reports an error. (See Unexpected / unhandled SWIs on page 72)
8.3.1 DCC semihosting

J-Link RDI does not support using the debug communications channel for semihost-
ing.
8.4 Semihosting with AXD

This semihosting mechanism can be disabled or changed by the following debugger
internal variables:
$semihosting_enabled
Set this variable to 0 to disable semihosting. If you are debugging an application run-
ning from ROM, this allows you to use an additional watchpoint unit.
Set this variable to 1 to enable semihosting. This is the default.
Set this variable to 2 to enable Debug Communications Channel (DCC) semihosting.
The S bit in $vector_catch has no effect unless semihosting is disabled.
$semihosting_vector
This variable controls the location of the breakpoint set by J-Link RDI to detect a
semihosted SWI. It is set to the SWI entry in the exception vector table () by default.
8.4.1 Using SWIs in your application

If your application requires semihosting as well as having its own SWI handler, set
$semihosting_vector to an address in your SWI handler. This address must point to
an instruction that is only executed if your SWI handler has identified a call to a
semihosting SWI. All registers must already have been restored to whatever values
they had on entry to your SWI handler.

72 CHAPTER 8 Semihosting
8.5 Unexpected / unhandled SWIs

When an unhandled SWI is detected by J-Link RDI, the message box below is shown.
This typically indicates that your application is using SWIs not only for semihosting,
but also for other purposes, but J-Link RDI stops on every SWI, which is inefficient
and affects the real-time behaviour of your application program. This is discouraged;
you should follow the instruction in the message box.

73
Chapter 9
Background information
This chapter provides background information about JTAG and ARM. The ARM7 and
ARM9 architecture is based on Reduced Instruction Set Computer (RISC) principles.
The instruction set and related decode mechanism are greatly simplified compared
with microprogrammed Complex Instruction Set Computer (CISC).

74 CHAPTER 9 Background information
9.1 JTAG
JTAG is the acronym for Joint Test Action Group. In the scope of this document,
"the JTAG standard" means compliance with IEEE Standard 1149.1-2001.
9.1.1 Test access port (TAP)

JTAG defines a TAP (Test access port). The TAP is a general-purpose port that can
provide access to many test support functions built into a component. It is composed
as a minimum of the three input connections (TDI, TCK, TMS) and one output con-
nection (TDO). An optional fourth input connection (nTRST) provides for asynchro-
nous initialization of the test logic.
PIN Type Explanation
The test clock input (TCK) provides the clock for the test
TCK Input
logic.
Serial test instructions and data are received by the test
TDI Input
logic at test data input (TDI).
The signal received at test mode select (TMS) is decoded

TMS Input
by the TAP controller to control test operations.
Test data output (TDO) is the serial output for test
TDO Output
instructions and data from the test logic.
Input
The optional test reset (TRST) input provides for asyn-
TRST (optional
chronous initialization of the TAP controller.
)
9.1.2 Data registers

JTAG requires at least two data registers to be present: the bypass and the bound-
ary-scan register. Other registers are allowed but are not obligatory.
Bypass data register
A single-bit register that passes information from TDI to TDO.
Boundary-scan data register
A test data register which allows the testing of board interconnections, access to
input and output of components when testing their system logic and so on.
9.1.3 Instruction register

The instruction register holds the current instruction and its content is used by the
TAP controller to decide which test to perform or which data register to access. It
consist of at least two shift-register cells.

75
9.1.4 The TAP controller

The TAP controller is a synchronous finite state machine that responds to changes at
the TMS and TCK signals of the TAP and controls the sequence of operations of the
circuitry.
Reset
tm s=1
tm s=0
tm s=1 tm s=1 tm s=1

Idle DR-Scan IR-Scan
tm s=0
tm s=0 tm s=0
tm s=1 tm s=1
Capture-DR Capture-IR
tm s=0 tm s=0
Shift-DR Shift-IR
tm s=1 tm s=0 tm s=1 tm s=0
Exit1-DR Exit1-IR
tm s=1 tm s=1
tm s=0 tm s=0
Pause-DR Pause-IR
tm s=0 tm s=0
Exit2-DR Exit2-IR
tm s=1 tm s=1
Update-DR Update-IR
9.1.4.1 State descriptions

Reset
The test logic is disabled so that normal operation of the chip logic can continue
unhindered. No matter in which state the TAP controller currently is, it can change
into Reset state if TMS is high for at least 5 clock cycles. As long as TMS is high, the
TAP controller remains in Reset state.
Idle
Idle is a TAP controller state between scan (DR or IR) operations. Once entered, this
state remains active as long as TMS is low.
DR-Scan
Temporary controller state. If TMS remains low, a scan sequence for the selected
data registers is initiated.
IR-Scan
Temporary controller state. If TMS remains low, a scan sequence for the instruction
register is initiated.
Capture-DR
Data may be loaded in parallel to the selected test data registers.
Shift-DR
The test data register connected between TDI and TDO shifts data one stage towards
the serial output with each clock.

Exit1-DR
Temporary controller state.
Pause-DR
The shifting of the test data register between TDI and TDO is temporarily halted.
Exit2-DR
Temporary controller state. Allows to either go back into Shift-DR state or go on to
Update-DR.
Update-DR
Data contained in the currently selected data register is loaded into a latched parallel
output (for registers that have such a latch). The parallel latch prevents changes at
the parallel output of these registers from occurring during the shifting process.
Capture-IR
Instructions may be loaded in parallel into the instruction register.
Shift-IR
The instruction register shifts the values in the instruction register towards TDO with
each clock.
Exit1-IR
Temporary controller state.
Pause-IR
Wait state that temporarily halts the instruction shifting.
Exit2-IR
Temporary controller state. Allows to either go back into Shift-IR state or go on to
Update-IR.
Update-IR
The values contained in the instruction register are loaded into a latched parallel out-
put from the shift-register path. Once latched, this new instruction becomes the cur-
rent one. The parallel latch prevents changes at the parallel output of the instruction
register from occurring during the shifting process.
9.2 The ARM core

The ARM7 family is a range of low-power 32-bit RISC microprocessor cores. Offering
up to 130MIPs (Dhrystone2.1), the ARM7 family incorporates the 16-bit Thumb
instruction set. The family consists of the ARM7TDMI, ARM7TDMI-S and ARM7EJ-S
processor cores and the ARM720T cached processor macrocell.
The ARM9 family is built around the ARM9TDMI processor core and incorporates the
16-bit Thumb instruction set. The ARM9 Thumb family includes the ARM920T and
ARM922T cached processor macrocells.

77
9.2.1 Processor modes

The ARM architecture supports seven processor modes.
Processor mode Description

User usr Normal program execution mode
System sys Runs privileged operating system tasks
Supervisor svc A protected mode for the operating system
Abort abt Implements virtual memory and/or memory protection
Undefined und Supports software emulation of hardware coprocessors
Interrupt irq Used for general-purpose interrupt handling
Fast inter-
fiq Supports a high-speed data transfer or channel process
rupt
Table 9.1: ARM processor modes
9.2.2 Registers of the CPU core

The CPU core has the following registers:
User/ Fast
Supervisor Abort Undefined Interrupt
System interrupt
R0
R1
R2
R3
R4
R5
R6
R7
R8 R8_fiq
R9 R9_fiq
R10 R10_fiq
R11 R11_fiq
R12 R12_fiq
R13 R13_svc R13_abt R13_und R13_irq R13_fiq
R14 R14_svc R14_abt R14_und R14_irq R14_fiq
PC
CPSR
SPSR_svc SPSR_abt SPSR_und SPSR_irq SPSR_fiq
Table 9.2: ARM CPU registers
= indicates that the normal register used by User or System mode has been
replaced by an alternative register specific to the exception mode.
The ARM core has a total of 37 registers:

• 31 general-purpose registers, including a program counter. These registers are
32 bits wide.
• 6 status registers. These are also 32-bits wide, but only 12-bits are allocated or
need to be implemented.
Registers are arranged in partially overlapping banks, with a different register bank
for each processor mode. At any time, 15 general-purpose registers (R0 to R14), one
or two status registers and the program counter are visible.

9.2.3 ARM /Thumb instruction set

An ARM core starts execution in ARM mode after reset or any type of exception. Most
(but not all) ARM cores come with a secondary instruction set, called the Thumb
instruction set. The core is said to be in Thumb mode if it is using the thumb instruc-
tion set. The thumb instruction set consists of 16-bit instructions, where the ARM
instruction set consists of 32-bit instructions. Thumb mode improves code density by
approximately 35%, but reduces execution speed on systems with high memory
bandwidth (because more instructions are required). On systems with low memory
bandwidth, Thumb mode can actually be as fast or faster than ARM mode. Mixing
ARM and Thumb code (interworking) is possible.
J-Link ARM fully supports debugging of both modes without limitation.
9.3 EmbeddedICE
EmbeddedICE is a set of registers and comparators used to generate debug excep-
tions (such as breakpoints).
EmbeddedICE is programmed in a serial fashion using the ARM core controller. It
consists of two real-time watchpoint units, together with a control and status regis-
ter. You can program one or both watchpoint units to halt the execution of instruc-
tions by ARM core. Two independent registers, debug control and debug status,
provide overall control of EmbeddedICE operation.
Execution is halted when a match occurs between the values programmed into
EmbeddedICE and the values currently appearing on the address bus, data bus, and
various control signals. Any bit can be masked so that its value does not affect the
comparison.
Either of the two real-time watchpoint units can be configured to be a watchpoint
(monitoring data accesses) or a breakpoint (monitoring instruction fetches). You can
make watchpoints and breakpoints data-dependent.
EmbeddedICE is an additional debug hardware within the core, therefore the Embed-
dedICE debug architecture requires almost no target resources (for example, mem-
ory, access to exception vectors, and time).
9.3.1 Breakpoints and watchpoints

Breakpoints
A "breakpoint" stops the core when a selected instruction is executed. It is then pos-
sible to examine the contents of both memory (and variables).
Watchpoints
A "watchpoint" stops the core if a selected memory location is accessed. For a watch-
point (WP), the following properties can be specified:
• Address (including address mask)
• Type of access (R, R/W, W)
• Data (including data mask)
Software / hardware breakpoints
Hardware breakpoints are "real" breakpoints, using one of the 2 available watchpoint
units to breakpoint the instruction at any given address. Hardware breakpoints can
be set in any type of memory (RAM, ROM, Flash) and also work with self-modifying
code. Unfortunately, there is only a limited number of these available (2 in the
EmbeddedICE). When debugging a program located in RAM, another option is to use
software breakpoints. With software breakpoints, the instruction in memory is modi-
fied. This does not work when debugging programs located in ROM or Flash, but has
one huge advantage: The number of software breakpoints is not limited.

79
9.3.2 The ICE registers

The two watchpoint units are known as watchpoint 0 and watchpoint 1. Each contains
three pairs of registers:
• address value and address mask
• data value and data mask
• control value and control mask
The following table shows the function and mapping of EmbeddedICE registers.
Register Width Function

0x00 3 Debug control
0x01 5 Debug status
0x04 6 Debug comms control register
0x05 32 Debug comms data register
0x08 32 Watchpoint 0 address value
0x09 32 Watchpoint 0 address mask
0x0A 32 Watchpoint 0 data value
0x0B 32 Watchpoint 0 data mask
0x0C 9 Watchpoint 0 control value
0x0D 8 Watchpoint 0 control mask
0x10 32 Watchpoint 1 address value
0x11 32 Watchpoint 1 address mask
0x12 32 Watchpoint 1 data value
0x13 32 Watchpoint 1 data mask
0x14 9 Watchpoint 1 control value
0x15 8 Watchpoint 1 control mask
Table 9.3: Function and mapping of EmbeddedICE registers
For more information about EmbeddedICE please see the technical reference manual
of your ARM CPU. (www.arm.com)
9.4 Flash programming

J-Link ARM comes with a DLL, which allows - amongst other functionalities - reading
and writing RAM, CPU registers, starting and stopping the CPU and setting break-
points. The standard DLL does not have API functions for flash programming. How-
ever, the functionality offered can be used to program the flash. In that case a
flashloader is required.
9.4.1 How does flash programming via J-Link ARM work ?

This requires extra code. This extra code typically downloads a program into the RAM
of the target system, which is able to erase and program the flash memory. This pro-
gram is called RAMCode and "knows" how to program the flash; it contains an imple-
mentation of the flash programming algorithm for the particular flash. Different flash
devices have different programming algorithms; the programming algorithm also
depends on other things such as endianess of the target system and organization of
the flash memory (e.g. 1*8 bits, 1*16 bits, 2*16 bits or 32 bits). The RAMCode also
requires the data to be programmed into the flash memory. There are two ways of
supplying this data:
• Data download to RAM
• Data download via DCC.

9.4.1.1 Data download to RAM

The data (or part of it) is downloaded to an other part of the RAM of the target sys-
tem. The instruction pointer (R15) of the CPU is then set to the start address of the
RAMCode, the CPU is started, executing the RAMCode. The RAMCode, which contains
the programming algorithm for the flash chip, copies the data into the flash chip. The
CPU is stopped after this. This process may have to be repeated until the entire data
is programmed into the flash.
9.4.1.2 Data download via DCC

In this case, the RAMCode is started as described above before downloading any
data. The RAMCode then communicates with the PC (via DCC, JTAG and J-Link ARM),
transferring data to the target. The RAMCode then programs the data into flash and
waits for new data from the host. The write memory functions of J-Link ARM are used
to transfer the RAMCode only, but not to transfer the data. The CPU is started and
stopped only once. Using DCC for communication is typically faster than using write
memory functions for RAM download since the overhead is lower.
9.4.2 Available options for flash programming

There are different solutions available to program internal or external flash memory
connected to ARM cores using J-Link ARM.
9.4.2.1 J-Flash ARM - Complete flash programming solution.

J-Flash ARM is a stand-alone Windows application, which can read / write data files
and program the flash in almost any ARM core supported by J-Link ARM. J-Flash ARM
requires an extra license from SEGGER.
9.4.2.2 JLinkARMFlash.dll - A DLL with flash programming capabilities.

An enhanced version of the JLinkARM.dll with additional API functions, which allow
loading and programming of data files. This DLL comes with a sample executable, as
well as the source code of this executable and a project file. This can be an interest-
ing option if you want to write your own programs for production purposes.
This DLL also requires an extra license from SEGGER; please contact us for more
information.
9.4.2.3 J-Link RDI Flash download - Allows flash download from any
RDI-compliant tool chain.
RDI (Remote Debug Interface) is a standard for "debug transfer agents" such as J-
Link ARM. The J-Link RDI software allows using J-Link ARM from any RDI compliant
debugger. You can use the flash download option integrated in the J-Link RDI soft-
ware to download your application program into flash memory.
The J-Link RDI software as well as the flash download option require licenses from
SEGGER.
9.4.2.4 Flash loader of compiler / debugger vendor such as IAR.

A lot of debuggers (some of them integrated into a workbench / IDE) come with their
own flash loaders. The flash loaders can of course be used if they match to your flash
configuration, which is something that needs to be checked with the debugger ven-
dor.
9.4.2.5 Write your own flash loader

Implement your own flash loader using the functionality of the JLinkARM.dll as
described above. This can be a time consuming process and requires in-depth knowl-
edge of the flash programming algorithm used as well as the target system.

81
Chapter 10
FAQs
You can find in this chapter a collection of frequently asked questions (FAQs)
together with answers.

82 CHAPTER 10 FAQs
10.1 FAQs
Q: Which CPUs are supported?
A: J-Link RDI is based on J-Link ARM and should work with any ARM7 / ARM9 core.
For a list of supported cores see section “Supported ARM Cores” in the J-Link ARM
manual.
Q: Which CPUs are flash breakpoint supported?
A: For a list of supported cores see section Supported flash devices on page 56.
Q: What is the advantage of flash download versus the flash loader that comes with
my IDE?
A: In a lot of cases, the J-LINK RDI flash download is significantly faster than that
provided by the IDE. Another advantage is that it uses the same flash program-
ming code being used for flash breakpoints, so it is very easy to set up flash
breakpoints if you are already using J-Link RDI flash download.

83
Chapter 11
Support
This chapter contains troubleshooting tips together with solutions for common prob-
lems which might occur when using J-Link RDI. There are several steps you can take
before contacting support. Performing these steps can solve many problems and
often eliminates the need for assistance.

84 CHAPTER 11 Support
11.1 Troubleshooting
11.1.1 General procedure
If you experience problems with J-Link RDI, you should follow the steps below to
solve these problems:
1. Close all running applications on your host system.
2. Disconnect the J-Link ARM device from USB.
3. Power-off target.
4. Re-connect J-Link ARM with host system (attach USB cable).
5. Power-on target.
6. Try your target application again. If the problem vanished, you are done; other-
wise continue.
7. Close all running applications on your host system again.
8. Disconnect the J-Link ARM device from USB.
9. Power-off target.
10. Re-connect J-Link ARM with host system (attach USB cable).
11. Power-on target.
12. Start JLink.exe.
13. If JLink.exe reports the J-Link ARM serial number and the target processor’s
core ID, your J-Link ARM is working properly and cannot be the cause of the
problem.
14. If JLink.exe is unable to read the target processor’s core ID you should analyze
the communication between your target and J-Link ARM with a logic analyzer or
oscilloscope. Follow the instructions in chapter "Support|Signal analysis" in the J-
Link ARM users manual.
15. If your problem persists and you own an original Segger J-Link ARM (not an OEM
version), see section Contacting support on page 84.
11.1.2 Typical problem scenarios

J-Link RDI doesn’t seem to do anything
Most likely reason:
The J-Link RDI DLL may not initialized by the debugger.
Remedy:
Please restart your debugger.
11.2 Contacting support

Before contacting support, make sure you tried to solve your problem by following
the steps outlined in section General procedure on page 84. You may also try your J-
Link ARM with another PC and if possible with another target system to see if it works
there. If the device functions correctly, the USB setup on the original machine or
your target hardware is the source of the problem, not J-Link ARM.
If you need to contact support, please send the following information to
support@segger.com:
• A detailed description of the problem.
• J-Link ARM serial number.
• Output of JLink.exe if available.
• Your findings of the signal analysis.
• Information about your target hardware (processor, board etc.).
J-Link ARM is sold directly by SEGGER or as OEM-product by other vendors. We can
support only official SEGGER products.

85
Chapter 12
Glossary
This chapter explains important terms used throughout this manual.

86 CHAPTER 12 Glossary
Application Program Interface

A specification of a set of procedures, functions, data structures, and constants that
are used to interface two or more software components together.
Big-endian
Memory organization where the least significant byte of a word is at a higher address
than the most significant byte. See Little-endian.
Cache cleaning
The process of writing dirty data in a cache to main memory.
Coprocessor
An additional processor that is used for certain operations, for example, for floating-
point math calculations, signal processing, or memory management.
Dirty data
When referring to a processor data cache, data that has been written to the cache
but has not been written to main memory. Only write-back caches can have dirty
data, because a write-through cache writes data to the cache and to main memory
simultaneously. The process of writing dirty data to main memory is called cache
cleaning.
Dynamic Linked Library (DLL)
A collection of programs, any of which can be called when needed by an executing
program. A small program that helps a larger program communicate with a device
such as a printer or keyboard is often packaged as a DLL.
EmbeddedICE
The additional hardware provided by debuggable ARM processors to aid debugging.
Host
A computer which provides data and other services to another computer. Especially, a
computer providing debugging services to a target being debugged.
ICache
Instruction cache.
ICE Extension Unit
A hardware extension to the EmbeddedICE logic that provides more breakpoint units.
ID
Identifier.
IEEE 1149.1
The IEEE Standard which defines TAP. Commonly (but incorrectly) referred to as
JTAG.
Image
An executable file that has been loaded onto a processor for execution.
In-Circuit Emulator (ICE)
A device enabling access to and modification of the signals of a circuit while that cir-
cuit is operating.
Instruction Register
When referring to a TAP controller, a register that controls the operation of the TAP.

87
IR
See Instruction Register.
Joint Test Action Group (JTAG)
The name of the standards group which created the IEEE 1149.1 specification.
Little-endian
Memory organization where the least significant byte of a word is at a lower address
than the most significant byte. See also Big-endian.
Memory coherency
A memory is coherent if the value read by a data read or instruction fetch is the
value that was most recently written to that location. Memory coherency is made dif-
ficult when there are multiple possible physical locations that are involved, such as a
system that has main memory, a write buffer and a cache.
Memory management unit (MMU)
Hardware that controls caches and access permissions to blocks of memory, and
translates virtual to physical addresses.
Memory Protection Unit (MPU)
Hardware that controls access permissions to blocks of memory. Unlike an MMU, an
MPU does not translate virtual addresses to physical addresses.
Multi-ICE
Multi-processor EmbeddedICE interface. ARM registered trademark.
nSRST
Abbreviation of System Reset. The electronic signal which causes the target system
other than the TAP controller to be reset. This signal is known as nSYSRST in some
other manuals. See also nTRST.
nTRST
Abbreviation of TAP Reset. The electronic signal that causes the target system TAP
controller to be reset. This signal is known as nICERST in some other manuals. See
also nSRST.
Open collector
A signal that may be actively driven LOW by one or more drivers, and is otherwise
passively pulled HIGH. Also known as a "wired AND" signal.
Processor Core
The part of a microprocessor that reads instructions from memory and executes
them, including the instruction fetch unit, arithmetic and logic unit and the register
bank. It excludes optional coprocessors, caches, and the memory management unit.
Program Status Register (PSR)
Contains some information about the current program and some information about
the current processor. Often, therefore, also referred to as Processor Status Register.
Is also referred to as Current PSR (CPSR), to emphasize the distinction between it
and the Saved PSR (SPSR). The SPSR holds the value the PSR had when the current
function was called, and which will be restored when control is returned.

88 CHAPTER 12 Glossary
Remapping
Changing the address of physical memory or devices after the application has started
executing. This is typically done to allow RAM to replace ROM once the initialization
has been done.
Remote Debug Interface (RDI)
RDI is an open ARM standard procedural interface between a debugger and the
debug agent. The widest possible adoption of this standard is encouraged.
Scan Chain
A group of one or more registers from one or more TAP controllers connected
between TDI and TDO, through which test data is shifted.
Semihosting
A mechanism whereby the target communicates I/O requests made in the application
code to the host system, rather than attempting to support the I/O itself.
SWI
Software Interrupt. An instruction that causes the processor to call a programer-
specified subroutine. Used by ARM to handle semihosting.
TAP Controller
Logic on a device which allows access to some or all of that device for test purposes.
The circuit functionality is defined in IEEE1149.1.
Target
The actual processor (real silicon or simulated) on which the application program
isrunning.
TCK
The electronic clock signal which times data on the TAP data lines TMS, TDI, and
TDO.
TDI
The electronic signal input to a TAP controller from the data source (upstream). Usu-
ally this is seen connecting the Multi-ICE Interface Unit to the first TAP controller.
TDO
The electronic signal output from a TAP controller to the data sink (downstream).
Usually this is seen connecting the last TAP controller to the Multi-ICE Interface Unit.
Test Access Port (TAP)
The port used to access a device's TAP Controller. Comprises TCK, TMS, TDI, TDO and
nTRST (optional).
Transistor-transistor logic (TTL)
A type of logic design in which two bipolar transistors drive the logic output to one or
zero. LSI and VLSI logic often used TTL with HIGH logic level approaching +5V and
LOW approaching 0V.
Watchpoint
A location within the image that will be monitored and that will cause execution to
stop when it changes.
Word
A 32-bit unit of information. Contents are taken as being an unsigned integer unless
otherwise stated.

89
Index
A JTAG ................................................. 74
Adaptive clocking .................................86 TAP controller ................................... 75
Application Program Interface ................86
ARM L
Processor modes ...............................77 Little-endian ....................................... 87
Registers ..........................................77
Thumb instruction set ........................78
M
Memory coherency .............................. 87
B Memory management unit (MMU) ......... 87
Big-endian ..........................................86 Memory Protection Unit (MPU) .............. 87
Multi-ICE ........................................... 87
C
Cache cleaning ....................................86 N
Coprocessor ........................................86 nSRST ............................................... 87
nTRST ............................................... 87
D
Dirty data ...........................................86 O
Dynamic Linked Library (DLL) ................86 Open collector .................................... 87
E P
EmbeddedICE ............................... 78, 86 Processor Core ................................... 87
Program Status Register (PSR) ............. 87
H
Host ...................................................86 R
Remapping ......................................... 88
I Remote Debug Interface (RDI) .............. 88
ICache ...............................................86
ICE Extension Unit ...............................86 S
ID .....................................................86 Scan Chain ......................................... 88
IEEE 1149.1 ........................................86 Semihosting ....................................... 88
Image ................................................86 Support ............................. 69, 81, 83, 85
In-Circuit Emulator ..............................86 SWI .................................................. 88
Instruction Register ..............................86 Syntax, conventions used ....................... 5
IR ......................................................87
T
J TAP Controller .................................... 88
J-Link Target ............................................... 88
FAQs ......................................... 70, 82 TCK ................................................... 88
Features ...........................................12 TDI ................................................... 88
Joint Test Action Group (JTAG) ...............87 TDO .................................................. 88

90 Index
Test Access Port (TAP) .......................... 88

Transistor-transistor logic (TTL) ............. 88
W
Watchpoint ....................................78, 88
Word ................................................. 88

User Guide of The J-Link RDI Interface For J-Link ARM Emulator

Uploaded by

Copyright:

Available Formats

User Guide of The J-Link RDI Interface For J-Link ARM Emulator

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

User Guide of The J-Link RDI Interface For J-Link ARM Emulator

Uploaded by

Copyright:

Available Formats

J-Link ARM RDI

User guide of the J-Link RDI Interface

Software Version 4.08

Date: August 6, 2009

A product of SEGGER Microcontroller GmbH & Co. KG

Manual version Date By Explanation

J-Link RDI(UM08004) © 2004-2009 SEGGER Microcontroller GmbH & Co. KG

Manual version Date By Explanation

J-Link RDI(UM08004) © 2004-2009 SEGGER Microcontroller GmbH & Co. KG

J-Link RDI(UM08004) © 2004-2009 SEGGER Microcontroller GmbH & Co. KG

About this document

Style Used for

Body Body text.

Text that you enter at the command-prompt or that appears on the

Parameter Parameters in API functions.

Reference Reference to chapters, tables and figures or other documents.

GUIElement Buttons, dialog boxes, menu names, menu commands.

Emphasis Very important sections

J-Link RDI(UM08004) © 2004-2009 SEGGER Microcontroller GmbH & Co. KG

SEGGER Microcontroller GmbH & Co. KG develops

Corporate Office: United States Office:

EMBEDDED SOFTWARE SEGGER TOOLS

J-Link RDI(UM08004) © 2004-2009 SEGGER Microcontroller GmbH & Co. KG

3 Using J-Link RDI with different debuggers.....................................................................21

J-Link RDI(UM08004) © 2004-2009 SEGGER Microcontroller GmbH & Co. KG

4.2.7 Breakpoints ............................................................................................ 49

6 Breakpoints in flash memory..........................................................................................57

7 Device specifics .............................................................................................................61

9 Background information .................................................................................................73

J-Link RDI(UM08004) © 2004-2009 SEGGER Microcontroller GmbH & Co. KG

9.3.2 The ICE registers ..................................................................................... 79

J-Link RDI(UM08004) © 2004-2009 SEGGER Microcontroller GmbH & Co. KG

J-Link RDI(UM08004) © 2004-2009 SEGGER Microcontroller GmbH & Co. KG

1.1 What is RDI?

RDI compliant + Data

J-Link RDI DLL

1.1.1 Features of J-Link RDI

J-Link RDI(UM08004) © 2004-2009 SEGGER Microcontroller GmbH & Co. KG

1.3 Basic principles

1.5 Required licenses

J-Link RDI(UM08004) © 2004-2009 SEGGER Microcontroller GmbH & Co. KG

J-Link RDI(UM08004) © 2004-2009 SEGGER Microcontroller GmbH & Co. KG

J-Link RDI(UM08004) © 2004-2009 SEGGER Microcontroller GmbH & Co. KG

2.2 Software components requiring a license

2.3 License types

J-Link RDI(UM08004) © 2004-2009 SEGGER Microcontroller GmbH & Co. KG

2.3.1 Built-in license

2.3.2 Key-based license

2.3.3 Device-based license

J-Link RDI(UM08004) © 2004-2009 SEGGER Microcontroller GmbH & Co. KG

2.3.3.1 Enabling a device-based license

2.3.3.2 Device list

J-Link RDI(UM08004) © 2004-2009 SEGGER Microcontroller GmbH & Co. KG

J-Link RDI(UM08004) © 2004-2009 SEGGER Microcontroller GmbH & Co. KG

J-Link RDI(UM08004) © 2004-2009 SEGGER Microcontroller GmbH & Co. KG

Using J-Link RDI with different

J-Link RDI(UM08004) © 2004-2009 SEGGER Microcontroller GmbH & Co. KG

3.1 IAR Embedded Workbench IDE

3.1.2 Configuring to use J-Link RDI