Gui based debuggers

GUI based Debuggers for

Wireless Sensor Networks

using Data Display Debugger

and Existing YETI 2

STUDENT PROJECT

AT

GEORG-AUGUST UNIVERSITY GÖTTINGEN, GERMANY

FACULTY OF MATHAMATICS AND COMPUTER SCIENCE

TELEMATICS GROUP

WORKED IN

WIRELESS SENSOR LAB

DR. OMAR ALFANDI

PROF. DR. DIETER HOGREFE

ARNE BOCHEM, MSC

Vijay Soppadandi | 21363273 | February, 2017

ABSTRACT

Wireless sensor networks (WSNs) are difficult to build and debug. It

is difficult to check whether the sensor is processing correctly or not

just by looking at the light-emitting diodes (LEDs). In this project,

are described tools which allow developers to debug their code. For

that, Data Display Debugger(DDD) and YETI1 2, a plug-in for an

Eclipse are presented. Both debuggers support GUI based

debugging, breakpoints, variable analysis, and the launching of

debug sessions. The direct debugging from the target platform is not

possible instead these debuggers need to integrate with the Joint

Test Action Group (JTAG) or AVR Dragon hardware adapter that

provides debugging support.

1 YETI is an Eclipse based TinyOS IDE

ACKNOWLEDGEMENT

I would like to thank all the people who supported me and made my

student project work possible.

First and foremost, I wish to express my sincere gratitude to

Professor Dr. Dieter hogrefe from the Institute of Informatics of

Georg-August-University, for being first advisor for the student

project and provide me an opportunity to work on the student project

under his supervision. I would also like to thank Dr. Omar alfandi

for supporting me as supervisor.

I would like to thank Arne bochem a Ph.D. student from Institute of

Informatics of Georg-August-University, for his outstanding

supervision- ideas, energy, discussions, and constructive feedback

right from the start of the project till the end.

I also thank my friends and colleagues for their timely support and

encouragement. Finally, I would like to thank my family members

for their never-ending support in all my endeavors.

Contents

ABSTRACT 1

ACKNOWLEDGEMENT 2

CONTENTS 3

1. INTRODUCTION 5

2. LITERATURE REVIEW 8

3. SYSTEM DESIGN 11

4. ANALYSIS AND DISCUSSION: 13

5. IMPLEMENTATION 15

6. SAMPLE DEBUG SCENARIO 18

7. CONCLUSION AND FUTURE WORK 21

BIBLIOGRAPHY 36

1. INTRODUCTION

Wireless sensor networks (WSNs) are widely used for

accomplishing various tasks and performing several functions. They

can be employed to measure real world environment and

atmospheric values such as temperature, humidity, visibility of light,

sound, pressure, speed etc. As the name suggests wireless sensor

networks is an interconnection of sensors indefinite topological

manner or ad-hoc to sense various environmental or physical

variables from the real world. The main benefits of using wireless

sensor networks include low cost of implementation and optimal

energy usage. The main tasks that sensors of WSNs perform are

sensing the real-world environment, calculating the environment

values and transferring those values to the storage (Wang, Nov.

2008).

IRIS sensors are responsible for sensing and storing the values in the

storage through functionality implemented in these sensors in

TinyOS and NesC programming language. The technological

advancements in the field of WSNs have decreased the size, power

consumption and cost of wireless sensors considerably. The

computational capabilities of sensors have also improved due to

research and studies. The capability of modern wireless sensors to

perform sensing and computation with fewer power requirements

increases the lifetime and sustainability of WSNs in various

applications. There are many ideas that are available for

implementation WSNs.

Debugging the sensor nodes

JTAG

JTAG USB

A debugger is important in the development of a software system or

building a code. It tells the developer about the errors and shows the

possibilities how to correct them. Not only debugging the code but

provides insight into the internal working of the program. The direct

debugging from the target platform are not possible instead these

debuggers need to integrate with the Joint Test Action Group

hardware adapter that provides debugging support. As shown in the

above figure 1-1 shows the AVR Dragon is an on-chip debugger

(OCD) connected sensor node using AVR Dragon interface. On

another hand, the computer is connected to AVR Dragon using USB

port. The AVR Dragon adapter provides a communication between

the sensor node and computer.

