J0 Vm wrote:
> Im using code:blocks editor with the ARM gcc toolchain. I saw in
> code:blocks an option to debug(GDB) the code over TCP/IP.

I don't used Code::Blocks but usually when TCP/IP is used in context 
with GDB this means that the debugging software "talks" to a GDB-server 
using this protocol. The GDB server could be a software which runs on 
the development-PC to interface with a debugging interface that connects 
to the target (i.e. OpenOCD which offers a GDB-Server and handles 
verious JTAG-interfaces, the JLINK-gdbserver which interfaces to a 
Segger JLINK or the GDB server offered by Lauterbach for their devices).
The GDB-server could also run on the target-hardware. This approach is 
often used when debugging embedded Linux applications. But I guess for a 
AT91SAM7X this approach would cost too much of the available 
processing-power and memory.

> Is there also an option to download the code in the ARM7x256 using an
> ethernet bootloader?

I don't know of any ready-made gdb-server which can run as some kind of 
"monitor" on the AT91SAM7X-controllers and offers a flash-programming 
interface for GDB. This would be needed to make something like gdb's 
"load" work. Maybe someone else knows such a software. It is possible to 
develop such a software by implementing a (reduced) GDB-server software 
which uses i.e. the uIP or lwIP TCP/IP stack for communication.

AFAIK there is a TFTP bootloader in Ethernut, which could be used to 
transfer a flash-image to a target through an ethernet connection. But 
this is neither related to debugging nor GDB.

Martin Thomas wrote:
> AFAIK there is a TFTP bootloader in Ethernut, which could be used to
> transfer a flash-image to a target through an ethernet connection. But
> this is neither related to debugging nor GDB.

Hi Thomas,

Thanks for the information. Indeed, there's no relationship between 
debugging and flashing the target.
But it just came up my mind if it's possible to remotely flash a device 
through ethernet.

So if the development-PC is the GDB server, then the target must be the 
GDB client.

How to make the target such a client?


Kind regards

J0 Vm wrote:
> So if the development-PC is the GDB server, then the target must be the
> GDB client.

I was assumpting the ethernet interface from the target itself could be 
used to debug it.

But u still need some external interface to do the job?


Sending an Image through FTP is possible, but then need the TCP or UDP 
connection be setup.
This would mean u need to first flash it serial?

J0 Vm wrote:
> J0 Vm wrote:
>> So if the development-PC is the GDB server, then the target must be the
>> GDB client.

The client for the GDB-server is your debugging-software. In your case 
the debugging-component in Code::Blocks which may call gdb (the 
software) internally.

> I was assumpting the ethernet interface from the target itself could be
> used to debug it.

This would mean that a gdb-server has to run on the target. As written, 
I don't know of any ready-made gdb-server which runs directly on an 
AT91SAM7X. There is some monitor-software available which offers some 
kind of debugging interface (IRC it's named Angel and made by ARM), but 
I have never used such software and don't know if has been ported for 
the SAM7X and it's ethernet cell. Maybe someone else who nows better can 
jump in here.

> But u still need some external interface to do the job?

If it's not an absolute "must have" to use something like a GDB-server 
directly on the target use the easier way: get a JTAG interface, a 
software which runs on the PC that can talk to the JTAG-interface and 
offers a gdb-server to for Code::Blocks. For example my usual setup is: 
Target-Board <-> Amontec JTAGkey as JTAG-Interface <-> OpenOCD as 
"bridge" between JTAG-Interface and gdb (=gdb server) <-> gdb/Eclipse 
CDT/CDT HW debugging plugin. I guess Code::Blocks offers similar 
features as Eclipse.

You can create a bootloader-software for firmware-update via ethernet 
later. This bootloader would be just used for this task and not for 
debugging.

> Sending an Image through FTP is possible, but then need the TCP or UDP
> connection be setup.
> This would mean u need to first flash it serial?

As far as I know the only interfaces supported by the factory programmed 
bootloader inside the AT91SAM7 are UART("DBGU") and USB. See the SAM7X 
and SAM-BA manuals available from atmel.com for further information. So 
yes, for flah-update through ethernet you need another software (i.e. a 
TFTP server) which you would have to transfer first using another method 
(SAM-BA, JTAG)