3 CCSv5 & Linux Debug - Texas Instruments

AgendaMorning Session (2 hours)Morning Session (2 hours)

Welcome Device Overview Tools – Boards & SDK What is Linux Linux Distributions Linux Distributions Booting Linux (with Lab)

Afternoon Session (2 hours)Afternoon Session (2 hours)

Introduction to CCSv5.1 Debugging Linux with CCS Quick Introduction to GNU Make Lab: Debug Linux App with CCSv5

Find these workshop materials at:http://processors.wiki.ti.com/index.php/LinuxWorkshopTechDays2011

Outline IDE’s - CCS, Eclipse, and Debugging IDE s CCS, Eclipse, and Debugging Linux Kernel & User Programs

D b i i Li Debugging in Linux CCSv5 GDB Demo (User Mode Debug) Summary / Wrap-Up (Optional) Using GNU Make( p ) g

What is an IDE? Integrated Development EnvironmentHow about … Integrated Debugger & Editor?

Compiler LibrariesExecutableExecutable

FileFile

Editor

p

Asm

EVM

Debugexe

LinkEditor AsmTargetBoard

DebugLink

What is an IDE? Integrated Development EnvironmentHow about … Integrated Debugger & Editor?

Compiler LibrariesExecutableExecutable

FileFile

Editor

p

Asm

EVM

Debugexe

Link

Edit / Build

Editor AsmTargetBoard

DebugLink

DebugEdit / Build Build side tools: Editor

C d G ti T l

Debug Connect to target to find/fix

errors & validate codeA d b l t Code Generation Tools

(toolchain) Manage project’s build with:

Standard gMake scripts

A debugger lets you: Pause a program (breakpoint) Examine and change variables Step through code Standard gMake scripts

Managed-Make (Eclipse) Step through code

The IDE we'll be using is...

Code Composer Studio (CCSv5)

Perspectives provide separatecontext-sensitive window arrangements

Call stack for devices being debug’d

Latest version of TI’s graphical IDE tools (CCSv5) Built on Eclipse platform (2nd gen to use Eclipse) Full install or install on top of standard Eclipse

F li f GDB d b i

Tabbed editor

Free license for GDB debugging Eclipse Open Source Framework

Cross-platform support (Windows & Linux)M d k fil (G M k i ti )windows Managed make files (Gnu Make scripting)

Plug-ins & web updates Project Management

U d M d M k St d d M k fil Used Managed Make or Standard Make files Select most tools/settings on a per project basis

DebuggerGDB d b i ti GDB debugging options (Ethernet / serial)

Scan-based debugging (JTAG) Target cfg simplifies TI JTAG emu setup (.ccxml)



Embedded SystemsGUIGUISongVolumeBass

mySong.mp3User interface

I t Master O t t

Treble

Input (Driver)

MasterThread

user code

Output(Driver)

GP OS (eg: Linux) Process

import source data export results

Manage multiple threads Assist in creation of user

interface Manage memory

(algorithm)

Convert input data g y Provide system services

Co e t put datato desired results

Linux-based SolutionUser Space

// “Master Thread”// Create Phase

GUISong mySong mp3

User Space Simple ‘Master Thread’ program demonstrates: Common embedded

system program flow:get IOalloc process RAM

// Process (Execute) Phasewhile(run)

SongVolumeBassTreble

mySong.mp3 y p gC P D

While loop contains std data flow: I P OInput/output drivers arewhile(run)

Input (exch bufs)ProcessOutput (exch bufs)

// Delete Phase

Process(algorithm)

Input/output drivers are specific to OS

Processing – algo’s API is usually OS agnostic

// Delete Phasefree process RAMsurrender IO

Linux provides two programming spaces User space – where user

programs run

Kernel Space

Input Output

p g Kernel space – owns

system resources; prog’s must request access via drivers

Driver Driver


D b i i Li Debugging in Linux Debugger Connections

Types of Debugging – That is, What to Debug?

User Mode (Application) Debugging

Kernel Mode Debugging

Simultaneous Debug

CCSv5 GDB Demo (User Mode Debug) Summary / Wrap-Up Summary / Wrap Up (Optional) Using GNU Make