SCOPE OF PROJECT:

The scope of this project is to provide an effective debugger for

wireless sensor networks.

GOALS OF THIS PROJECT:

The goal of this project is to make easy debugging of TinyOS

applications. Before debugging the NesC code, it is important to

know some of the knowledge about how the internal operations of

the NesC compiler work. To remove this burden of the developers

is the main goal. Graphical user interfaces such as Integrated

Sensor

AVR Dragon

Computer

Figure 1-1 Sensor debugger setup

development environments (IDEs) similarly DDD and Eclipse are

used in this project. Both debuggers support for GUI based

debugging, breakpoints, variable analysis, and launching of

debugging sessions.

Some of the other important challenges that are identified are:

Implementation of an interface with a sensor node to the

debugging tools (avr-gdb)

Implementing of an interface between GDB to DDD

debugger

Implementation of YETI 2 plug-in for eclipse which

performs debugging, breakpoints, variable analysis, and

launching of debug sessions.

Configuration of the debugger to integrate GDB to AVR

JTAG adapter.

STRUCTURE OF THIS PROJECT:

This project report is categorized into 7 chapters.

Chapter 1 provides the introduction, scope, and objectives of

this project.

Chapter 2 is the literature review which provides

hypothetical background required for this project.

Chapter 3 describes in detail regarding the system design.

Chapter 4 explains how the system is analyzed and

discussed.

Chapter 5 provides in detailed explanation how the system

is implemented.

Chapter 6 provides sample debug scenario or demonstration

Chapter 7 provides the conclusion, appendices, and required

future work.

2. LITERATURE REVIEW

AVR DRAGON:

The AVR Dragon is a hardware adapter that provides debugging

support. This tool is built completely for On-chip debugger on all

AVR (explained below) supports debugging with the help of JTAG

interface. Not only debugging but also do real-time emulation of

the target system by using the standard interface such as JTAG. With

this, an end user gets the complete control of the internal resources

of the AVR microcontroller (Atmel, 2001).

As shown in the above figure 2-1 shows the AVR Dragon is an On-

chip debugger interfacing with the real device. This On-chip

debugger logic is used to manage the executions in the device.

AVR:

AVaRICE (AVR) is a tool that acts as a broker for AVR Dragon and

AVR-GDB, it usually communicates with the AVR Dragon and

after gathering the information instantly transfers to the AVR-GDB.

AVaRICE AVR run´s on POSIX machines and connects to AVR-

GDB via TCP socket. The AVR-GDB and JTAG ICE

communicates via GDBs “serial debug protocol”. In theory, it is

possible to debug a program by connecting to a computer that is far

away from JTAG ICE which is attached to another computer with

