Connecting Host and Target

Host and target can be connected using either serial ports, parallel ports, or Ethernet. The port to be used on the target must be specified using the COMPort command in a configuration file referenced by the Debug Monitor. The port used on the host is specified in file Rttarget.ini.

Cross Debugging Over Serial Ports

If serial ports are to be used, a NULL modem cable must be used with crossed send and receive lines. The minimal wiring of a serial NULL modem cable is:

Signal	Connect To	DB25 Pin	Connect To	DB9 Pin	Connect To
Ground	Ground	1	1	n/a	n/a
Ground	Ground	7	7	5	5
Transmit	Receive	2	3	3	2
Receive	Transmit	3	2	2	3

The baudrate set through the COMPort command and file Rttarget.ini defines the throughput. With standard ports, up to 115200 baud can be used. High speed UARTs can support up to 921600 baud (about 90k bytes per second).

Cross Debugging Over Parallel Ports

With parallel ports, a parallel LapLink or InterLink cable with the following cabling is required:

Signal	Connect To	DB25 Pin	Connect To
Data 0	Error	2	15
Data 1	Select	3	13
Data 2	Paper End	4	12
Data 3	Ack	5	10
Data 4	Busy	6	11
Busy	Data 4	11	6
Ack	Data 3	10	5
Paper End	Data 2	12	4
Select	Data 1	13	3
Error	Data 0	15	2
Ground	Ground	25	25

The transfer rate achievable with parallel ports is about 50k to 100k bytes per second, depending on the host and target speeds (both CPU speed and I/O bus speed).

Cross Debugging Over Ethernet

For cross debugging over Ethernet, host and target must be connected through a network (LAN or WAN) connection. The documentation on the COMPort command lists the Ethernet controllers supported by the Debug Monitor. On the host, any available network connection with TCP/IP support can be used.

The Debug Monitor Monitor.exe contains a minimal IP stack supporting ARP, ICMP/Ping, a DHCP client, and UDP to exchange data with the host debugger. On Time RTOS-32 component RTIP-32 is not required to use cross debugging over Ethernet, but if it is used, the application can use the same Ethernet interface as the Debug Monitor.

If the Monitor and an RTIP-32 application share the same Ethernet controller, the Monitor hooks into the RTIP-32 Ethernet driver and filters all incoming Ethernet packets to route them either to the application or to the Monitor. As a consequence, the RTIP-32 driver shared by the application and the Monitor cannot be debugged (setting a breakpoint in the driver which might then be encountered through a driver call of the Monitor will crash the Monitor with a "recursive breakpoint" error). Network performance of the application can be slightly degraded due to the packet filtering. Typically, data throughput is about 10-20% less compared to a configuration where the application runs stand-alone or is debugged through a different interface (other Ethernet controller or a serial/parallel port).

As the Monitor and the application might share hardware resources such as a PCI IRQ and/or an Ethernet controller, it is very important that all PCI devices of the application are properly shut down when the program is terminated or reset. Please see sections RTSetExitHandler and RTKInstallExitTask for details on how this can be achieved.