5.9.1. Intended use of CADI and SCADI

The design principles for CADI and SCADI are:

CADI

Used by debuggers and simulation controllers to control the simulation. Execution control functions are always asynchronous and are usually called from a non-simulation thread, usually the debugger GUI thread. You can also use CADI to read/write registers, memory and so on, but only from non-simulation threads, for example only from the debugger thread.

SCADI

Implements a specific subset of functions of CADI, that is, mainly read/write registers and memory, set and clear breakpoints, and get disassembly. You can only use SCADI from the simulation thread itself and from threads that can make sure on their own that the simulation is currently blocked, for example a debugger thread while it is sure that the simulation is in a stable state. SCADI is intended to be used from within peripheral read/write accesses while the simulation is running, or from within MTI callbacks that the simulation is running.

SCADI does not implement and execute control functions except CADIExecStop(), because only stop makes sense from within the simulation thread. SCADI is the Synchronous CADI interface. Asynchronous functions such as CADIExecContinue() and CADIExecSingleStep() are not supported by SCADI, so for these you must use CADI instead. The SCADI::CADIExecStop() is the exception, because for CADI this means “stop when it is convenient for the simulation”, which is asynchronous, but CADIExecStop() is synchronous and means “stop now”, which you enable with the appropriate syncLevel >=2.

The guideline is:

Copyright © 2008-2013 ARM. All rights reserved.ARM DUI 0423O
Non-ConfidentialID060613