Types of Debugging – That is, What to Debug?



Simultaneous Debug


Host/Target ConnectionsHost PC runs:Host PC runs: Its own OS (Linux, Windows, etc.) Terminal application (Tera Term, putty, etc.) Debugger software (CCSv5)Debugger software (CCSv5)

Host PC DebuggerCCSv5 (Eclipse)

CCSv5 (Eclipse)

TerminalCCSv5 (Eclipse)

RS-232

Target (EVM)

RS-232ControlsTarget

DebuggerEmbedded O/S (ie. Linux)Term controls target O/S

Boot settings (U-boot) Standard Linux cmds Start/kill user programs

Debugger Connect via Ethernet,

Serial/RS232, or JTAG Issues debugging cmds Start/Stop what’s being Start/kill user programs

Standard IO (printf, etc.) Start/Stop what s being

debugged Accesses program or

system data



T f D b i Th t i Wh t t D b ? Types of Debugging – That is, What to Debug?



Simultaneous Debug


What Do You Want to Debug? User Program

User Programs (processes) User Program

SchedulerLinux Kernel

V4L2 ALSA I2C

SchedulerMem Mgmt

V4L2 ALSA … I2C

Kernel Code

U M d D b i

Types of DebuggingUser Mode Debugging

As it sounds – debugging a program running in User Space When debugging user programs, you often only want to debug –gg g p g , y y g

hence stop – one program thread GDB (Gnu Debugger) works well for this. (Discussed on next slide) Physical connection is usually via Ethernet or serial-portPhysical connection is usually via Ethernet or serial port

Low-Level (Kernel Mode) Debug Debugging kernel code requires complete system access Used for debugging drivers or other kernel objects You need KGDB (Ethernet/Serial) or scan-based (JTAG)

debuggers for this type of debugging All threads (basically everything) are halted!

Let's look more closely at User Mode Debugging...






Simultaneous Debug


Open source debugger that is often supplied with the toolchainI thi k h it’ i l d d i th C d S k

GNU Debugger (GDB) : Cmd Line Debug In this workshop, it’s included in the Code Sourcery package GDB has a client/server nature::

GDB (ie. client) – Terminal app that sends debug commands to server GDB Server Runs app for you based on the GDB commands you send it

Host PC

GDB Server – Runs app for you, based on the GDB commands you send it

Tera TermEVM> gdbserver 192.168.1.122:10000 myAppListening on port 10000Remote debugging from host 192.168.1.1

GDB Server

UserProgram Starts gdbserver

Target (running Linux O/S)




Host PC


Tera Term (gdb) target remote 192.168.1.122:10000Debugger Terminal (shell, telnet, etc.)

EVM> gdbserver 192.168.1.122:10000 myAppListening on port 10000Remote debugging from host 192.168.1.1

(g ) g(gdb) step(gdb) b 43 (gdb) run

GDB Server Sends debug


Sends debug cmds to gdbserverto control User Prog





Host PC


Tera Term (gdb) target remote 192.168.1.122:10000Debugger Terminal (shell, telnet, etc.)

EVM> gdbserver 192.168.1.122:10000 myAppListening on port 10000Remote debugging from host 192.168.1.1

(g ) g(gdb) step(gdb) b 43 (gdb) run

GDB Server

Hello World

Sends debug


Receives Std I/O

Sends debug cmds to gdbserverto control User Prog


Graphical Debug with GDB CCSv5 (Eclipse) can translate actions (mouse clicks, etc.) into GDB cmds

Other than starting gdbserver, it means we don’t have to know GDB syntax The PC Host system runs:

Terminal (Tera Term, putty, etc.) D b IDE (h it Gdb)

Debugger: Controls User application

Debugger IDE (hence, it Gdb)

Host PCCCSv5 (Eclipse)

by sending appropriate gdb commands based on user clicks, menus, etc

Host PCCCSv5 (Eclipse)Terminal

GDB

Target (EVM)RS-232

Ethernet

GDB

ControlsTarget

Terminal: Starts Embedded O/S Starts gdbserver to

Embedded O/S (ie. Linux)

gdb server Starts gdbserver to

