The test may be executed on the target hardware immediately, no hardware reset is required. For example, on a simulator or when the board is connected to a hardware debugger that resets or programs the target according to its configuration when a GDB client connects to it.

When using a Pipe command to openocd, openocd normally will reset and bring up the hardware in accordance with its scripts before accepting GDB commands from the Pipe. Similarly establishing a remote TCP/IP connection to a JTAG debugger such as the Ronetix PEEDI will normally configure and reset the hardware accordingly.

Target hardware can be reset through the local host execution of a command or script. You will be required to provide the command, complete with arguments, in the field alongside. Do not include the pipe (“|”) symbol. If the command is not on the path, the full path to the command must be entered. The command must also terminate with a zero exit code once the target hardware has been successfully reset. A non-zero exit code indicates the target as having failed and all following test executions are cancelled.

All output from the command will be displayed in the Output tab of the Run dialog.

The target requires manual or physical intervention (such as a power cycle or pressing the reset button). The user is directed through a dialog Window to reset the target hardware and press OK when the target hardware is ready to execute a test or Cancel to terminate the execution of the selected tests.

This is the default and is typically used when tests are loaded and executed from RAM via a debug monitor such as RedBoot. This option may also be used with hardware debuggers when eCos isconfigured with the CYGFUN_HAL_DIAG_VIA_GDB_FILEIO and CYGFUN_HAL_GDB_FILEIO configuration options enabled.

However, this method of extracting output is invasive as the target will cease test execution temporarily, either through the monitor or the hardware debugger, while the output is extracted through GDB to the host. In addition, when the target is configured with SMP, RedBoot-based debugging is currently not supported.

Select this radio button and choose the serial port on the host, along with the baud rate, on which diagnostic output from the target running eCos can be received. All data received on this port will appear in the Output tab described in Section 18.3, “Output Tab” and be interpreted as test output.

Many ARM target platforms include a Communication Device Class (CDC) USB Device using the sub-class Abstract Control Model (ACM). This enables input/output between the target and an external host to be configured in eCos through the USB-Serial connection. In addition, other targets include connectors for TTL to USB Serial converters to be attached, also providing a channel for input/output functionality between the target and an external host.

eCos supports configuring diagnostic output, such as test results, to be sent over a USB-Serial connection to a host. For example, the eCos configuration option CYGHWR_HAL_CORTEXM_DIAGNOSTICS_INTERFACE is available on certain targets to allow you to specify where diagnostic output is to be sent.

Select this radio button and choose the host name or IPv4 address, as well as the port number, on which diagnostic output from the target running eCos can be received. All data received on this port will appear in the Output tab described in Section 18.3, “Output Tab” and be interpreted as test output.

This feature is especially useful for accessing remotely located target hardware over a network where the target is providing diagnostic output over a serial port attached to either a terminal server such as the IOLAN+ Terminal Servers, or the target is connected to a remote host which provices access to its serial port through Linux applications such as ser2net or Windows applications such as realterm or TCP-Com.