This is NOT an official Atmel product. You will not get help for this through the official Atmel Support channels. But, there are a lot of helpful people on www.avrfreaks.net that might lend a hand. This is a branch of http://gdbproxy.sourceforge.net adding targets for AVR simulator models distributed with Atmel Studio (http://www.atmel.com/Micr…
Switch branches/tags
Nothing to show
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Failed to load latest commit information.
avrmodelapi
.cvsignore
AUTHORS
COPYING
ChangeLog
Makefile.am
NEWS
README
THANKS
TODO
atcommon.cpp
atcommon.h
bootstrap
configure.in
copying.c
gdbproxy.1
gdbproxy.c
gdbproxy.h
gdbproxy.texi
getopt.c
getopt.h
getopt1.c
init.c
remote.c
rpmisc.c
rpmisc.h
serial.c
serial.h
target_atavr8.cpp
target_atsam.cpp
target_atuc3.cpp
target_skeleton.c

README

gdbproxy - a remote proxy program for the GNU debugger, GDB
=========================================================== 

gdbproxy is an open source remote proxy program for the GNU debugger, GDB.
Its licence is similar to the BSD licence, so it can be used to build
closed source interfaces between GDB and proprietary target debug
environments.

gdbproxy is based on the Open Source program rproxy, which can be found at:

http://world.std.com/~qqi/labslave/rproxy.html

What is gdbproxy actually for?
==============================

Here was our problem:

One of the nice features of the Texas Instruments MSP430 microcontrollers
are their on-chip emulation facilities. These are usually accessed through
a TI JTAG Flash Emulation Tool (FET) attached to a PC's parallel port. To
make the GNU debugger (GDB) work with this, an interface between GDB and
the FET was needed.

TI made their MSP430 debug interface code available to the developers of
the MSP430 port of the GNU toolchain. However, for commercial reasons, TI
would not allow the full version of their interface library to be released
as open source code. It would reveal things about the working of the MSP430,
which they consider commercially confidential. The licencing of the GNU tools
does not permit linking against a closed source library. This is where
gdbproxy fits in.....

GDB supports remote debugging through serial or TCP/IP connections.
gdbserver is a remote debug proxy program for these remote debug
environments, supplied as part of the GDB package. This is licenced
under the GPL, and cannot be mingled with closed source code. gdbproxy
provides similar functionality, but is licenced under a BSD style
licence. It does, therefore, permit linking with closed source
code. gdbproxy has, therefore, been adapted to provide a TCP/IP to
MSP430 FET interface for GDB. I think it is also better structured for
isolating the functionality associated with a specific target in one simple
module. It is, therefore, easier to adapt to new target environments.

The source for the generic version of gdbproxy continues to be open source,
released under the same licence as the original gdbproxy program. Only the
MSP430 specific code remains closed source. The skeleton target interface,
supplied as open source, is the same code on which the MSP430 support is
built. It should be easy to adapt this to provide support for many targets.

What can gdbproxy do for me?
============================

If you are trying to provide GDB support for a target which requires the
use of proprietary code, gdbproxy may be just right for you. I also think
gdbproxy is a better basis for building completely open GDB debug interfaces,
too. In gdbproxy, all target specific code is kept in one tidy module. A
skeleton for that module is provided, so it should be quite a quick task to
get support for a new environment up and running.  Look through the code for
"TODO" markers that highlight what needs changing for new target support.

If you are using the mspgcc port of the GNU tools for the Texas Instruments
MSP430 you definitely want the MSP430 version of gdbproxy.

How can I try it out?
=====================

gdbproxy builds OK on Linux and with MinGW32 or Cygwin on Windows. It uses
the GNU autoconf and automake tools, so to build it use:

./configure
make
make install

By default, this will build the program to support a GDB serial protocol
interface to a generic target, and a skeleton module that you can adapt to
a target specific debug environment.

To try it use:

./gdbproxy --help

or

./gdbproxy --help skeleton

to get help specific to the "skeleton" target.

To run gdbproxy for the "skeleton" target, listening on TCP/IP port 1234 for
connections from GDB, use:

./gdbproxy --port=1234 skeleton


Good Luck
Steve Underwood <steveu@coppice.org>



Atmel additions
===============

Pthread-support:

For supporting multiple cores in one device/model, threading was added to
the gdbproxy. The thread support was implemented by using pthread. This is
supported in Linux, but not in Windows. The Windows support was added by
downloading pthreads-win32 (https://sourceware.org/pthreads-win32/).
ftp://sourceware.org/pub/pthreads-win32/pthreads-w32-2-9-1-release.tar.gz

Pthread building:

Building the pthread library is quite easy. Just untar the package and run
"make CROSS=i686-pc-mingw32- clean GC-static". This will create the files
needed. pthread.h and sched.h were copied to
/tools/simulator/mingw32-gcc-simulator/i686-pc-mingw32/include
and libpthreadGC2.a was copied to:
/tools/simulator/mingw32-gcc-simulator/i686-pc-mingw32/lib

Pthread usage:

In addition to including pthread.h we also had to add defining 
PTW32_STATIC_LIB to the CPPFLAGS. Then it was just running the
 cross-compile as normal:
./bootstrap
./configure --build=x86_64-unknown-linux-gnu --host=i686-pc-mingw32
make