4.3.2. Processor Settings Tab

The Processor Settings tab enables you to change processor specific settings before you connect to the target. The settings you can define depend on the processor you are connecting to, and so you must select a processor (using the Connect tab) before this tab can be used. You can change the following settings:

Cache clean code address

This setting, shown in Figure 4.11, is the base address of an area of 128 bytes of memory that is used to store a code sequence that ensures that all of the dirty data in the Data Cache (DCache) is written into main memory.

Cleaning the DCache is important because when the processor caches are enabled, program instructions that are written to target memory are written through the DCache but read through the instruction cache. If the DCache is not cleaned, some or all of the instructions are not written to main memory before the processor executes them, and so the previous contents of memory at that address is executed instead.

Multi-ICE loads the cache clean code as required. The area must be program memory, readable and writable, and must not be used for any other purpose. If Multi-ICE cannot load code to this memory you see the error Could not clean D-Cache - memory may appear incoherent in writeback regions. Refer to Multi-ICE server messages for more information about this message.

For some processor types, restart code must also be downloaded that enables Multi-ICE to restart the processor when a breakpoint or exception is handled. For these processors, the restart code is written to the cache clean code address.

Figure 4.11. Multi-ICE Processor Settings tab showing cache setting

Multi-ICE Processor Settings tab showing cache setting
Cache clean data address

This setting for XScale microarchitecture processors, shown in Figure 4.12, is the base address of a 32KB region of memory that Multi-ICE uses when cleaning the processor cache. This memory region:

  • must be cachable

  • must be aligned to a 32KB address (that is, the least significant 15 bits of the address must be zero)

  • must be 32KB in size.

Note

Physical memory does not have to exist at this location.

Figure 4.12. Multi-ICE Processor Settings tab showing XScale settings

Multi-ICE Processor Settings tab showing XScale settings
XScale debug handler options

These settings, shown in Figure 4.12, configure the behavior of the debug handler that is used with an XScale microarchitecture processor.

The following settings are available:

Debug handler address

The base address of a region of memory that can be used by the debug handler code. This memory:

  • must be aligned to a 2KB address (that is, the least significant 11 bits of the address must be zero)

  • must be 2KB in size

  • must be in the range of an ARM branch instruction (approximately ±32MB) from address 0

  • must not be used for any other purpose.

Note

Physical memory does not have to exist at this location.

If you enter an invalid address a message box reports that The address you have entered is invalid.

Hot-debug enabled

A toggle that enables or prevents Multi-ICE from connecting to an already running XScale microarchitecture processor by using a debug handler:

  • If you enable hot-debug, ARM Limited recommends that the target provides firmware support for this feature:

    • For details of the code that is required, see Debug handler firmware support.

    • If you do add this firmware support, you must check the Flush debug handler cache if running on exit box, and select the Leave processor in Monitor mode on exit button.

  • If you disable hot-debug, Multi-ICE always resets the processor when connecting.

Flush debug handler cache if running on exit

A toggle that controls whether or not the debug handler is flushed from the cache on exit from the debugger:

  • If this box is checked, and the processor is running, the debug handler is flushed from the cache. The debugger cannot later reconnect to the handler.

  • If this box is not checked, the debug handler is not flushed from the cache. The debugger can later reconnect to the handler.

    Note

    Any code that subsequently alters the exception vectors does not function correctly (see Intel XScale microarchitecture processors).

Leave processor in Halt mode on exit, Leave processor in Monitor mode on exit

Buttons that set whether to leave the processor in Halt or Monitor mode on exit from the debugger:

  • If you leave the processor in Halt mode, and a reset subsequently occurs, the debug handler is not flushed from the cache. The processor halts, waiting for the debugger to connect to the handler.

  • If you leave the processor in Monitor mode, and a reset subsequently occurs, the debug handler is flushed from the cache, and the processor resets.

Copyright © 1998-2002 ARM Limited. All rights reserved.ARM DUI 0048F
Non-Confidential