Could not clean D-Cache - memory(Multi-ICE仿真器调试问题)

在用“Multi-ICE仿真器”调试三星S3C2440开发板时，

可能会遇到如下问题，这里将这个问题发生的原因与解决方法做个记录。

—————————————————————————————

Could not clean D-Cache - memory may appear incoherent

in writeback regions.

—————————————————————————————

 问题简述：目标设备有独立的数据缓存和指令缓存，（比如ARM920T

体系结构的芯片），在“Multi-ICE”的配置对话框中，有一个叫做

“Cache clean code address”的设置，

（看Processor Settings Tab选项卡），在这里需要指定一块存储区域

用来存储和执行“cache cleaning code” 。“Multi-ICE”需要下载

并执行这段“relocatable”代码。假如这段代码不能够正确下载，

就会出现如上警告信息。

英文原文：

 ——————————————————————————————————

For targets that have separate data and instruction caches

(such as the ARM920T), Multi-ICE uses the Cache clean code

address setting in the Multi-ICE configuration dialog

(see Processor Settings Tab) to specify memory it can use to store

 and execute the cache cleaning code. Multi-ICE downloads and

runs relocatable code into this memory the first time it is required.

If it cannot download the code correctly, it displays this warning

message.

——————————————————————————————————

 产生原因： Multi-ICE can fail to download the code to the target

for one or more of the following reasons:

• There is no memory at the Cache clean code address

• The memory at Cache clean code address is in read only memory

 (either true ROM or memory that requires a special write procedure,

such as EEPROM) • There is an active Memory Management Unit (MMU)

 and the page containing Cache clean code address is marked read-only.

解决方法：

You can take one or more of the following steps to correct this:

• You can change Cache clean code address to an address in RAM

 that Multi-ICE can access and that is not used by the application

• You can ensure that the MMU page descriptor for the memory

you specified enables data reads, data writes and instruction reads.

You can force Multi-ICE to download the cache clean code again

by changing the Cache clean code address setting in the Multi-ICE

configuration dialog. If you ignore the error, you must be aware of

 the following:

• The Data Cache (DCache) uncachable bit is not set, and the

DCache is not cleaned while in debug state. This means that memory

 is still read precisely as the processor sees it, so there is no

inconsistency even when the DCache has dirty data in it. However,

any data read in cachable regions causes DCache linefills to occur,

so new addresses are written into the DCache and old data is evicted.

• Any data that is written to memory is written as normal. This means

that any writes that hit addresses in the DCache do not get into

 memory, but only into the cache. This matters if the data is actually

code. A side-effect of this is that software breakpoints set on

addresses that have been cached in the DCache are not read correctly

 on processor instruction fetches and so are not taken. Note If the

Fault Address Register (FAR) and Fault Status Register (FSR) are

 implemented by the system coprocessor, they are read on debug state

 entry. The values are available in the system coprocessor (number 15)

 register display and get restored before leaving debug state, unless

you write new values. If you perform a debug action that causes a

memory abort, then an error is returned that includes the FSR and FAR

 values just after the abort. 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 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 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: o For details of the code

that is required, see Debug handler firmware support. o 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 i

n 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.