Hi guys, 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. Is there also an option to download the code in the ARM7x256 using an ethernet bootloader? Kind regards, Jo
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)