controls app’s execution Receives Std I/O

App






Simultaneous Debug


Linux Low-Level Debug Kernel and device driver debug require

access to the Kernel Mode Gdb and Gdbserver are not well suited for this

Addition of an external JTAG emulator grants complete access to the embedded processor Allows source-level kernel code debugging Access: peripherals, registers and memory, etc.

The standard Eclipse CDT IDE does not have support for low-level debugging

St d d E li i h il d d t b th Standard Eclipse is heavily dependent on both the emulation technology & type of processor

TI added their emulation technology to CCS in order to provide enhanced JTAG support

Non-TI debuggers can use GDB / KGDB to access kernel. KGDB is a kernel patch that allows GDB-type access to control execution

Linux Low-Level Debug - Setup

Host debug system (PC) Target system (Board)

RS-232T TTera Term, Putty, minicom

JTAG EmulatorUSB or Ethernet

As seen previously:p y Terminal (RS-232) boots the system and starts/stops Linux user programs CCSv5 controls low-level debugging via JTAG emulator






Simultaneous Debug


User Mode & Kernel Mode Simultaneously debug using both modes at the same time Simultaneously debug using both modes at the same time

That is, debug the kernel in conjunction with an application This allows drivers to be debugged in the context of their usage

How it works? Remember, gdbserver is just another user-space application;

therefore it can be halted just like any other programtherefore, it can be halted just like any other program

Can make heterogeneous debug easier Useful when debugging ARM with DSPs or other co-processors Useful when debugging ARM with DSPs or other co processors Example: Debugging DSP code communicating to ARM via DSP/Link

Note: Using standard interfaces, such as the Codec Engine framework can help to minimize dual processor debugging (nice!)framework can help to minimize dual-processor debugging (nice!)

Debug plug-ins available for other OSes (Android, Mylyn, etc.) can allow a one-stop-shop debugging environmentgg g



Setting Up CCSv5 for GDB (1)

1. Create/open a project and build so that you have an executable to debugp p j y g

Note: Please refer to Embedded System Design Workshop with Linux (Lab 5e) for step-by-step directions regarding this demo.

The course materials can be found at:http://processors.wiki.ti.com/index.php/OMAP%E2%84%A2/DaVinci%E2%84%A2_System_Integration_using_Linux_Workshop Link


1. Create/open a project and build so that you have an executable to debugp p j y g2. By default, CCSv5 doesn’t have remote/GDB debugging turned on


1. Create/open a project and build so that you have an executable to debugp p j y g2. By default, CCSv5 doesn’t have remote/GDB debugging turned on3. Once enabled, create a new “Debug Connection” for GDB


1. Create/open a project and build so that you have an executable to debugp p j y g2. By default, CCSv5 doesn’t have remote/GDB debugging turned on3. Once enabled, create a new “Debug Connection” for GDB4. Eclipse assumes “native” debugging, so you need to re-configure for remote


1. Create/open a project and build so that you have an executable to debugp p j y g2. By default, CCSv5 doesn’t have remote/GDB debugging turned on3. Once enabled, create a new “Debug Connection” for GDB4. Eclipse assumes “native” debugging, so you need to re-configure for remote5. Point your connection to GDB for the target (remote) processor


1. Create/open a project and build so that you have an executable to debugp p j y g2. By default, CCSv5 doesn’t have remote/GDB debugging turned on3. Once enabled, create a new “Debug Connection” for GDB4. Eclipse assumes “native” debugging, so you need to re-configure for remote5. Point your connection to GDB for the target (remote) processor6. Specify the method of connecting to the target … then click ‘Debug’



Summary

The application debugging is entirely done with open source components:

Gdb client on the host side Gdb client on the host side Gdbserver on the target side CCSv5 or standard Eclipse CDT

Th JTAG d b d CCS 5 d t l f The JTAG debugger and CCSv5 are mandatory only for device driver and kernel development

More Information at: More Information at: Debugging in Linux Tutorial – Step by step procedure:

http://processors.wiki.ti.com/index.php/Linux_Debug_in_CCSv5 Link

Easier to develop code with TI’s Linux-based SDKs.http://processors.wiki.ti.com/index.php/Linux_Host_Support