an AVaRICE on it (O`Flynn).

GUI front

end Target

AVR

AVR

Dragon

interface

Figure 2-2-1 AVR Dragon interface with the target device

AVR-GDB:

AVR-GDB is a debugger tool which gives access to end user to look

at the source code, view variables, alter information and many other

things. The main advantage of AVR-GDB is that it can be run under

Linux platform. The other advantage is that GDB was particularly

designed for computers. A lot of developers use GDB to debugging

their system code that would run on their personal computers. There

are many GUIs that can support interfacing GDB/MI (machine

interface) such as DDD and IDEs such as eclipse. GDB get into three

important parts: write the required command to communicate to

GDB, reads the commands and responds instantly with notifications

about the events generated. To debug a program, it must connect to

the JTAG with a help of AVaRICE. AVaRICE is used because it

can easily understand the commands sent from the GDB. Then these

commands are translated into related AVR protocol that the JTAG

ICE can be easily understandable (Nicolas Burri, 2009).

C DEVELOPMENT TOOLKIT (CDT):

CDT 2is used to launch C/C++ applications. It is widely supported

by the GNU debugger (GDB). The GNU C development tools such

as gcc or gdb are available in Linux or Mac and CDT such as

Cygwin 3or MinGW 4is used in windows. CDT supports plug-in for

IDEs such as eclipse or NetBeans (Nicolas Burri, 2009).

DATA DISPLAY DEBUGGER (DDD):

DDD 5is a debugger supports GUI based debugging for command-

line debuggers such as GDB, the bash debugger based and much

2 https://www.eclipse.org/cdt 3 https://www.cygwin.com 4 https://www.mingw.org 5 https://www.gnu.org/software/ddd/

more. It supports displaying the target source code, DDD is famous

for displaying its interactive graphical data (Saha). DDD debuggers

supports also breakpoints, variable analysis, and launching of debug

sessions. The direct debugging from the target platform are not

possible instead the DDD debuggers need to integrate with the Joint

Test Action Group (JTAG) hardware adapter that provides

debugging support.

YETI 2 DEBUGGER:

Yeti 2 is a plug-in for an IDEs such as eclipse or NetBeans. It is a

NesC editor and the last component in the TinyOS chain can be seen

in the figure 3-2. Some of other important functions of using yeti 2

are: Provides a real-time code validation, highlighting the syntax,

context sensitive in the completion of the code, many search tools

and other things (Yeti 2- TinyOS 2 Plugin for Eclipse, 2013). The

advantage of using the Yeti 2 in IDEs is that it supports an automatic

debugging via a friendly graphical user interface.

ECLIPSE:

Eclipse 6with its IDE that provides a place to edit the code, a

debugger and an assembler and frontend end for all AVR-GDB and

the JTEG ICE. It can run on different platforms of an operating

system such as windows, Linux, Solaris, Mac OSX and many others

because eclipse which uses the software development kit (SDK),

developed in Java. Java supports many platforms as possible.

6 https://www.eclipse.org

3. SYSTEM DESIGN

DATA DISPLAY DEBUGGER:

Figure 3-1 Setup for Data Display Debugger

The above figure shows how DDD is setup using a chain of

interfaces integrates to form a GUI debugger. Of these, the

important interface that plays an important role is AVR Dragon. As

we talked about it already, it is a hardware adapter that provides

debugging support. This tool is built completely for On-chip

Debugging on all AVR with the support of AVR Dragon interface.

The aim is to debug the code that is installed inside a sensor mote

using GUI debugger. For this we used an AVR Dragon and AVR, a

tool that acts as a broker for AVR Dragon and AVR-GDB, it usually

communicates with the AVR Dragon and after gathering the

information instantly transfers to the AVR-GDB. AVR-GDB is a

debugger tool which gives access to the end user to look at the

source code, view variables, alter information and many other things

in the DDD frontend tool.

DDD is a debugger supports GUI based debugging for command-

line debuggers such as GDB, the bash debugger based and much


for displaying its interactive graphical data.

YETI 2 DEBUGGER

Technical architecture

Figure 3-2 shows an in-detail overview of the system which

describes how these different parts are integrated to form the Yeti 2

debug plugin.

The technical architecture also shows the source mote that includes

an AVR microcontroller running TinyOS. The Yeti 2 works with

CDT plugins to interact with the GNU debugger GDB called AVR-

GDB. AVaRICE, a tool that acts as a broker for JTAG ICE and

AVR-GDB, it usually communicates with the JTAG ICE and after

gathering the information instantly transfers to the AVR-GDB.

Figure 3-2 Technical architecture of YETI 2 debugger

These components from the figures 3-1 & 3-2 are a chain of

dependencies, starting from a target device such as a sensor node

to the GUI debugger controller.

4. ANALYSIS AND DISCUSSION:

It was difficult to debug the code using GDB in terminal window.

The developer cannot easily find the issue or bug in the code. More

of all, when using GDB in terminal, developer must know the basic

commands that are used for debugging. These kinds of debugging

used in terminal window are not user friendly. So, in this report

provides solutions for this issues by using GUI debuggers.

In WSNs direct debugging from the target platform are not possible

instead these debuggers need to integrate with the AVR Dragon

hardware adapter that provides debugging support. There are many

GUIs that can support interfacing GDB/MI (machine interface) such

as DDD and IDEs such as eclipse. GDB get into three important

parts: write the required command to communicate to GDB, reads

the commands and responds instantly with notifications about the

events generated. To debug a program, it must connect to the JTAG

with a help of AVaRICE.

DDD is famous for displaying its interactive graphical data (Saha).

DDD debuggers supports also breakpoints, variable analysis and

launching of debug sessions. Before, DDD was only used to debug

the code but not for WSNs. In this project, DDD GUI debugger is

used to connect to WSNs that has an inbuilt GDB. Later, it is

observed that the DDD can only open the executable files for

debugging but not supports nesC related files and more of all its

slow and takes time for exchanging messages between the DDD

GDB and the sensor mote.

Next introduced with YETI 2 is a plug-in for an IDEs such as eclipse

or NetBeans. It is a NesC editor and last component in the TinyOS

chain can be seen in the figure 3-2. Some of other important

functions of using yeti 2 are: Provides a real-time code validation,

highlighting the syntax, context sensitive in completion of the code,

many search tools and other things (Yeti 2- TinyOS 2 Plugin for

Eclipse, 2013).

As in YETI 2 uses GDB proxy is defined by the lunch configuration

that permits a direct interface between GNU debugger and the JTAG

adapter. These proxies are first configured before processing them

then the proxy process is displayed to the end users one after the

other in debug session (Yeti 2- TinyOS 2 Plugin for Eclipse, 2013).

Here, the communication between YETI 2 and sensor node is fast

and efficient.

5. IMPLEMENTATION

In this chapter gives a detail explanation how the DDD and YETI 2

plugin are implemented. Here, basically the sensor node is debugged

as it our target device. As a prerequisite install the required program

in the sensor node.

A) DATA DISPLAY DEBUGGER

DDD is a debugger supports GUI based debugging for command-

line debuggers such as GDB, the bash debugger bashdb and many


for displaying its interactive graphical data (Saha).

Make sure that the DDD is installed in a system before launching it.

The DDD GUI debugger has an inbuilt GDB. When AVaRICE is

lunched then it waits for TCP target remote connection from the

GDB. Here, we need to understand is that, the DDD has an inbuilt

GDB instead of connecting to an AVaRICE directly from AVR-

GDB within a terminal it needs to be connected from DDD GDB to

AVaRICE.

The important interface that plays an important role is AVR Dragon.

As we talked about it already, it is a hardware adapter that provides

debugging support. This tool is built completely for OCD on all

AVR with the support of JTAG interface. This adapter connects to

the sensor node and provides OCD capabilities to it. AVaRICE is an

important interface that interacts with both AVR Dragon adapter

and to the DDD GDB.

B) YETI 2 DEBUG PLUGIN

Basically, the YETI 2 debug plugins use C development toolkit to

interface with GDB and make the GUI for debugging the TinyOS

applications. CDT is used to launch C / C++ applications. It is

widely supported by the GNU debugger (GDB).

Figure 5-1 List of all the processors required for lunch

GDB proxy is defined by the launch configuration that permits an

interface between GNU debugger and the JTAG adapter. Here in the

above figure shows the three varieties of proxies that are used to

launch the debugger. These proxies are first configured before

processing them then the proxy process is displayed to the end users

one after the other in debug session (Yeti 2- TinyOS 2 Plugin for

Eclipse, 2013). There are several other configuration setups even

after the GDB proxy setup. These configurations are briefly

explained in chapter 6.

Figure 5-2 Break points setup in an NesC code before debugging

Here in the above figure shows the breakpoint is setup by double

clicking on the left ruler in eclipse TinyOS code editor. C

development toolkit first receives the request of breakpoints before

it communicates from Eclipse to GDB. All together with GDB

binary can know the exact address of the instruction using this the

breakpoint on the hardware is set. Annotations are notes of

describing the action of a breakpoint in an eclipse IDE. So, the

annotation provides external editors such as model registers in AVR

Dragon adapter, whenever a breakpoint is created (Yeti 2- TinyOS

2 Plugin for Eclipse, 2013).

6. SAMPLE DEBUG SCENARIO

Case Study: Consider an application called “BlinkToRadio”. Here,

in this application two nodes communicates via radio packets and

that can be observed a continuous blinking of target sensor LEDs.

PREREQUISITES:

Check whether Yeti 2 plugin is installed in Eclipse IDE, install code

into the sensor, and make sure the debugger configuration is

correctly setup before starting debugging process (Consider manual

guide in chapter 7 in this report).

Now, a breaking point is set on a packet sending event that can be

seen in the below figure.

Figure 6-1 Break point to in packet sending event

Then, go to (x)= Variables tab in eclipse debug environment. Look

for the Radio counter to manipulate. Consider below figure, how the

variable radio counter is looked before manipulation.

Figure 6-2 Before manipulation of counter variable

Figure 6-3 After manipulation Setup

As seen from the above figure counter variable is manipulated by

setting a value 12000 against a default value 1.

It is observed that the LEDS on the mote freezes that is shown in

below figure, to continue working after the counter manipulation

just remove the break point and click continue debugging button

inside an eclipse debug environment.

Figure 6-4 LEDs stops blinking

Then, install an application called “Base Station” on to another mote

and run the Listen tool command from the terminal window.

java net.tinyos.tools.Listen -comm serial@/dev/ttyUSB:iris

Here, the Listen tool is a packet sniffer. Below figure shows the

binary code of the packet after it listens.

Figure 6-5 Raw data format listen from the sensor mote

Then, to check the value, type python in terminal window. If value

doesn’t match reset the mote, then try again. Check again a value if

it matches with the manipulated value.

Figure 6-6 Results to prove that value matches with the manipulated

value

Hence, it is confirmed that both values are matched and can perform

variable manipulation using GUI debugging.

7. CONCLUSION AND FUTURE WORK

In this report, it was explained how to use debuggers for WSNs and

not only debugging but also explained the internal working of the

NesC compiler that shows how the debugger works. Starting from

creating a project until the debugging of the NesC code is clearly

explained in appendices. As this is done because to make the

debugging easy for the WSNs.

Here, within this report, it was explained in brief how these two

types of GUI debuggers such as DDD and YETI 2 plugin for Eclipse

are used for debugging. It can be observed that debugging for WSNs

are not easy unless the introduction of GUI debuggers.

For future work, one can use other kinds of sensor instead of IRIS

which has already been used, tested and implemented in real-time in

this project.

APPENDICIES (OR) MANUAL GUIDE

DATA DISPLAY DEBUGGER SETUP

PREREQUISITES:

DDD must be installed in a system before using it. Follow steps.

1. Preparing an Iris mote: Use below command lines to

install the code in to sensor nodes.

make iris debug

make iris reinstall.0 mib520, /dev/ttyUSB0

2. Change the fuse to enable JTAG debugging: To enable

the debugging in to sensor node below command is used.

avrdude -cmb510 -P/dev/ttyUSB0 -U hfuse: w:0*19:m -pm1281

3. Connect avarice to iris mote: Below command is used to

send a connection request to GNU debugger to start

debugging using “- g”. Then waits for target to connect.

avarice -g -j usb localhost:4242

4. Call GDB by interfacing with avarice: AVaRICE (AVR)

is a tool that acts as an interface between AVR Dragon and

AVR-GDB.

avr-gdb build/iris/main.exe

5. Now, start DDD by connecting with AVR and GDB by

calling: Below command is used for direct connectivity

from inbuilt GDB DDD to AVR Dragon.

ddd -- eval - command= “target remote localhost:4242”

build/iris/main.exe

After, run the above command DDD is popped up is shown in below

figure 7-1.

Output:

Figure 7-1 Complete output of the Data Display Debugger

YETI 2 DEBUGGER SETUP

PREREQUISITES:

Installing of YETI 2 PLUG-IN in Eclipse environment is

explained below:

Go to menu Help Software Updates.

Now, click “Add Site”

Figure 7-2 Software update window for yeti 2 (Nellen, 2009)

Enter the location with http://tos-ide.ethz.ch/update/site.xml and

click ok.

Figure 7-3 Add site dialog box for installing yeti 2

Now, Select the required plugins to Install.

http://tos-ide.ethz.ch/update/site.xml

There is a Core Editor Plugin the important plugin for the code

editor, preprocessor for NesC, Environment setup and TinyOS for

windows or Linux environment.

Figure 7-4 Plugin selection for Yeti 2 (Nellen, 2009)

Then restart the system after installation

Figure 7-5 Restart dialog box for yeti 2

Then,

Go to menu File New Project Select in a Wizards window

TinyOS Project.

Then it’s open the New TinyOS Project window shown below

Figure 7-6TinyOS new project window

Here, in the above figure 7-6, one must provide the project name

inside the textbox such as “MotoToMoto”. The environment is set

as “TinyOS Unix Wrapper 2” or others this depends on the platform

the TinyOS project is running. Next is target sensor is an important

choice to be made depends on the sensor developer will be working

on it. Here, within this project iris sensor is used for developing an

application.

Then click finish to create a new project. The project folder can be

seen on the left corner of the Eclipse window.

Inside the newly created project folder such as “MotoToMoto”,

there is one default subfolder called “src”. Just highlight the folder

and right click.

Now, when you hover to the “New” automatically sub menus under

it are shown, next select the module for creating a module class.

Then opens “Create Module” window that can show in below

diagram.

Figure 7-7 Create Module class

Here, in the create module window, as shown in the above figure, a

developer provides the name of the new module such as here

“MotoToMotoC”.

After creating the file “MyworldC.nc” This has a function called

(implementation) of the component MotoToMoto.

As it is important to keep in mind that an iris mote is used as a target

device to embedded the developed code so, it has different kinds of

interfaces from another type of sensors.

Using the above required interfaces a module class is seen below.

#include"MoteToMoteh.h"

module MoteToMoteC

{

uses interface Boot;

uses interface Leds;

uses interface Packet;

uses interface AMPacket;

uses interface AMSend;

uses interface SplitControl as AMControl;

uses interface Receive;

}

implementation

{

uint16_t counter;

message_t _packet;

bool busy = FALSE;

event void Boot.booted(){

call AMControl.start();

}

event void AMControl.stopDone(error_t error)

{

}

event void AMControl.startDone(error_t error)

{

if(busy == FALSE)

{

//creating the packet

MoteToMoteMsg_t* msg = call Packet.getPayload(& _packet,

sizeof(MoteToMoteMsg_t));

msg -> NodeId = TOS_NODE_ID;

msg -> Data = (uint8_t)error;

//sending the packet

if (call AMSend.send(AM_BROADCAST_ADDR, & _packet,

sizeof(MoteToMoteMsg_t))==SUCCESS);

if(error == SUCCESS)

{

call Leds.led0On();

}

else

{

call AMControl.start();

}

}

}

event void AMSend.sendDone(message_t *msg, error_t error)

{

if(msg == & _packet)

{

busy = FALSE;

}

}

event message_t * Receive.receive(message_t *msg, void *payload, uint8_t len){

if(len == sizeof(MoteToMoteMsg_t))

{

MoteToMoteMsg_t * incomingPacket = (MoteToMoteMsg_t*) payload;

uint8_t data = incomingPacket -> Data;

if(data == 1)

{

call Leds.led2On();

}

if(data == 0)

{

call Leds.led2Off();

}

}

return msg;

}

}

Figure 7-8 Module class define

The above code performs a wireless radio communication.

Now, when you hover to the “New” automatically a sub menus

under it are shown, next select the module for creating configuration

class.

Then opens “Create Configuration” window that can show in

below diagram.

Figure 7-9 Configuration window

configuration MoteToMoteAppC{

// Not Intrested Now!!

}

implementation{

//General

components MoteToMoteC as App; //Main module file

components MainC; //Boot

components LedsC; //Leds

App.Boot -> MainC;

App.Leds -> LedsC;

//Radio Communication

components ActiveMessageC;

components new AMSenderC(AM_RADIO);

components new AMReceiverC(AM_RADIO);

App.Packet -> AMSenderC;

App.AMPacket-> AMSenderC;

App.AMSend -> AMSenderC;

App.AMControl -> ActiveMessageC;

App.Receive -> AMReceiverC;

}

Figure 7-10 Configuration class setup and wiring

The above figure shows the configuration class and wiring with the

module class.

Now, create a header file for a packet as shown below

#ifndef MOTE_TO_MOTEH_H

#define MOTE_TO_MOTEH_H

typedef nx_struct MoteToMoteMsg

{

nx_uint16_t NodeId;

nx_uint8_t Data;

}MoteToMoteMsg_t;

enum

{

AM_RADIO = 6

};

#endif /* MOTE_TO_MOTEH_H */

Figure 7-11 Creating packet header

Next, Create a Makefile class

Figure 7-12 Creating a make file

COMPONENT=MoteToMoteAppC

include $(MAKERULES)

Figure 7-13 Created a Makefile class for main component

Preparing an Iris mote: Use below command lines to install the

code in to sensor nodes.

make iris debug

make iris reinstall.0 mib520, /dev/ttyUSB0

Change the fuse to enable JTAG debugging: To enable the

debugging in to sensor node below command is used.

avrdude -cmb510 -P/dev/ttyUSB0 -U hfuse: w:0*19:m -pm1281

Connect avarice to iris mote: Below command is used to send a

connection request to GNU debugger to start debugging using “- g”.

Then waits for target to connect.

avarice -g -j usb localhost:4242

Required configuration to be done before connecting an eclipse

to an avarice by using this following steps:

Before debugging:

Check whether the plugins are properly installed such as CDT and

all the connections are plugin correctly.

Then, open the required file set breakpoints for debugging.

1. Main:

The binary TinyOS is used to map files address and get the

serial numbers to set a breakpoint.

Figure 7-14 Debug configuration window

2. GDB Proxy:

Here it shows the GDB proxy tab. The GDB proxy is

interfaced with the target platform.

Inside GDB proxy configuration it shows the JTAG

connection settings:

The JTAG communicates to the target device by

defining its path (e.g., /dev/ttyUSB0)

Set the JTAG version as default mkl

The rate in which the JTAG communicates with the

target device is defined by providing the bitrate.

Here, a developer can provide the speed for GDB that

can interrupt the code one line after another in

between the break points.

Default TCP port for remote localhost is set to communicate

between avarice and target device (e.g., 4242)

A startup delay for GDB is set for (e.g., 1500 milliseconds)

this is helpful for GDP proxy to initialize before it connects

to the GDP.

Figure 7-15 GDB Proxy configuration

3. Debugger

Here it defines the debugger. The stop on startup is default

main.

Figure 7-16 Debugger Configuration

In GDB debugger uses a command that helps in initiating the

debugger (avr-gdb). In GDB command file uses a command (.

gdbinit) will executed when a file starts at first. The GDB command

set is used to interact with the GDB proxy. The protocol is set using

GDB protocol for communicating with the GDB proxy. If verbose

console mode is checked so it will show all the commands on the

console that sends to GDB proxy. The connections options that are

used to connect to the GDB host is defined by the Host name or IP

address.

Figure 7-17 The above figure shows the Debugger window in

TinyOS Eclipse window

Figure 7-18 AVR Dragon continuous blinking shows ongoing

communicating between target device and GUI debugger

BIBLIOGRAPHY

Atmel. (2001). Retrieved from AVR JTAG ICE user guide:

www.atmel.com/images/doc2475.pdf

Eason, K. (1991). Ergonomic perspectives on advances in human-

computer interaction.

Gurkin, S. (2015). Detection of debugger aware malware.

Nellen, S. (2009, December 16). Distribution computation group.

Retrieved from Installations: http://tos-

ide.ethz.ch/wiki/pmwiki.php?n=Site.Installation

Nicolas Burri, R. F. (2009). Demo Abstract: YETI - An Eclipse

Plug-in for TinyOS 2.1. Berkeley, CA, USA.: ACM 978-1-

60558-748-6.

O`Flynn, C. (n.d.). Using AVR-GDB and AVaRICE Together.

Retrieved from winavr.sourceforge.net/AVR-

GDB_and_AVaRICE_Guide.pdf

S. K. Card, A. N. (1983). The psychology of human-computer

interaction.

Saha, S. (n.d.). Retrieved from Data Display Debugger:

https://www.gnu.org/software/ddd/

Siddiqui, F. (n.d.). What is system design? why is it important in

the system development process. Retrieved from

https://www.linkedin.com/pulse/ what-system-design-why-

important-development-process-fareed

T. L. Nyerges, M. K. (2012). Cognitive aspects of human-

computer interaction for geographic information systems.

Wang, W. L. ( Nov. 2008). An asynchronous MAC protocol for

wireless sensor.

Yeti 2- TinyOS 2 Plugin for Eclipse. (2013, may 14). Retrieved

from Distributed Computation Group:

http://tinyos.stanford.edu/tinyos-wiki/index.php/Yeti

Gui based debuggers

Technology

Transcript of Gui based debuggers