st200_cross_dev_manual.pdf

8/19/2019 ST200_Cross_Dev_Manual.pdf

1/172

STMicroelectronics

ST200 VLIW series

ST200 crossdevelopment manual

User manual

7521642 Rev L

November 2006


2/172

BLANK


3/172

November 2006 7521642 Rev L 1/ 170

User manualST200 VLIW series

ST200 cross development manual

Overview

The ST200 development system is a set of tools used to create programs for the ST200family of VLIW cores. It is a cross-development environment, in that the target machine forwhich the code is developed (for example, ST220) is distinct from the host machine onwhich the development tools run. As there are many situations in which the availability of atarget is not possible, a software simulator is provided on which to run and evaluate code.

This has the advantage of allowing software to be developed in parallel with the detaileddesign of the hardware, as well as permitting software considerations to exert a reciprocaleffect on hardware design (in cases where the hardware architecture has not beenfinalized).

www.st.com

http://-/?-http://www.st.com/http://-/?-http://www.st.com/


4/172

Contents ST200

2/ 170 7521642

Contents

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

ST200 document identification and control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

ST200 documentation suite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Conventions used in this guide. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1 Getting started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.1 Testing the compiler installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.2 Supported targets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.3 Connecting to a target . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.4 Target address space usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

1.5 st200run tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

1.6 Targets and target options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

1.6.1 Simulator options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

1.6.2 Board options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

1.7 st200gdb debugger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

1.7.1 GDI target command option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

1.7.2 GDI st200gdb commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

1.7.3 New startup configuration commands . . . . . . . . . . . . . . . . . . . . . . . . . . 33

1.7.4 Emulated system calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

1.8 Using the graphical user interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

1.8.1 Running a simple debugging session . . . . . . . . . . . . . . . . . . . . . . . . . . 35

1.8.2 Accessing other st200gdb functions . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

1.8.3 Using the ST2x0 Statistics window . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

1.8.4 Using the Performance Monitoring window . . . . . . . . . . . . . . . . . . . . . . 38

1.8.5 Displaying multiple Memory windows . . . . . . . . . . . . . . . . . . . . . . . . . . 39

1.8.6 Watch and local variables window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

1.8.7 Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

1.9 Configuring the program execution startup . . . . . . . . . . . . . . . . . . . . . . . 42

1.9.1 Initialization sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

1.9.2 Initialization hook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

http://-/?-http://-/?-


5/172

ST200 Contents

7521642 3/ 170

1.10 Configuring the run-time and boot code for a target . . . . . . . . . . . . . . . . . 44

1.10.1 The sysconf and boot code modules . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

1.10.2 Generating code for a board target . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

1.11 Using a custom board target . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

1.11.1 Defining a custom board target and compiling a program . . . . . . . . . . . 46

1.11.2 Debug a program on a custom hardware board target . . . . . . . . . . . . . 47

1.12 Modifying the memory protection settings . . . . . . . . . . . . . . . . . . . . . . . . 47

1.13 Rebuilding the run-time libraries and target modules . . . . . . . . . . . . . . . . 48

1.13.1 Rebuilding the target BSP tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

1.13.2 Rebuilding the lib tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

1.13.3 Rebuilding the OS21 libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

2 The STWorkbench and related plug-ins . . . . . . . . . . . . . . . . . . . . . . . . 50

2.1 STWorkbench installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

2.1.1 Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

2.2 Getting started with STWorkbench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

2.2.1 Configuring STWorkbench to work with the ST200 toolset . . . . . . . . . . 52

2.2.2 Creating and building a Hello World project . . . . . . . . . . . . . . . . . . . . . . 53

2.2.3 Debugging Hello World . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

2.3 STWorkbench customizations for ST200 . . . . . . . . . . . . . . . . . . . . . . . . . 55

2.3.1 ST200 preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

2.3.2 ST Profiler preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

2.3.3 Creating a new project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

2.3.4 Library names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

2.3.5 Project properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

2.3.6 Building, cleaning, rebuilding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

2.3.7 Running a program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

2.3.8 Analyzing a program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

2.3.9 Running and analyzing a program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

2.3.10 Debugging a program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

2.3.11 Debugging tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

3 ST200 simulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

3.1 Target configuration options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

3.2 The sample device plug-in for the ST200 simulator . . . . . . . . . . . . . . . . . 71

3.2.1 Callbacks into the simulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

3.2.2 Building and running the plug-in . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

http://-/?-http://-/?-


6/172

Contents ST200

4/ 170 7521642

3.3 The ST200 simulator plug-ins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

3.3.1 ST200 simulator plug-ins usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

4 Setting up a board . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 754.1 Introduction to setting up a board . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

4.2 Understanding target dependent settings . . . . . . . . . . . . . . . . . . . . . . . . 75

4.2.1 Toolset partitioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

4.2.2 Toolset configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

4.2.3 Configuration matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

4.3 Supported configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

4.3.1 ST220 and ST231 cores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

4.3.2 SoC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

4.3.3 Example of mb428_host and mb428_audio boards . . . . . . . . . . . . . . . 83

4.4 Integrating a new board in the toolset . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

4.4.1 Add a board file into the ST200 toolset . . . . . . . . . . . . . . . . . . . . . . . . . 84

4.4.2 Critical test suite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

4.5 Using the tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

4.5.1 Initialization sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

4.5.2 st200gdb commands for bring up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

4.5.3 Debug facilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

4.6 Bring up operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

4.6.1 Define an alias for the silicon connection settings . . . . . . . . . . . . . . . . . 87

4.6.2 Connect to the target through the ST Micro Connect . . . . . . . . . . . . . . 87

4.6.3 Perform the DSU register accesses . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

4.6.4 Perform the RAM accesses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

4.6.5 Execute the generated critical test suite . . . . . . . . . . . . . . . . . . . . . . . . 88

4.6.6 Compile and execute a C program . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

5 Relocatable loader library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

5.1 Introduction to the relocatable loader library . . . . . . . . . . . . . . . . . . . . . . 90

5.1.1 Run-time model overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

5.2 Relocatable run-time model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

5.2.1 The relocatable code generation model . . . . . . . . . . . . . . . . . . . . . . . . . 93

5.3 Relocatable loader library API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

5.4 Customization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

5.4.1 Memory allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

5.4.2 File management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

http://-/?-http://-/?-


7/172

ST200 Contents

7521642 5/ 170

5.5 Building a relocatable library or main module . . . . . . . . . . . . . . . . . . . . 108

5.5.1 Importing and exporting symbols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

5.5.2 Optimization options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

5.6 Debugging support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

5.7 Profiling support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

5.8 Memory protection support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

5.9 Load time decompression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

Appendix A ST200 board support package (BSP). . . . . . . . . . . . . . . . . . . . . . . 114

A.1 Introduction to board support packages . . . . . . . . . . . . . . . . . . . . . . . . . 114

A.1.1 Backward compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

A.1.2 Error handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114A.2 Caches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

A.2.1 Managing the caches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

A.2.2 Cache header file: machine/bsp/cache.h . . . . . . . . . . . . . . . . . . . . . . . 116

A.3 Instruction and data protection unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

A.3.1 IPU/DPU support functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

A.3.2 Initializing the IPU/DPU support system. . . . . . . . . . . . . . . . . . . . . . . . 116

A.3.3 Managing the IPU/DPU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

A.3.4 OS21 BSP for DPU/IPU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

A.4 Memory management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

A.4.1 Initial memory map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

A.4.2 Managing the MMU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

A.4.3 MMU header file: machine/bsp/mmu.h . . . . . . . . . . . . . . . . . . . . . . . . . 118

A.4.4 Speculative control unit (SCU) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

A.5 Timers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

A.5.1 Input clock frequency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

A.5.2 Tick duration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