Embedded System Design with Linux Workshop (GDB lab in Chapter 5)htt // iki ti /i d h /OMAP™/D Vi i™ S t I t ti i Li W k h

Link

Link

http://processors.wiki.ti.com/index.php/OMAP™/DaVinci™_System_Integration_using_Linux_Workshop

Why Use CCS to Debug Linux?

CCSv5 addresses both scenarios of Linux debug: Application debugging: Application debugging:

It is based on the latest release of the standard Eclipse CDT IDE and keeps its standard functionality, including the support for the GNU toolchain

Much more compatible with third party plug ins Much more compatible with third-party plug-ins Low-level debugging:

It is compatible with several JTAG emulators XDS100v2 if low cost is desired XDS560v2 USB/Ethernet if remote debugging is desired

CCSv5 – Downloads & More Info Code Composer Studio version 5 (CCSv5)

Windows & Linux versions available Eclipse 3.6 / CDT7 / “Helios” Main CCS page: www.ti.com/ccs CCSv5 page (Download, Topics):

http://processors.wiki.ti.com/index.php/Category:Code_Composer_Studio_v5 CCS Pricing* (on 8/1/2011):

Single-seat (node locked) – download only: $445 Single-seat (node locked) – DVD shipped: $495 Single-seat (floating): $795 Use with XDS100, EVM’s, Linux/GDB: Free

CCSv5/Eclipse plug-ins available: Terminal view

http://processors.wiki.ti.com/index.php/How_to_install_the_terminal_plugin_in_CCSv5 Eclipse Linux Tools Project: http://www.eclipse.org/linuxtools/p j p p g Target Management Plug-in: http://www.eclipse.org/tm

* Please check with TI Web eStore, Distributor, or TI sales person for up-to-date pricing

Lab 2 – Debugging Linux App with GDB1. Build “hello world” with Standard gMake fileg2. Create CCS/Eclipse project for Linux application3. Setup GDB/GDBserver connection for CCSv54. Single-step debug your application



Big Picture – Why use gMake?

Creating/Using a Makefile g g

Using Variables and Printing Debug Info

Basic Makefile Code Review Basic Makefile Code Review




Creating/Using a Makefile Creating/Using a Makefile



Build OverviewS Build

InstructionsSource Files

“Dependencies”app.x64P

Executables “Targets”

Build Toolapp.c

app cfg

app.xv5Tapp.x470MVapp.x86U

Build Toolapp.cfgapp.h app.o

app.lib

Build Tool Goals:B ild t bl (t t) f i t fil (d d i ) i b ild

“D” “CMD” “T”

1. Build executable (target) from input files (dependencies) using buildinstructions (commands)

2. Build for multiple targets at once (e.g. ARM, X86, DSP)

Solution: command line (e.g. cl6x, gcc) or scripting tool (gMake, etc.)

Looking at gcc commands...

Command Line (Examples 1-2)

“C d ”“D d i ” “T t ”“Commands”

Command Line

“Dependencies”

app.capp.o

app.oapp.x86U

“Targets”

app.o app.x86U

“D” “CMD” “T”

Example 1: create an object file (app.o) from an input file (app.c) gcc –g –c app.c –o app.o

Example 2: create an executable (app.x86U) from an object file (app.o) gcc –g app.o –o app.x86U

command flag dependency flag target-c = compile only-g = build with debug enabled-o = output filename

Might be more convenient to place commands in a script/batch file…makefile…p




Creating/Using a Makefileg g



Basic Makefile with Rules

“D d i ” “T t ”Makefile

gMake

“Dependencies”

app.capp.o

app.oapp.x86U

“Targets”

app.o app.x86U

“D” “CMD” “T”

One of the more common “scripting” tools is GNU Make, aka gMake, aka Make… gMake uses “rules” to specify build commands, dependencies and targets

G i ll RULE l k lik thi Generically, a RULE looks like this:

Remember Example 2? Let’s make this into a simple Makefile rule:

TARGET : DEPENDENCY[TAB] COMMANDS…

Remember Example 2? Let s make this into a simple Makefile rule:gcc –g app.o –o app.x86U

