Chapter 7. Target Setup

Most targets will require RedBoot or GDB Stubs to be installed as part of the setup procedure described in the platform documentation for the target. These normally wait for GDB to connect at 38400 baud, using 8 data bit, no parity bit and 1 stop-bit and no hardware flow control. Check the documentation for your target to ensure it uses this speed. If not, adjust the following instructions accordingly.

The following instructions depend on your having selected the appropriate serial port on the host. That is, the serial port which connects to the target's (primary) serial port. On Linux this could be /dev/ttyS0 or /dev/ttyUSB0, while the same port on Windows would be named COM1. Substitute the proper serial port name in the below.

Connect to the target by issuing the following commands in GDB console mode:

(gdb) set serial baud 38400
(gdb) target remote /dev/ttyS0

The program may then be loaded and executed, and optionally breakpoints set to make the program halt at specific points to allow debugging. For example:

(gdb) load
Loading section [...]
[...]
(gdb) break main
Breakpoint 1 at 0x12345678: file /work/main.c, line 20
(gdb) break file.c:123
Breakpoint 1 at 0x12346000: file /work/file.c, line 123
(gdb) continue
Continuing.

Some targets allow GDB to connect via Ethernet - if so, it will be mentioned in the document describing the target. Substitute the target's assigned IP address or hostname for <hostname> in the following. Depending on how RedBoot has been configured, it will either have this address allocated statically, or will acquire it via BOOTP/DHCP. In both cases RedBoot will report the IP address it is listening on in its startup message printed on the serial port. The <port> is the TCP port which RedBoot is listening on, usually 9000. It is also listed in the target document.

Connect to the target by issuing the following command in GDB console mode:

(gdb) target remote <hostname>:<port>

The program may then be loaded and executed, and optionally breakpoints set to make the program halt at specific points to allow debugging. For example:

(gdb) load
Loading section [...]
[...]
(gdb) break main
Breakpoint 1 at 0x12345678: file /work/main.c, line 20
(gdb) break file.c:123
Breakpoint 1 at 0x12346000: file /work/file.c, line 123
(gdb) continue
Continuing.

JTAG can be used to single-step and debug loaded RAM applications, or even applications resident in ROM. If JTAG is supported by your target, please refer to the documentation describing the target as you will need to configure your JTAG debugger appropriately. Certain targets may also need to specify a JTAG startup type in the eCos configuration. Again, refer to the target specific documentation.

Many JTAG debuggers provide a GDB server to which you may connect GDB to download, run and debug your application. This is typically done over ethernet so refer to Section 7.2, “ Connecting Via Ethernet” for instructions on how to debug over ethernet and replace <hostname> with the name or IP address of the JTAG debugger, and <port> with the port number typically associated with your JTAG debugger. For example, for the Ronetix PEEDI the port number is normally 2000, while for the Abatron BDI3000 the port number is normally 2001.

Debugging of ROM applications is sometimes only possible if using hardware breakpoints, and some hardware may only support a very limited number of hardware breakpoints so they should be used sparingly. Check the target documentation to see if your target falls into this category. If so and you use a GDB front-end such as Eclipse, check it has not set unnecessary extra breakpoints. Some JTAG devices give the option of whether to set hardware or software breakpoints by default. Be sure to configure your device appropriately.

Some targets allow the use of OpenOCD for debugging and development - if so, it will be mentioned in the document describing the target. For these targets, the openocd executable provided with the eCosPro Host Tools must be used along with the openocd.cfg configuration file for the target.

One of the enhancements of eCosPro 4.x was the placement of all target-specific configuration files for hardware debuggers, such as openocd.cfg or peedi.cfg, into the install/etc directory of the eCos build tree. These configuration files may also be configuration specific. In addition, with consistent naming, developers are easily able to reference and use the configuration files.

Connect to the target by issuing the following command in GDB console mode:

(gdb) target remote | openocd -f /home/test/dev/demo_install/etc/openocd.cfg -c "gdb_port pipe"

The program may then be loaded and executed, and optionally breakpoints set to make the program halt at specific points to allow debugging. For example:

(gdb) load
Loading section [...]
[...]
(gdb) break main
Breakpoint 1 at 0x12345678: file /work/main.c, line 20
(gdb) break file.c:123
Breakpoint 1 at 0x12346000: file /work/file.c, line 123
(gdb) continue
Continuing.

	Warning
	Do not use publically available or third-party openocd or gdb executables. eCosCentric have made patches to these applications to either fix or add functionality to allow them to be used with eCosPro development.

Synthetic targets are special in that the built tests and applications actually run as native applications on the host. This means that there is no target to connect to. The test or application can be run directly from the GDB console using:

(gdb) run

There is therefore no need to connect to the target or download the application, so you should ignore GDB “target” and “load” commands in any instructions found in other places in the documentation.

At present, only Linux Synthetic Target support is available.