|Home > Using the CADI Interface Methods from a Debugger > Application loading|
The CADI interface simplifies the loading of an application from a debugger to a target.
A debugger typically writes the application program code directly to the
platform memory. For simplicity, CADI has a
CADIExecLoadApplication() method that autonomously writes the application code
to the target. The debugger must extract debug information, if available, from the
executable. You can use this debug information to initialize more hardware resources of the
simulation model: for example, by setting the program counter to the entry point of the
The file path to the binary must be visible to both the debugger and the target because only the path string is passed through the interface.
The types of executable that a model supports depends on the implementation. For example, ELF file support.
You can load multiple applications to a target, for example to load several different applications to a cluster. The information about each loaded application and its received command-line parameters are stored in an internal list in the target.
This list always represents the currently loaded applications. To determine
which applications are loaded on a connected target, call the
CADIExecGetLoadedApplications(). It returns all information, including the file
paths and the applied command-line parameters, used to load the corresponding binary. Other
debuggers connecting to this processor can use this data to obtain the required debug
Preserve the list of loaded applications until a hard reset, that is until
CADIExecReset(level=0). Other reset levels that modify
program memory can also empty this list. See the documentation for the model to determine
the model behavior.
CADIMemWrite()does not have an impact on the list of loaded applications even if it breaks one of them.
To unload an application from the target (or even better, to invalidate the
application) without using a CADI reset, the debugger can call
CADIExecUnloadApplication(). This method removes the application information and
any debug information from the target. Memory contents are not, however, erased by this
call. The passed file path must be identical with the one used for