command flag dependency flag target

app.x86U : app.ogcc –g app.o –o app.x86U

Becomes….RULE

Creating Your First Makefile


gMake

“Dependencies”

app.capp.o

app.oapp.x86U

“Targets”

app.o app.x86U

“D” “CMD” “T”

gcc –c –g app.c –o app.ogcc –g app.o –o app.x86U

Command Lines

# Makefile for app.x86U (goal)

app.x86U : app.ogcc –g app.o –o app.x86UMakefile

Creating Your First Makefile


gMake

“Dependencies”

app.capp.o

app.oapp.x86U

“Targets”

app.o app.x86U

“D” “CMD” “T”

gcc –c –g app.c –o app.ogcc –g app.o –o app.x86U

Command Lines

# Makefile for app.x86U (goal)

app.x86U : app.ogcc –g app.o –o app.x86UMakefile

app.o : app.cgcc –g –c app.c –o app.o

Running gMake


gMake

“Dependencies”

app.capp.o

app.oapp.x86U

“Targets”

app.o app.x86U

“D” “CMD” “T”

To run gMake, you can use the following commands: make (assumes the makefile name is “makefile”, runs FIRST rule only) make app.x86U (specifies name of “rule” – e.g. app.x86U) make –f my_makefile (can use custom name for makefile via forcing flag… -f)

gMake looks at timestamps for each target and dependency. If the target is newer than its dependencies, the rule (and associated commands) will not be executed.

To “rebuild all”, use the “clean” rule to remove intermediate/executable files…

Looking at convenience rules...

“Convenience” Rules“D” “CMD” “T”

Convenience rules (e.g. all, clean, install) can be added to your makefile to make building/debug easier.

For example a “clean” rule can delete/remove existing intermediate and For example, a clean rule can delete/remove existing intermediate and executable files prior to running gMake again.

If the rule’s target is NOT a file, use the .PHONY directive to tell gMake not to search for that target filename (it’s a phony target).

“Build All Targets”.PHONY : all

86 ( )

g ( p y g ) Let’s look at three common convenience rules (to use, type “make clean”):

Build All Targets all: app.x86U …(all “goals” listed here)

.PHONY : cleanclean :

f“Remove Unwanted Files”

rm –rf app.orm –rf app.x86U

.PHONY : installinstall : app x86U

“Copy Executable to thei t ll di t ” install : app.x86U

cp app.x86U /dir1/install_dirinstall directory”

Note: “all” rule is usually the first rule because if you type “make”, only the first rule is executed

gMake Rules Summary“D” “CMD” “T”

3 common uses of rules include:• [.x] – final executable

[ o] intermediate/supporting rules

app x86U : app o

• [.o] – intermediate/supporting rules• [.PHONY] – convenience rules such as clean, all, install

Examples: app.x86U : app.ogcc –g app.o –o app.x86U

app.o : app.c

p.x

o pp : ppgcc –g –c app.c –o app.o

.PHONY : clean

.o

clean :rm –rf app.x86U

.PHONY

Run: • make (assumes makefile name is “makefile” or “Makefile” and runs the first rule only) make (assumes makefile name is makefile or Makefile and runs the first rule only)

• make app.x86U (runs the rule for app.x86U and all supporting rules)

• make clean







Using Built-in Variables“D” “CMD” “T”

Simplify your makefile by using these built-in gMake variables:• $@ = Target• $^ = All Dependencies• $< = 1st Dependency Only

Scope of variables used is the current rule only Scope of variables used is the current rule only. Example:

Original makefile…app.x86U: app.o

gcc –g app.o –o app.x86U

g

app.x86U: app.ogcc –g $^ –o $@

Becomes…

User-Defined Variables & Include Files“D” “CMD” “T”

User-defined variables simplify your makefile and make it more readable. Include files can contain, for example, path statements for build tools. We use Include files can contain, for example, path statements for build tools. We use

this method to place absolute paths into one file. If “-include path.mak” is used, the “-” tells gMake to keep going if errors exist.

i l d th k CC DIR / sr/bin/

Examples:

makefile path.makinclude path.mak

CC := $(CC_DIR)gcc

