7.1.3. Synchronization and cross-triggering

When you have multiple processors that are cooperating within a single application, it is sometimes useful to control all processors with a single debugger command. RealView Debugger provides a synchronization mechanism to:

Also, you might want to examine the state of all processors at one point in time. A processor stops for the following reasons:

Synchronization and cross-triggering differ as follows:

You must manually identify the target connections that are to be synchronized or that are to take part in cross-triggering.


Synchronization and cross-triggering are separate mechanisms. Therefore, processors do not have to be synchronized to take part in cross-triggering.

Definition of terms used in synchronization and cross-triggering

The following terms are used for synchronization and cross-triggering in RealView Debugger:

Processor group

In this section, the term processor group is used to refer to the set of processors that are configured to operate in a synchronized way.

You can synchronize:

  • multiple simulated RVISS targets

  • multiple hardware targets

  • simulated targets with hardware targets.


For a processor group, skid is the time delay between the first processor stopping and the last processor stopping, and is an artefact of cross-triggering:

  • When hardware cross-triggering is used, the delay involved (that is, the length of skid) might be a small number of clock cycles.

  • When software cross-triggering is used, RealView Debugger must receive the stop request from the triggering target, process the request, and then send the stop request to each triggered target. Therefore, the skid time is far greater with software cross-triggering.

Loose synchronization

In some situations, RealView Debugger might synchronize processors loosely, such as in a mixed hardware and software environment or in a CoreSight system. This is characterized by a large skid, of as much as one to two seconds, because the synchronization is usually controlled by software. A large skid might also arise because there is no hardware synchronization control, so the debugger must issue start and stop commands individually.

When you add a target to the processor group for synchronized execution, and loose synchronization is in force, then RealView Debugger displays:

  • a warning message in the Output view:

    Synchronization will be loose (intrusive) for some or all connections in the synch group.

  • a message in the Synchronization Control window:

    Loosely coupled

Tight synchronization

In a hardware environment using a single DSTREAM or RealView ICE unit, RealView Debugger uses a closely synchronized system where this is supported by the underlying processor or emulator. This has a very short skid, usually a few microseconds or less, and perhaps only a single instruction. This is because the synchronization controls are built into the target hardware, or hardware assistance is available in the DSTREAM or RealView ICE unit, or other JTAG emulator.


Tight coupling is supported only for JTAG systems, that is ARM7, ARM9 and ARM11 processors. If there is a DAP, as in a CoreSight system, then tight coupling is not supported by DSTREAM or RealView ICE.


Cross-triggering occurs when one processor in a group stops because of an internal or an external event, which then causes other processors to stop.

The initial stop activates an external signal on the processor, for example DBGACK, that causes the cross-triggering hardware to generate an input signal to the other processors, for example CPU0 stop, that stops the processors. Each of these other processors skids before it stops.

For a target system that does not have hardware cross-triggering, the debugger can perform a similar function in software. However, the processes involved are more complex, and the skid time is much longer. For example, hardware cross-triggering might be able to stop all processors five target instructions after the initial breakpoint. A software solution might take many more target instructions.

If two processors, CPU0 and CPU1, are taking part in software cross-triggering and both reach an address that has a breakpoint, then there is a delay in processing the breakpoints:

  1. The breakpoint on processor CPU1 is activated, which initiates a stop request to CPU0.

  2. The software cross-triggering mechanism stops the processor CPU0. However, the breakpoint on CPU0 is not processed at this time.

  3. When CPU1 restarts, it continues to run.

  4. When CPU0 starts, the breakpoint on that processor is processed. CPU0 might stop or continue execution depending on the breakpoint actions.

See also

Copyright © 2002-2011 ARM. All rights reserved.ARM DUI 0153N