Description
Profiling is currently only possible using the ARMulator or the Angel debug monitor (running on a target board). It is not possible to use Multi-ICE or EmbeddedICE for profiling.

Profiling is an optional feature for Angel, selectable in software in devconf.h. The standard Angel images as supplied with SDT must be rebuilt to enable this.

The profiling system used by the debugger requires two things:

• The debugger must add extra calls to counter functions at the start of all the functions in the code, to record how many times the functions are being called.
• A timer interrupt must exist on the target system, together with interrupt handler code which will examine where the program was when the interrupt triggers. This information can then be used to work out how long was spent in each routine.

This means that it is not possible to profile code running out of ROM, because the debugger cannot modify the ROM code to add the 'counting veneers'.

The Debuggers place the 'counting veneers' (used for call-graph profiling) above the end of the image (at _RW_Limit). For a simple image, this corresponds to Image$$RW$$Limit. Unfortunately, this means that it is not possible to profile scatter-loaded images (with user-named execution regions, e.g. Image$$MyFlash$$RW$$Limit) or images with a fragmented memory map. Profiling is therefore limited to only simple images built with the normal defaults.

When running an application on a target with Angel (or under ARMulator) some assumptions can be made about the system the code is running on. For instance with Angel, it would have been known at the time of porting that the system has a timer. Thus the Angel code can be built to use this timer to assist with profiling - with the interrupt handler which does the timer counting being inside Angel itself.

It is not possible to perform profiling with Multi-ICE or EmbeddedICE, because these make no assumptions about the connected system (so cannot assume that a timer exists), and being 'non-intrusive' they must not make any demands on system resources such as interrupts, so cannot provide an interrupt handler.

When the user selects Options->Profile->Toggle Profiling, the debugger 'asks' the target if it can perform profiling. If the answer from the target is 'yes', then profiling will be enabled. If the target can't profile, the message 'Target Processor can't do this' is displayed.