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 ﬁrst 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 2
is 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 3
or MinGW 4
is used in windows. CDT supports plug-in for
IDEs such as eclipse or NetBeans (Nicolas Burri, 2009).
DATA DISPLAY DEBUGGER (DDD):
DDD 5
is 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 6
with 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.

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

Recommended

Recommended

More Related Content

Similar to Gui based debuggers

Similar to Gui based debuggers (20)

More from Mysa Vijay

More from Mysa Vijay (7)

Recently uploaded

Recently uploaded (20)

Gui based debuggers