A.5.3 Reading the current time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120A.5.4 ST200 timer assignments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

A.5.5 Timer header file: machine/bsp/timer.h. . . . . . . . . . . . . . . . . . . . . . . . . 122

A.6 Performance monitor (PM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

A.6.1 Hardware abstraction layer for the PM module. . . . . . . . . . . . . . . . . . . 124

A.7 Exception handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

A.7.1 Exceptions types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

A.7.2 Exceptions header file: machine/bsp/core.h . . . . . . . . . . . . . . . . . . . . . 127

http://-/?-http://-/?-


8/172

Contents ST200

6/ 170 7521642

A.8 Interrupts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

A.8.1 Interrupt handler installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

A.8.2 Interrupts header file: machine/bsp/interrupt.h . . . . . . . . . . . . . . . . . . . 127

A.9 OScalls and debug events suspension . . . . . . . . . . . . . . . . . . . . . . . . . . 128

A.10 Flash file system handling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

A.11 User handles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

A.12 BSP function definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

Revision history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

http://-/?-http://-/?-


9/172

ST200 Preface

7521642 7/ 170

Preface

ST200 document identification and control

Each book in the ST200 documentation suite carries a unique ADCS identifier of the form:

ADCS nnnnnnnx

where nnnnnnn is the document number, and x is the revision.

Whenever making comments on an ST200 document, the complete identificationADCS nnnnnnnx should be quoted.

ST200 documentation suite

The ST200 documentation suite comprises the following volumes:

ST200 Micro Toolset Compiler Manual

(ADCS 7508723) This manual describes the software provided as part of the ST200 tools. Itsupports the development of ST200 applications for embedded systems. Applications maybe developed in either a stand-alone environment, or under the OS21 real-time operatingsystem.

This manual also contains reference material relating to the ST200 Micro Toolset.

ST200 Cross Development Manual

(ADCS 7521642) This manual describes the cross development tools and platforms.

ST200 Run-time Architecture Manual

(ADCS 7521848) This manual describes the common software conventions for the ST200processor run-time architecture.

ST200 ELF Specification

(ADCS 7932400) This document describes the use of the ELF file format for the ST200processor. It provides information needed to create and interpret ELF files and is specific tothe ST200 processor.

OS21 for ST200 User Manual

(ADCS 7410372) This manual describes the use of OS21 on ST200 platforms. It describes

how specific ST200 facilities are exploited by the OS21 API. It also describes the OS21board support packages for ST200 platforms.

ST220 Core and Instruction Set Architecture

(ADCS 7395369) This manual describes the architecture and the instruction set of theST220 core as used by STMicroelectronics.

ST231 Core and Instruction Set Architecture

(ADCS 7645929) This manual describes the architecture and the instruction set of theST231 core as used by STMicroelectronics.

http://-/?-http://-/?-


10/172

Preface ST200

8/ 170 7521642

Conventions used in this guide

General notation

The notation in this document uses the following conventions:

● sample code, keyboard input and file names,

● variables and code variables,

● code comments,

● screens, windows and dialog boxes,

● instructions.

Hardware notation

The following conventions are used for hardware notation:

● REGISTER NAMES and FIELD NAMES,

● PIN NAMES and SIGNAL NAMES.

Software notation

Syntax definitions are presented in a modified Backus-Naur Form (BNF). Briefly:

1. Terminal strings of the language, that is, strings not built up by rules of the language,are printed in teletype font. For example, void.

2. Nonterminal strings of the language, that is, strings built up by rules of the language,are printed in italic teletype font. For example, name .

3. If a nonterminal string of the language starts with a nonitalicized part, it is equivalent tothe same nonterminal string without that nonitalicized part. For example, vspace-name .

4. Each phrase definition is built up using a double colon and an equals sign to separatethe two sides (‘::=’).

5. Alternatives are separated by vertical bars (‘|’).

6. Optional sequences are enclosed in square brackets (‘[’ and ‘]’).

7. Items which may be repeated appear in braces (‘{’ and ‘}’).

Mathematical notation

A range of values can be shown using square braces, [], and round braces, (). Squarebraces mean the nearest value is included, and round braces mean the nearest value is notincluded.

For example:

[1 .. 3] is the values 1, 2, 3,

[1 .. 3) is the values 1, 2,

(1 .. 3] is the values 2, 3,

(1 .. 3) is the value 2 only.

http://-/?-http://-/?-


11/172

ST200 Preface

7521642 9/ 170

Acknowledgements

Microsoft ® , Visual Studio ® and Windows ® are registered trademarks of MicrosoftCorporation in the United States and/or other countries.

SolarisTM is a trademark of Sun Microsystems, Inc. in the US and other countries.

CygwinTM and InsightTM are trademarks of Red Hat Software, Inc.

Linux ® is a registered trademark of Linus Torvalds.

http://-/?-http://-/?-


12/172

Getting started ST200

10/ 170 7521642

1 Getting started

1.1 Testing the compiler installation

On Solaris and Linux, the following simple test can be executed to check that the compiler iscorrectly installed.

cp -r /samples/hello .cd hello

make

where is the installation directory.

The string “Hello World !!” is displayed after the compilation and execution in thesimulator target.

On a Windows PC, the same test can be carried out by entering the following commandsthrough the console:

xcopy /I /Y \samples\hello .\hellocd hello

make

1.2 Supported targets

Different versions of the ST200 Micro Toolset support different targets.

The R5.0 toolset supports the ST220 and ST231 cores on the following targets: ST220 andST231 Simulator, STm8000-Demo Board (mb379), STm5700-Demo Board (mb385),ST230EMU-PCI Board (mb388a), STm8010-Mboard (mb421), ST231-EVAL board

(mb424), STm8010-REF Traviata (mb426), STb5525-Mboard (mb428) and STb7100/09-Refboard (mb442).

1.3 Connecting to a target

Figure 1 shows how to connect to a target from an ethernet based host via an ST MicroConnect(a).

a. The ST Micro Connect required is the ST40-Connect.

http://-/?-http://-/?-


13/172

ST200 Getting started

7521642 11/ 170

Figure 1. Connecting to a target

1.4 Target address space usage

By default, the toolset is configured for the program to load and execute in 8 Mbytes of LMIRAM memory (from 0x08000000 to 0x08800000). Figure 2 explains how the toolset usesthe ST200 address space to load and execute a C program when the program is compiledand executed with the default options.

In order to change the memory location where the program is loaded and executed, memorysettings must be changed in the board.ld linker script located in

/target/board/.Once DEFAULT_RAMEND, DEFAULT_TEXT_BASE and memory mapping have beenmodified, compile and run the program as usual. This is shown in the example provided in/samples/hello. See the README file for more information.

Board configuration has been designed to be flexible, so that it is possible to add a customboard with different memory and run-time settings. Guidelines are provided in Section 1.11:Using a custom board target on page 46 .

Silicon target

ST Micro ConnectSolaris, Linux or Windows host

Ethernetnetwork

(working at 10 MBaud)

http://-/?-http://-/?-


14/172


12/ 170 7521642

Figure 2. ST200 address space usage

Memory Space Comments

0x00000000RESET_ADDRESS

.boot

0x00010000BOOT_ADDRESS

.text

0x08000000TEXT_BASE

.data

.bss

scratch area

copy of env var

copy of args

kernel stack

scratch area

stack_pt -->

kstack_pt -->

RAMEND

Section loaded, and executed only if reset

mode is specified from st200run or st200gdb.This is the section where execution starts afterRESET signal is released.

Section loaded, and executed only if reset modeis specified from st200run or st200gdb.The default boot code executes external memoryinitialization, initializes the start parameters to thedefault ones then jumps to 0x08000000.

Section loaded.It contains the __start() entry point of the program.

.bootreset

Section loaded. Initialized C global variables aredirectly mapped at these addresses.

Not loaded, initialized to 0 at __start() execution,unless st200run --no_clear_bss is set orst200gdb startbss is set to no.

During the execution, the stack grows toward thedefault area where sections are loaded and the

16 bytes aligned area to setup the stack.

This area (before RAMEND) is used by st200run or

st200gdb to pass arg and env information to theprogram.

16 Kbytes reserved for the kernel stack.

16 bytes aligned area to setup the kernel stack0x08800000

_ramend

0xffffffff

This base address is configurable through theboard.ld script link dedicated to the target.

heap for malloc grows from the end of the .bsssection towards the stack.

http://-/?-http://-/?-


15/172


7521642 13/ 170

1.5 st200run tool

st200run enables the connection of an execution target, and enables an ST200 program toload and execute. Moreover, while the program is executing on the target, st200run is ableto emulate some system calls (syscall) on the host machine.

The system calls emulated are:

● All C standard I/O:inputs and outputs are read from and written to the console where the st200run command is executed.

● All C file I/O:files are opened, written to and closed in the host environment.

● exit() process termination:the exit() function is called on the host side, terminating the st200run process ormaking the debugged program exit under st200gdb.

The program is invoked as follows:

st200run [OPTIONS] [FILES]

The valid [OPTIONS] are described in Table 1 on page 14 . [FILES] must specify theprogram name and its arguments.

Note: If the “-” character precedes a program argument, it must be back-slashed twice (\\-) in orderto not be interpreted by st200run and sent to the target program.

Binary files are checked at load time to ensure they match one of the core versionssupported by the target. An error is displayed if they do not match.

A complete example of how to operate the st200run tool is provided in/samples/hello.

The --target (or -t) option is a compulsory option and should specify the alias name of apredefined target. The predefined targets are configured in the target description file. SeeSection 1.6 on page 19 for a full description of targets.

Two types of target are supported by the toolset: the simulator targets, based on the ST200cycle accurate reference simulator models, and real silicon targets. Section 1.2: Supportedtargets on page 10 details the targets supported by each toolset release.

There are three basic modes that can be used to run a simulation. They reflect the trade offin simulation accuracy against simulation speed.

● In Reference (or cycle accurate) mode, the pipeline is modelled, and by default, thecaches are configured to be at the highest level of detail. The memory subsystem/busis also faithfully modelled (including the write buffer and prefetch buffer), as are all therelevant protection/translation units (for example, IPU, DPU on the earlier ST200 coresand the UTLB + micro TLB’s on the ST231 cores onwards). This mode is guaranteed toexecute code in a similar manner to the hardware, that is, it behaves as expected in allexceptional circumstances. This includes the modelling of all types of bus errors,interrupts, debug interrupts and exceptions. Consequently, it has the lowestperformance of the three modes.

● In ISS (or instruction set accurate) mode, each instruction is run to completion beforethe next instruction begins (that is, it does not model the pipeline, latencies, interlockingand so on). It does model the caches (basic versions) and the protection/translationunits (IPU/DPU/UTLB), so (as with reference mode) in terms of exceptionalcircumstances, it behaves in a manner similar to the hardware.

http://-/?-http://-/?-


16/172


14/ 170 7521642

● In Fast (functional) mode, only the minimal set of components required to run correctcode ‘correctly’ are modelled. This mode does not model any of the memorysubsystem, caches, protection units (the UTLB however is present in the ST231model), bus errors, external interrupts or provide the device plug-in functionality.

Therefore, it has the highest performance, but the lowest accuracy.The simulator configuration options are described in Table 2 on page 20 .

Table 1. st200run options

Option Short form Description

--help -h

Display the st200run help and exit.

For example:

st200run -hst200run --help

--after_exec=

-a

This option submits a direct command(1) to the target, via

the GDI function DiDirectCommand(), after the program

has exited.For example:

st200run -astatistics -tsim hellost200run --after_exec=statistics -tsim hello

In the case above, st200run calls

DiDirectCommand("statistics") after the hello program has exited.

If the direct command contains several parameters, it must

be enclosed in double quotes. For example:

st200run –a"statistics file" –tsim hello

See Table 5 on page 28 for a list of all the available

simulator direct commands.

--before_exec=

-b

This option submits a direct command(1) to the target,before program execution, via the GDI function

DiDirectCommand().

For example:

st200run -bstatistics -tsim hellost200run --before_exec=statistics -tsimhello

In the case above, st200run calls

DiDirectCommand("statistics") before startingexecution of the hello program.

If the direct command contains several parameters, it must

be enclosed in double quotes. For example:

st200run –b"statistics file" –tsim helloSee Table 5 on page 28 for a list of all the available

simulator direct commands.

http://-/?-http://-/?-http://-/?-http://-/?-


17/172


7521642 15/ 170

--debug -D

st200run displays a variety of debug information during

load and run. This is stored in therun.log

file. Debug

information covers the following:

– module versions,

– DLL parameters,

– various information about GDI functions,

– system call information.

For example:

st200run -D -tsim hellost200run --debug -tsim hello

--detach -P

This option detaches st200run from application execution

on the silicon target (the default is off). No polling is

performed by st200run on the board to get the status on

application execution. The application’s oscalls are notserviced with this option.

For example:

st200run -P -tboard hellost200run --detach -tboard hello

--dll= -d

This option is used to specify a GDI dynamic target dll

name and associated target options.

The search strategy for the dynamic library is explained in

Search strategy for dynamic libraries on page 18 .

Appropriate file extensions are completed automatically

(.dll on Windows, .so on Solaris and Linux).

This facility can be used to patch an existing toolset with a

new version of a target dynamic linked library.For example:

st200run -dst200sim hellost200run --dll=st200sim hello

If the dll is called with options, it must be enclosed in double

quotes. For example:

st200run –d"st200sim 220" hello

Details of the available target options for the simulator

target are defined in Section 1.6 on page 19 .

--env -e

Pass the host environment to the target. By default, the host

environment is not passed.

For example:

st200run -tsim helloIn this case, if the hello program uses the getenv function, for example:

printf("PATH=%s\n",getenv("PATH"));the environment variable value is not displayed.

st200run -e -tsim hellost200run --env -tsim helloIn these cases, if the hello program uses the getenv function, for example:

printf("PATH=%s\n",getenv("PATH"));the environment variable value is displayed.

Table 1. st200run options (continued)




18/172


16/ 170 7521642

--force -f

Specifying this option bypasses any checks made on

memory, architecture or endianness at load time.

The following checks are carried out:

– check presence of memory before loading a section,

– check RAMEND address is located in a memory area,

– check if the execution engine is compatible with the core

for which the binary is generated,

– check if the target endianness is compatible with binary

endianness.

This option is useful while working with a new board or core

environment that is not fully integrated in the toolset.

--ignore_cache -cExecute the system calls ensuring that parameters passed

to the st200run tool are synchronized with the external

RAM (and not left in ST200 internal caches).

--loaded -l

With this option st200run assumes the program has

already been loaded into memory. By default, st200run

considers that the program is not loaded.

For example:

st200run -tsim helloThe hello program is not loaded in memory. st200run must load it.

st200run -l -tsim hellost200run --loaded -tsim helloThe hello program is already loaded in memory. st200run does not load the program.

--mtargetdir=

-m

Defines the path for the target to use.For example:

st200run -tmyboard -m/home/xx/mytarget hello

The program uses all description files (for example,

targets.cfg and board.txt) defined in the/home/xx/mytarget directory.

--no_clear_bss -B

This option prevents the .bss section from being initialized

during the startup execution. This is useful for testing

programs with large C global variables on slow execution

targets. Beware, the user must ensure that the memory

content at the address to which the bss is mapped has

been initialized to 0.

By default, the .bss is cleared by the program during thestartup phase.

--noncacheable_size=

-n

This option has been deprecated.

Specify the size of the noncacheable memory area (in

bytes). If the size is not defined, it defaults to 16 Kbytes.

For example:

st200run -c -n0x1000 -tsim hellost200run -c --noncacheable_size=0x1000 -tsimhello

--pc= -p This is used to specify the PC start value.



http://-/?-http://-/?-


19/172


7521642 17/ 170

--ramend= -r

Define the address of the end of the RAM. This base

address is configurable with this option. The default value of

the RAM end is the value defined in board.ld file for thecurrent target selected.

value can be in hexadecimal or decimal.

For example:

st200run -tsim helloThe RAM end is 0x08800000 for the simulator target.

st200run -tsim -r0x03800000 hellost200run -tsim --ramend=0x03800000 helloThe RAM end is 0x03800000.

When using a simulator target, any changes made to

RAMEND must be matched by a change to the configurationoption EXTERNAL_MEMORY_SIZE, see Table 7: Target

configuration options on page 67 .If the -reset option is used, the -ramend option isignored.

--reset -R

By default, execution is started at the __start symbol inthe binary file. When reset mode is specified, execution

starts at the hardware reset address. This allows execution

of boot code.

For example:

st200run -R -tsim hellost200run --reset -tsim hello

--target= -t

Specify the name of a predefined target. The predefined

targets are configured in a target description file.

For example:

st200run -tsim hellost200run --target=sim hello

--timeout= -o

st200run will be stopped after the agreed delay (INT

seconds)

For example:

st200run -tsim -o5 hellost200run -tsim --timeout=5 hello

The program will be stopped after 5 seconds if it doesn't

stop before.



http://-/?-http://-/?-


20/172


18/ 170 7521642

Search strategy for dynamic libraries

The search algorithm defined below is used by st200run or st200gdb, to locate thecorresponding execution engine:

if(engine_library found in . ) { engine_library = ./engine_library

}else if ($ST200ROOT_ENGINE exists && engine_library found in

$ST200ROOT_ENGINE) { engine_library = $ST200ROOT_ENGINE/engine_library}else if(engine_library found in

/lib/engine//) { engine_library =

/lib/engine///engine_library

}else engine_library not found

--verbose -v

Provide additional information on st200run, including:

– target description file used,– dynamic library used,

– st200run version,

– GDI version supported,

– target version (dll version used),

– progress loading sections,

– transfer rate (bytes per second),

– run-time version used.

For example:

st200run -v -tsim hellost200run --verbose -tsim hello

--version -V

Display the st200run version and exit.

For example:

st200run -Vst200run --version

1. The full list of direct commands can be obtained by typing gdi help at the gdb command prompt afterconnecting to the dll.



http://-/?-http://-/?-


21/172


7521642 19/ 170

1.6 Targets and target options

st200run is designed to be compatible with a variety of execution models (for example,simulator and silicon boards) as well as an effectively unlimited number of parameterizedvariants. These are referred to as targets and are defined in a file, targets.cfg, which issupplied with the standard toolset release. When invoking either st200run or st200gdb,the execution target must be specified on the command line using the option-t. The location of the target specified by is determinedin accordance with the strategy defined below:

if (-mtargetdir= option defined && targets.cfg in the path defined by this option && is in this targets.cfg ){ target = as found in /targets.cfg}else if (target.cfg found in /target &&

is in this targets.cfg){ target = as found in

/target/targets.cfg}else target not found

Note: 1 $ST200ROOT_TARGET is now deprecated. Use the -mtargetdir option instead.

2 For the Windows toolset, the path defined with the -mtargetdir option must be set usingthe format DRIVE:\Directory\ (for example C:\mytarget\ ).

1.6.1 Simulator options

By default, two simulator targets are predefined in /target/targets.cfg .They are:

● sim : the default simulator target,

● simprof: the simulator target, generating profiling data files in gprof format.

The following syntax is used in the targets file:

[dll options ...]

For example:

sim st200sim MODE FAST

This defines a target called sim which uses the st200sim.dll file to simulate the programin FAST_MODE. Core and simulator endianness are deduced from the program’s binary.

The intention is for the user to modify this file (or a copy of it) in order to define specificexecution contexts. For example, if it is necessary to assess the performance of theprocessor in the context of a system with specific bus latency and external memorycharacteristics, the following target might be added to the file:

sim_SoCx st200sim BUS_LATENCY 30 EXTERNAL_MEMORY_SIZE 0x600000

This defines a target called sim_SoCx which uses the st200sim.dll to simulate the coredefined within the program binary, specified in a system context in which the latency on thebus is 30 bus cycles and the external memory size is 6 Mbytes.

http://-/?-http://-/?-


22/172


20/ 170 7521642

The first item after the target identifier is the name of the dynamic library (.dll or .so)used to specify the execution model. st200sim indicates the simulator. The remainingitems are referred to as target options and are specific to the target concerned.

There are three ways to specify target options:

● include the options on a line defining a distinct target in the targets.cfg file,

● list the options in double quotes, along with the dynamic library name, as an argumentto the st200run dll option (see Table 1 on page 14 ),

● list the options in a textual configuration file and specify the filename using a singleCONFIG_FILE option.

The basic simulator options are listed in Table 2 , further options are given in Section 3.1 onpage 67 . The first two target options are used to control the use of the configuration fileitself.

Table 2. Simulator target configuration options

Option Description Default value

CONFIG_FILE

Read options from the specified CONFIG_FILE (seeDUMP_CONFIG_FILE).

DUMP_CONFIG_FILE

Dump all user definable options to the specified file.

MODE [FAST|ISS|REFERENCE|REF]

The operation mode, the options are FAST, ISS andREFERENCE (or REF). See Section 1.5 on page 13 .

REFERENCE

EXTERNAL_MEMORY_SIZE

Size of external memory (in bytes).(1)

Beware that, by default, the toolset generates programs

that use only 0x800000 bytes of memory size. To specify

a larger or smaller memory usage for the program, either

use the --ramend option of st200run (see Table 1 onpage 14 ) or adjust the board.ld parameter and rebuildthe program (see Section 1.11.1 on page 46 ).

0x800000 forST220

0x4000000 for

ST231

EXTERNAL_MEMORY_BASE

Byte address of the base of external memory.(1) 0x08000000

NONCACHEABLE_MEM_SIZE (2)

The size (in bytes) of noncacheable memory. Buffers

associated with a number of I/O related system calls are

copied into this area.

0x4000 (16 Kbytes)

TRACING_ON

This determines whether or not the simulator produces a

code execution trace. If set to true, the default operation

is to output a textual trace to stdout. An alternativelocation can be specified by setting the

OUTPUT_TRACE_FILE configuration item.

false

OUTPUT_TRACE_FILE

This item only takes effect when TRACING_ON is set totrue. It’s effect is to output the trace to the specified

filename. If the string is empty or the file cannot be

opened, the trace is output to stdout.

""

TRACE_START_CYCLE

Cycle on which to start tracing. 0

TRACE_END_CYCLE

Cycle on which to end tracing.



23/172


7521642 21/ 170

1.6.2 Board options

Silicon targets are predefined in /target/targets.cfg , for example, mb379. By default this is commented out in the targets.cfg file. When a silicon target is

connected, the definition must be uncommented and the IP address must be modified.

The following syntax is used in the targets file:

[dll options ...]

For example:

mb379 st200emu HTI_ID tcp:

The first item after the target identifier is the name of the dynamic library (.dll or .so)used to specify the execution model. st200emu indicates a silicon target. The remainingitems are referred to as target options and are specific to the target concerned.

There are two ways to specify target options:

● include the options on a line defining a distinct target in the targets.cfg file,

● list the options in double quotes, along with the dynamic library name, as an argumentto the st200run dll option (see --dll in Table 1 on page 14 ).

The available board specific options are listed in Table 3 .

PROFILING

When this is set to true the simulator will produce the

following (gprof-style) output files(3):

gmon.out - standard execution profile.

gmon.outDCACHE - time spent in each function waitingon dcache stalls.

gmon.outICACHE - time spent in each function waitingon icache stalls.

false

PROFILING_OUTPUT_FILE

By default, profiler information is recorded in a file in

which the last part of the filename is an incrementing

integer (for example, 0042). The width of this numeric

field is determined by the form of the filename. For

example gmon**** results in a succession of filenames:gmon0000, gmon0001, and so on.

"gmon****"

1. EXTERNAL_MEMORY_SIZE and EXTERNAL_MEMORY_BASE can be used to model additional blocksof memory if desired.

2. The st200run and st200gdb tools are insensitive to this option. This option is only meaningful forcosimulation environments.

3. The gmon format employs 16-bit numbers to represent time intervals. As this gives insufficient dynamicrange for typical simulations, time values have had to be scaled. In consequence, the column headersproduced by gprof (specifying the underlying unit of time) are incorrect. It is recommended that analysis ofexecution profiles is restricted to consideration of relative times.See the gprof documentation for information on the interpretation of the output files.

Table 2. Simulator target configuration options (continued)


http://-/?-http://-/?-


24/172


22/ 170 7521642

Table 3. Silicon target configuration options


BOARD

This option is necessary for a board connection unless

DSU_TEST is specified. indicates thename of the directory in/target/board that contains theboard.txt and board.ld files for the board.

The board.txt file (or the file referred by theBOARD_TXT_FILE option, if present) describes theconnection initialization sequence and the board.ld file describes the RAM location in the memory mapping.

BOARD_TXT_FILE

Specify an alternate name for the board configuration

file containing the connection initialization sequence.

The file is searched relatively from the directory

specified by the BOARD option.

board.txt

BOOTRAM=

This specifies the RAM area used at connection, reset,

load and at run time for running some utility routines.

The RAM content is safely restored after use.

If there are several ST200 cores sharing the same RAM

space under concurrent debug access, it is necessary

to specify a different address for each core. An

alternative method to define this area is to specify a

reserved debug memory region in the board.ld file.

CLOCK_D=

ST200 clock divider. Setting to 1 means the fullHTI(1) clock (50 MHz).

Note that the semantic of the CLOCK_D option changesin the case of a pure JTAG connection, see the

description of the PURE_JTAG option.

1

CONFIG_FILE

This option is deprecated but kept for compatibility

reasons. It should be replaced by the BOARD option.

CPU_RESET_ADDRESS=

This specifies the value of the CPU reset address. 0x0

DISABLE_MPOKE

This is a simplified connection mode. At connection

time, a physical core reset and taplink reset are

performed. The board.txt memory initialization file isthen executed. This state prevents some utility routines

from being installed and so introduces the following

discrepancies:

– the core endianness is not tested so that it remains in

assumed little-endian mode by default, and

– the downloading speed remains at the default poke

slow rate.

This connection mode is used as an intermediate step

during new board tests.



25/172


7521642 23/ 170

DSU_TEST

This sets the mode for hardware board testing. At

connection time, only a physical core reset and taplink

reset are performed. In this state, the memory access is

not setup but the ST200 DSU can be accessed through

the boards low level commands. This connection mode

is required for executing the DSU critical test suite.

This connection mode is dedicated to initial silicon bring

up tests and is not suitable to execute any toolset

generated program.

EMU_SAFE_TRACESet low level communication trace in safest but slowest

mode.

EMU_TRACE Set low level communication trace.

HTI_ID tcp:

Host Target Interface(1) (HTI) connection identification.

HTI_MODE[st200|tap|st20]

HTI(1) connection mode. st200

ID2KEY_FILE

Specify an alternate name for the file containing the

identifier-key mapping list used by the id2key boardcommand.

The file is searched relatively from the directory

specified by the BOARD option.

id2key.txt

JTAG_REMOTE_CLOCK(2)

This option specifies a pure jtag connection instead of

taplink and enables the remote clock for the connection

speed.

The JTAG signal is set to ARM like pinout.

The option NO_TAP_CTRL must not be used inconjunction with this option. For this option, CLOCK_D has no meaning.

The feature is available for the ST230EMU-PCI board

only and the option must be specified in the

corresponding alias within the target.cfg file. Forexample:

mb388 st200emu HTI_ID tcp:xxx.yyy.zzz.kkkCONFIG_FILE mb388 NO_CHIP_RESETJTAG_REMOTE_CLOCK

The CLOCK_D option is used

to specify the

connection

speed.

NO_CHIP_RESET

This sets the mode where no physical reset is executed

during the board reset sequence performed at

connection time, load time or execution time. All of theusual reset actions are done (for example, taplink reset

and memory initialization) except for the physical chip

reset.

NO_TAP_CTRL

This sets the mode where the tap controller is not used

to access taplink.

This option does not have to be used for ST220 cores

with taplink.

Table 3. Silicon target configuration options (continued)




26/172


24/ 170 7521642

OS21_OSCALL

This option configures the oscall behavior versus the

execution of OS21 tasks.

By default, when OS21_OSCALL is not specified, anyoscall made inside a task locks the ST200 CPU until the

oscall emulation has been completed on the host

machine. When OS21_OSCALL option is set, the ST200CPU is not locked (in fact, it is stalled for periods less

than 30 µs) while the oscall emulation is being

performed, and high priority OS21 tasks can execute.

This option is typically useful when data streaming (for

example, file I/O) or trace display oscalls need to be

performed by the program while the program ensures

that high priority tasks remain executed with strong

timing constraints.

Using this option can lead to st200emu errors in thefollowing cases.

– If the high priority tasks do not leave the CPU to the

task performing the oscall, after around 5 seconds the

oscall emulation issues a time-out error and the

program fails.

– With st200gdb, breakpoints must not be used when

the OS21_OSCALL mode is activated on a boardtarget. This would break the synchronization between

the debugger and the program, and lead to

unpredictable connection loss. For this reason, it is

recommended to use the OS21_OSCALL mode onlywith the st200run tool to execute the program.

– The usage of this option is not compatible with theusage of the CONF_DEBUG flags version of thelibos21.a library.

OS21 tasks are

locked whileexecuting

oscalls.



http://-/?-http://-/?-


27/172


28/172


26/ 170 7521642

Note: All the three options enable the pure jtag connection.

PURE_JTAG uses the JTAG signal st20 and CLOCK_D as an index to specify the frequencyof the connection.

JTAG_REMOTE_CLOCK uses the JTAG signal ARM pinout and enables the remote clock.

ST231_CUT6 enables the ST231 cut 6 protocol and has to be used in conjunction with oneof the previous two options.

VERBOSITY=n Set verbosity to n for debug purposes.

VIRTUAL_DEBUG

This option configures the mode (physical or virtual) ofthe address space seen by the debugger.

By default, when VIRTUAL_DEBUG is not specified, anyrequest sent by the debugger directly accesses the

physical address space.

When the VIRTUAL_DEBUG option is set, the debuggeraccesses the virtual address space, as currently set in

the TLB by the program being debugged.

In most cases (and by default), the TLB is set so that

the addresses of the virtual space matches the

addresses of the physical space. This option is

therefore unnecessary.

As soon as the TLB is set with unmatching address

translation, this option is necessary to enable thedebugger to access correctly the objects mapped in

memory through their virtual address. This is the case

when the bare run-time service

bsp_mmu_memory_map() is used with unmatchingaddress and phaddr parameters, or when the OS21run-time service mmap_create() is used instead of mmap_create_identity().

The debugger

accesses the

physical

address space.

1. The ST Micro Connect (ST40-Connect).

2. These options are explained in more detail in Table 4 .

Table 4. JTAG connection options

JTAGJTAGsignal

ST20

JTAGsignal

ARM

CLOCK_D

as index

Remote

clock

CLOCK_D

as divider

N-2

response

PURE_JTAG X X X

JTAG_REMOTE_CLOCK

X X X

ST231_CUT6 X X



http://-/?-http://-/?-


29/172


7521642 27/ 170

1.7 st200gdb debugger

The st200gdb debugger provided is an ST200 retargeting of the GNU gdb-6.4 standarddebugger which comes with a GUI. This gdb-6.4 is sometimes called Insight-6.4. Insight isthe name chosen by Red Hat for the software made from gdb plus the added GUI. Refer tothe standard GNU gdb documentation for information about the st200gdb features andcommands. Refer to the Insight home page (http://sources.redhat.com/insight) for additionalinformation about the GUI.

To launch an st200gdb session in the command line interface, type:

/bin/st200gdb

The basic gdb commands to perform in command line mode in order to execute a programare:

file target gdi -t load

run

The file command is not required if is specified on the st200gdb launch line.

The target command connects to a target, either a simulator or a board.

The load command can be omitted if the application is already loaded in memory. In thiscase, the pc value has to be initialized before running:

set $pc=__text_start

The load command can also be omitted if the application has been burnt in Flash and theuser wants to start the execution from the reset address located in Flash. In this case aspecial debugging mode is required before running:

startmode -set reset

The run command starts the execution of the program.

While the target remains connected, it is possible to restart the execution of the program inRAM, providing that the .data section has been reinitialized, for example by reloading it:

loadrun

The ST200 specific features are described in the following sections.

Note: The st200gdb debugger supports OS21 threads. If you are using the GUI (see Section 1.8on page 35 ) the threads are listed in the Processes window.

http://-/?-http://-/?-


30/172


28/ 170 7521642

1.7.1 GDI target command option

The st200gdb target command supports the connection to the same targets as thosesupported by the st200run tool. A target is selected using one of the following options:

The targets are defined in the targets.cfg file supplied with the standard toolset release.The location of the target description file is determined in accordance with the strategydefined in Search strategy for dynamic libraries on page 18 .

1.7.2 GDI st200gdb commands

The st200gdb command language has commands to deal with the GDI target, at two levels.

● At the first level, pure st200gdb commands allow access to generic GDI targets.

● At the second level, a set of target specific commands are available as soon as the GDItarget has been connected. They are also called the GDI direct access commands.

The available commands are described in Table 5 . Additional information is provided in theonline help available within st200gdb using the help st-gdi command.

Note: All values (for example, address and length ) can be an expression using the followingoperators:

(, +, -, *, /, ~, &, | or a variable.

target gdi -t where is the same target alias used byst200run and predefined in the target description file.The st200gdb execution targets available (simulator orevaluation board) are inherited from the sameconfiguration mechanism.

target gdi -t -m

where is the same target alias used byst200run and predefined in the target description fileand is the location of the targets.cfg file.The st200gdb execution targets available (simulator orevaluation board) are inherited from the sameconfiguration mechanism.

target gdi -dll where specifies the same GDI dynamictarget dll name and associated target options as used byst200run.

Table 5. Target specific GDI direct commands

Command Description

st200gdb commands

gdi Execute one Direct DI Access command.

mcumap Display or set the MCU memory mapping.

mcuname Display or select the MCU name.

reset Reset the debug instrument.

pmblock Access the performance monitoring block.



31/172


7521642 29/ 170

Simulator commands

gdi bus-trace-off Turn off bus traffic tracing.

gdi bus-trace-on Turn on bus traffic tracing.

gdi flush Flush the trace output stream.

gdi get_config config_item Give the value of a specified configuration item.

gdi help Display the simulator direct command help.

gdi profile-off Turn profiling off.

gdi profile-on Turn profiling on.

gdi reset-statistics Reset the simulator statistics counter to zero.

gdi set-bus-trace-file Set the current bus tracing file.

gdi set-trace-file Set the current tracing file.

gdi start-statistics Start the simulator statistic counters.

gdi statistics Output the current simulator statistics to screen.

gdi statistics > filename Output the current simulator statistics to file.

gdi statistics >> filename Append the current simulator statistics to file.

gdi stop-statistics Stop the simulator statistic counters.

gdi trace-off Turn tracing off.

gdi trace-on Turn tracing on.

Board commands

gdi call address

Call any routine, while keeping the current DSU

context untouched.

It uses the DSU_CALL_OR_RETURN debug ROMoperation case where DSU_ARG1 is not 0, asdescribed in the ST2xx Core and Instruction Set

Architecture Manual s.

address is the start address of the routine to call.

gdi dbreak either lower upper

gdi dbreak in_range lower upper

gdi dbreak masked lower upper gdi dbreak out_range lower upper

The DBREAK_CONTROL registers determine the

comparison operations performed on the breakpoint

addresses.

If the comparison is true then a breakpoint

exception is signaled. For the data breakpoints, the

data effective address of loads and stores are used

for comparison.

Prefetches and purges do not trigger data

breakpoints.

gdi dpeek reg [length]

Read a number of DSU registers. reg is the first

register number to read.

If length is not specified, only one DSU register is

read.

If reg and length parameters are not specified, all

DSU registers are read.

Table 5. Target specific GDI direct commands (continued)

Command Description

http://-/?-http://-/?-


32/172


30/ 170 7521642

gdi dpoke reg DATA [DATA ...]

Write 32-bit word values in consecutive DSU

registers.

reg is the first register number to write.

The number of DATA occurrences must not exceed

32.

gdi enable_mpoke addr

Enable the use of the downloaded monitor when the

DSR7 register is not set to 0 and save the DSU

area.

Disable the use of downloaded monitor when the

DSR7 register is set to 0 and restore the DSU area.

gdi fhalt Force a target stop even if stopped.

gdi file filename Execute a list of commands from filename .

gdi file_exit Exit the current file and close it.

gdi flush low_address high_address

Flush an address range from data and instruction

caches using the DSU_FLUSH debug ROMoperation as described in the ST2xx Core and

Instruction Set Architecture Manual s.

low_address and high_address specify the

inclusive address range and must be aligned to

word addresses.

gdi halt

Send the unmaskable DSU debug interrupt and

trigger the DSU context save operation of the debug

ROM as described in the ST2xx Core and

Instruction Set Architecture Manual s.

gdi help Display the board direct command help.

gdi ibreak either lower upper

gdi ibreak in_range lower upper

gdi ibreak masked lower upper

gdi ibreak out_range lower upper

The IBREAK_CONTROLE registers determine the

comparison operations performed on the breakpoint

addresses.

If the comparison is true then a breakpoint

exception is signaled. For the instruction

breakpoints, the currently executing bundle address

(PC) is used for comparison.

gdi id2key value Get the key of the board from the identifier value .

gdi id2keyhigh value Get the upper 32 bits of the 64-bit key of the board

from the identifier value found in the id2key.txt file.

gdi id2keylow value Get the lower 32 bits of the 64-bit key of the board

from the identifier value found in the id2key.txt file.

gdi if exp gdi command gdi ....[gdi elsegdi command gdi ...]gdi endif

The expression exp is evaluated. If it is not null, the

first commands group is executed. If the else command exists and the expression is null, the

second commands group is executed.


Command Description

http://-/?-http://-/?-


33/172


7521642 31/ 170

gdi jtag -get Read the value on the jtag line.

gdi jtag -off Set the jtag mode to OFF.

gdi jtag -on Set the jtag mode to ON.

gdi jtag -set value Write value to the jtag line.

gdi load filename [addr] Load the ELF, DISM or BIN file filename , at the

address addr . If addr is not defined, the file is

loaded at 0x0.

gdi peek address [length]

Read 32-bit word values in the memory using

DSU_PEEK debug ROM operations as described inthe ST2xx Core and Instruction Set Architecture

Manual s.

The address is the start address and must be

aligned to word addresses. length is the numberof words.

The integer value reflects the current endianness of

the target for integer value management in memory.

gdi poke address value [value] ...

Write 32-bit word values in the memory using

DSU_POKE debug ROM operations as described inthe ST2xx Core and Instruction Set Architecture

Manual s.

The address parameter is the start address and

must be aligned to word addresses.

The first word value is written to the start address

and the following value s are written to the following

word aligned addresses.

gdi print_verified Display the current value of the error counter.

gdi reset_taplink-nochipreset|-chipreset

Send the taplink reset sequence to the ST200 DSU

through the jtag link. The taplink reset sequence

may contain the tap controller initialization

sequence on behalf of the NO_TAP_CONTROL st200emu option flag. During the taplink reset

sequence, a chip reset is sent (-chipreset) or not(-nochipreset) to the chip through the NOT_RSTST Micro Connect signal.

Note that the NO_CHIP_RESET st200emu optionflag is ignored.

gdi reset_verified Reset the counter of verified errors to zero.

gdi restart

Restart the execution from the current DSU context.

It uses the DSU_CALL_RETURN debug ROMoperation case where DSI_ARG1 is 0, as describedin the ST2xx Core and Instruction Set Architecture

Manual s.

gdi rpeek [register]

Read one or all CPU registers. Where register is

the register name to read. If the register

parameter is not specified, all CPU registers are

read (register = (R0-R63,B0-B7,PC,PSW)).


Command Description

http://-/?-http://-/?-


34/172


32/ 170 7521642

The pmblock st200gdb command

The ST200 cores are equipped with a performance monitoring block. This block is capableof recording core relevant events such as data cache hits, instruction cache hits and severalothers (see the Core and Instruction Set Architecture manuals for reference and thecomplete list). The pmblock command gives the user access to this block.

Usage

pmblock -start -stop

-reset -setevent -setcounter -setclock -showcounter -showclock -show -resetidle

gdi rpokeregister value

Write a CPU register. Where register is the

register name to write (register =

(R0-R63,B0-B7,PC,PSW)).

gdi set_timeout value Set the timeout value (in seconds) for

communication between the host and the

STMicro Connect.

gdi sleep value Sleep during the value milliseconds.

gdi verbose value

Execute STMicro Connect software in verbosity

mode.

value specifies the level (0 to 5).

gdi verify value

Verify the value versus the value reported by the

last executed command able to return a value and, if

they differ, display an error message on the output

and increment the verify error counter.

gdi version Get version numbers of components allowing

access to silicon.

gdi while exp gdi command gdi ...gdi endwhile

The expression exp is evaluated. If it is not null, all

commands are executed. The expression exp is

re-evaluated and while this expression is not null, all

commands are re-executed.

gdi write "comment" [format data] Write a comment only or write a comment with a

variable value.

var = value | result_of_command Create a variable var and initialize it with value or

the result of a command returning a value.

# any_text Echo the text as a comment.


Command Description

http://-/?-http://-/?-


35/172


7521642 33/ 170

Basic parameters

1.7.3 New startup configuration commands

The following new st200gdb commands dedicated to the run-time configuration have beenadded, see Table 6 .

These commands are equivalent respectively to the --ramend, --env and--no_clear_bss st200run options.

startramend

Display or set the startup location of the RAMEND.

Note: When using a simulator target, any changes made to the RAMEND must be matched by achange to the configuration option EXTERNAL_MEMORY_SIZE , see Table 7: Targetconfiguration options on page 67 . If the -reset option is used the -ramend option isignored.

Usage

startramend -show -set

-start Starts the event counting. During the following execution, events arecounted.

-stop Stops the event counting. During the following execution, events arenot counted.

-reset Resets to zero all the event counters and the clock counter.

-setevent Set the counter to count events.

-setcounter Sets the counter to .

-setclock Sets the clock counter to (available on ST231 onwardonly).

-showcounter Displays the value, that is, the number ofcounted events.

-showclock Displays the counted clock ticks.

-show Displays the complete status of the performance monitoring block.

Table 6. Startup configuration commands

Command Description

startramend Display or set the startup location of the RAMEND.

startenvDisplay or set the setting of the passing of host

environment variables.

startbss Display or set the setting of the BSS clear variable.

http://-/?-http://-/?-


36/172


34/ 170 7521642

Basic parameters

startenv

Display or set whether host environment variables are passed.

Usage

startenv -show-set yes|no

Basic parameters

startbss

Display or set the BSS clear variable.

Usage

startbss -show-set yes|no

Basic parameters

1.7.4 Emulated system calls

System calls such as printf and fprintf are supported for any st200gdb GDI targets ina similar way to st200run. See Section 1.5 on page 13 .

-show Displays the current value of the ramend address taken by a programat startup. This is the default.

-set Changes the RAMEND address to a new value.

-show Displays the current setting for whether the host environmentvariables are passed to the program (yes or no).

-set Changes the setting for whether the host environment variables arepassed to the program (yes or no).

-show Displays whether the .bss will be cleared (yes or no).

-set Changes the setting of BSS clear variable (yes or no).

http://-/?-http://-/?-


37/172


7521642 35/ 170

1.8 Using the graphical user interface

The st200gdb debugger automatically starts in command line mode. If you want to use theGUI, launch st200insight (or enter an additional -w option when you launch st200gdb).

To debug a file called hello.out in graphical mode, type:

/bin/st200gdb -w hello.out

or

/bin/st200insight hello.out

1.8.1 Running a simple debugging session

When st200gdb is started the main window is displayed, showing the source file containingthe main function of the program. The first step is to choose the execution target:

1. Select Target Settings... from the File menu. The Selecting an ST2x0 Target windowis displayed, see Figure 3 .

The ST2x0 Target list contains the set of execution targets found by the GUI in thevisible targets.cfg files. The targets.cfg files are searched for successively in:

– the directory defined by the -mtargetdir option,

– the directory /target.

The target file defined by the -mtargetdir option could also be selected from theGUI using the Browse button.

Note: The search strategy for the target configuration file is shown in Search strategy for dynamiclibraries on page 18 .

Figure 3. Selecting an ST2x0 Target window

When a target is found more than once, the first definition is used. This allows you touse overridden definitions for some targets. The origin of the used definition is shownbetween parentheses in the list. See Section 1.6: Targets and target options onpage 19 for details.

http://-/?-http://-/?-http://-/?-http://-/?-http://-/?-http://-/?-


38/172


39/172


7521642 37/ 170

Figure 4. Selecting an ST2x0 Target window, More options

1.8.3 Using the ST2x0 Statistics window

The GUI provides an ST2x0 Statistics window which displays the results of the gdistatistics command. It is only useful when this command is available, for example withthe simulator target. The window is updated each time the state of the processor changes.

An example of the ST2x0 Statistics window is shown in Figure 5 .To display the ST2x0 Statistics window, do one of the following:

● select ST2x0 Statistics from the View menu,

● press Ctrl+I on the keyboard,

● click on the icon.

http://-/?-http://-/?-


40/172


38/ 170 7521642

Figure 5. The ST2x0 Statistics window

The Start button calls the gdi start-statistics command. It starts the statisticscounters for the ST200 processor. By default, the counting is enabled.

The Stop button calls the gdi stop-statistics command. It stops the statisticscounters for the ST200 processor.

The Reset button calls the gdi reset-statistics command. It may typically be usedbefore executing a sequence of code in order to compute the statistics.

1.8.4 Using the Performance Monitoring window

The Performance Monitoring window gives access to all the features provided by theST200 cores performance monitoring block. The counter values are updated whenever theirvalues change, and it is possible to start and stop the event counting, to set the type of eventcounted by the counters and their values. An example of the Performance Monitoring

window is shown in Figure 6 .To display the Performance Monitoring window, do one of the following:

● select Performance Monitoring from the View menu,

● press Ctrl+X on the keyboard,

● click on the icon.

http://-/?-http://-/?-


41/172


7521642 39/ 170

Figure 6. The Performance Monitoring window

Any changes made in the editable fields become effective whenever the Apply button ispushed. The buttons in the Switches area of the window are active immediately. The Start button toggles to Stop when the counting of the events is enabled and vice versa.

1.8.5 Displaying multiple Memory windows

Multiple Memory windows can be simultaneously displayed by either:

● clicking on the icon, or

● selecting Memory from the View menu.

http://-/?-http://-/?-


42/172


40/ 170 7521642

Figure 7. Multiple memory windows

1.8.6 Watch and local variables window

The look and feel of the Watch and Local Variables windows were enhanced in Insight 6.1.

The following information is displayed for each item:

=

http://-/?-http://-/?-


43/172


7521642 41/ 170

Figure 8. Watch window

1.8.7 Troubleshooting

Unexpected failure during a simulation

During a simulation session, in cases where the operating tool (st200gdb or st200run)crashed, failed unexpectedly, or was killed by the user, a gdiserv process may remainexecuting on the host machine. It is recommended that any remaining process is killedbefore attempting to run a new tool session with the simulator.

st200gdb initialization file

Some user session parameters are kept by st200gdb across debugging sessions in aninitialization file called ~/.gdbtk200init on Solaris and Linux and ~/gdbtk200.ini onWindows.

Occasionally, when the version of st200gdb is changed, there are problems with this file.This can be avoided by deleting or renaming this file before changing the version.

st200gdb README file

Some of the known st200gdb limitations are documented in a file called README.GDBTK that is found on the st200gdb source tree. It is recommended that this file is read for furtherinformation about st200gdb.

http://-/?-http://-/?-


44/172


42/ 170 7521642

1.9 Configuring the program execution startup

1.9.1 Initialization sequence

After the program is loaded and before the program execution is started, a few core registersand software parameters are expected to be initialized. They are passed as parameters ofthe __start() entry point function. This configuration is done according to st200run options or st200gdb commands and is described below.

Note: In reset mode, these parameters take the value set up by the boot code, regardless of thetool options.

After the program is started and before the main() function is called, the program executesthe internal real time run-time initialization.

Start parameters

int argc

char **argvThese are the arguments passed to the st200 program from the st200run commandline (st200run [OPTIONS]) or st200gdb commands (set args). The boot codesetup for these parameters is argc=0, argv=0.

char **env

This is the full system environment variable from the host machine, copied into theST200 program (st200run -env option, or st200gdb startenv command). Theboot code setup for this parameter is env=0.

char *ramend

This is an absolute address passed to the program, indicating the “end of the RAM”(that is, the first non-RAM address) where some internal data and the stack pointer areto be initialized. The default value is defined in the board.ld linker script dedicated tothe program’s target and can be changed by modifying the DEFAULT_RAMEND_VALUE in this file (recommended). It can be overridden by the user (st200run --ramend option or st200gdb startramend command).

From this address, the stack grows toward the program text and data normally loadedin LMI RAM. The boot code setup for this parameter is ramend=0x08800000 .

char *noncacheable_start

This option is a boolean indicating to the run-time the way that the system callsparameters have to be exchanged with the tool able to emulate the system calls.

If noncacheable_start equals 0, the tool emulating the oscall accesses theparameters wherever they are provided by the run-time, this could be in ST200 internal

registers or data caches. The st200run and st200gdb tools are designed to work inthis mode by default. This is also the mode setup by default by the boot code.

If noncacheable_start does not equal 0, care is taken by the run-time to have allthe system call parameters accessible in external RAM by the tool able to emulatesystem calls. Although this mode is not relevant for the st200run tool, the st200run option --ignore_cache enables this mode to be setup for test purposes.

http://-/?-http://-/?-


45/172


7521642 43/ 170

Other core register initialization

The only core register expected to be initialized, in addition to the previously described startparameters and the program counter, is the stack pointer. The stack pointer is an ABIreserved core register, and is initialized by the st200run and st200gdb tools as described in

Section 1.4: Target address space usage on page 11. In reset mode, the stack pointer isinitialized by the boot code.

Internal C run-time initialization

At the execution of the __start() function, the following initialization is performed prior tothe BSP initialization:

● the bss section is initialized to zero,

● the kernel stack is set up.

The C run-time initialization sequence is located in the crti.o module linked with theprogram.

The C run-time initialization invokes the BSP initialization (calling the three hooks__init_core(), __init_board() and __init_soc()) before calling main().

Board Support Package initialization

The following default initialization is performed in __init_core() prior to calling main():

● the ST200 exception handler is setup,

● the hardware is initialized for clock function setting,

● the memory protection units and dismissible loads behavior are set to a default value.

The setting for the memory protection unit is by default adjusted to your program needs.This enables the use of the data cache for all memory access between __text_start and_ramend, and prevents any dismissible load in the peripheral control register area.

The default initialization sequence is located in the libcore.a, libboard.a andlibsoc.a modules linked with the program, and source code for the initialization sequenceis visible in the following directories:

/target/core//src/target/board//src/target/soc//src

1.9.2 Initialization hook

If, for some reason (for example, peripheral initialization or target environment setup), it isnecessary to change the behavior of the init sequence before main(), the recommended

method is to use the hook mechanism put in place in the startup phase of the run-time.Two types of hooks are available for the user in the run-time to enable user initialization ofhardware or software before executing the main program.

The bsp_user_start_handle() and bsp_user_end_handle() are invoked from thelibcore.a library in the BSP initialization respectively at the start and the end of the BSPinitialization (see Appendix A: ST200 board support package (BSP) on page 114 ).

The __init_soc() and __init_board() functions are located in the libsoc.a andlibboard.a libraries respectively.

http://-/?-http://-/?-


46/172


44/ 170 7521642

1.10 Configuring the run-time and boot code for a target

The configuration of a target is done at three levels.

To configure the execution of the user program to be specific for the board target, therun-time must be aware of the sysconf parameters. These parameters are hardwareparameters (such as the core and bus clock frequency) which, together with the handling oftheir access, are found in the sysconf.c module.

By default, the sysconf module linked with the application fits the needs of all simulatortargets. This means that for hardware boards, a dedicated sysconf module specific toeach board must override the default sysconf.

It is exactly the same for the boot code. By default, a boot program is linked with theapplication, however, it can be overridden with a boot program dedicated to a given targetboard, see Section 1.11.

Caution: A correct run-time configuration is required to get valid results on the time functions such asclock(), and for benchmarking purposes.

1.10.1 The sysconf and boot code modules

A set of sysconf and boot code modules are delivered in the toolset. They are located in the

/target/board directory. Within the board directory there is onesubdirectory for each board.

Core level This level must contain all the settings which are related to a core

and independent of either the SoC in which the core is embedded, orthe board on which the SoC is used.

SoC level This level is related to all the settings necessary for a given SoCindependent of any board.

Board level This level covers all the settings needed to configure a given boardindependent of the core or the SoC.

src/boot.S The source of the boot section corresponding to a dedicated target.By default, the boot code provided initializes the minimal boardsettings for enabling access to RAM, if necessary. It then sets thestartup parameters to their default values for boot and jumps to thestart of the C program, which is assumed to be loaded in memory.

src/sysconf.c The module managing sysconf parameters for the correspond

st200_cross_dev_manual.pdf

Documents