CFLAGS := -g

CC_DIR := /usr/bin/...# other paths go here…

LINK_FLAGS := -o

app.x86U : app.o

$(CC) $(CFLAGS) $^ $(LINK_FLAGS) $@

Printing Debug/Warning Info“D” “CMD” “T”

Two common commands for printing info to stdout window:• echo – command line only, flexible printing options (“@” suppresses echo of “echo”)

Examples:

• $(warning) – can be placed anywhere in makefile – provides filename, line number,and message

app.x86U : app.o$(CC) $(CFLAGS) $^ $(LINK_FLAGS) $@@echo@echo $@ built successfully; echo@echo $@ built successfully; echo

$(warning Source Files: $(C_SRCS))app.x86U : app.o $(warning now evaluating dep’s)

$(CC) $(CFLAGS) $^ $(LINK_FLAGS) $@$(warning $@ built successfully)

$(warning) does not interrupt gMake execution $( g) p g A similar function: “$(error)” stops gMake and prints the error message.

Quiz Fill in the blanks below assuming (start with .o rule first):

• Final “goal” is to build: main.x86U• Source files are: main.c, main.h• Variables are: CC (for gcc), CFLAGS (for compiler flags)

CC := gccCFLAGS := -g# l# .x rule_________ : _______

_____ ________ ___ -o ___

# .o rule:_________ : _______ _______

_____ ________ -c ___ -o ___

Quiz Fill in the blanks below assuming (start with .o rule first):

• Final “goal” is to build: main.x86U• Source files are: main.c, main.h• Variables are: CC (for gcc), CFLAGS (for compiler flags)

CC := gccCFLAGS := -g# l# .x rule_________ : _______

_____ ________ ___ -o ___main.x86U main.o

$(CC) $(CFLAGS) $^ $@

# .o rule:main o main c main h_________ : _______ _______

_____ ________ -c ___ -o ___main.o main.c main.h

$(CC) $(CFLAGS) $< $@

Could $< be used in the .x rule? What about $^ in the .o rule?







Basic gMake Makefile – Review (1)# -----------------------# ------ includes -------

Include file that contains tool paths (e g the path to gcc)

# -----------------------include ./path.mak

# --------------------------------# ------ user-defined vars -------

paths (e.g. the path to gcc)

User-defined variables# --------------------------------CC := $(X86_GCC_DIR)gccCFLAGS := -gLINKER_FLAGS := -lstdc++

## -----------------------# ------ make all -------# -----------------------.PHONY : allall : app.x86U

“all” rule

# -----------------------------------# ------ executable rule (.x) -------# -----------------------------------app.x86U : app.o

$(CC) $(CFLAGS) $(LINKER FLAGS) $^ o $@

Main “goal” of makefile…rule for app.x86U

$(CC) $(CFLAGS) $(LINKER_FLAGS) $^ -o $@@echo; echo $@ successfully created; echo

# ---------------------------------------------------# ------ intermediate object files rule (.o) -------#

Intermediate .o rule. Notice the use of pattern matching # ---------------------------------------------------

%.o : %.c$(CC) $(CFLAGS) -c $^ -o $@

the use of pattern matching.

Basic gMake Makefile – Review (2)# ----------------------# ----- clean all ------

“clean” rule. Removes all files created by this makefile. Note # clean all

# ----------------------.PHONY : cleanclean :

rm -rf app.x86Urm -rf app.o

created by this makefile. Note the use of .PHONY.

pp

# -------------------------------------# ----- basic debug for makefile ------# ----- example only ------# -------------------------------------

“printvars” rule used for debug. In this case, it echos

.PHONY : printvarsprintvars:

@echo CC = $(CC)@echo X86_GCC_DIR = $(X86_GCC_DIR)@echo CFLAGS = $(CFLAGS)

debug. In this case, it echos the value of variables such as

“CC”, “CFLAGS”, etc.

@echo LINKER_FLAGS = $(LINKER_FLAGS)

Date post:	16-Oct-2021
Category:	Documents
Upload:	others
View:	9 times
Download:	0 times

3 CCSv5 & Linux Debug - Texas Instruments

Documents