readme.txt

sqlite-source-wince源代码学习

vector at all, but will rather overwrite the instruction in memory. The
rest of the vectors are therefore not shadowed.

The restrictions imposed by this option are as follows:

  * The memory at the reset vector must be writable. Multi-ICE will not
    allow execution to proceed if it fails to overwrite the reset
    vector.

  * The memory at the reset vector must not be remapped, either by
    hardware or by the MMU, once execution is started. Otherwise when a
    debug exception occurs, the instruction written by Multi-ICE to
    memory may not in fact be the instruction executed by the processor.

  * The program must not overwrite the instruction itself. It may do so
    if, for example, it overwrites the entire exception vector table
    when changing the vector table contents. Otherwise when a debug
    exception occurs the processor will execute the instruction written
    by the program, and not the instruction written by Multi-ICE.

If these restrictions are not adhered, the system will cease to respond
to the debugger.

Note: A program with bugs such as the incorrect dereferencing of NULL
   pointers (in C) might cause the final restriction to be broken. Since
   the purpose of a debugger is to find such bugs, this restriction
   might prove too limiting. Setting up the MMU to prevent the program
   from writing to the vectors (Multi-ICE will circumvent such
   protection) might ease the limitation.

Ignore
~~~~~~
With "Ignore" selected, Multi-ICE will not shadow this set of exception
vectors at all.

It is therefore imperative that the program does not configure the
processor to use these vectors (by programming the HIVECS bit in the
coprocessor 15 control register). If the vectors are selected, then any
debug exception will cause the application's reset vector to be
executed, and the debug monitor will not be entered.

Multi-ICE checks before execution starts if the vectors set to "Ignore"
are currently selected by the processor. Multi-ICE will issue a warning,
giving the user a chance to abort execution:

  "Warning: Multi-ICE is configured to ignore the low vectors, but
   the target is configured to use the low vectors. Continue with
   execute? [YES] [NO]"

Selecting "Yes" allows execution to proceed. However, if the processor
does not change the setting of HIVECS, any breakpoint hit by the
program, or debug request from the user selecting "stop" from within
the debugger will most likely cause the debugger to lose communications
with the target.

You may use "Ignore" if there is a branch to the address occupied by the
debug monitor hard-wired into your application.

It is possible to configure both sets of vectors for "Ignore". If so
configured, Multi-ICE will issue a warning on execute:

  "Warning: Multi-ICE configured to ignore both low and high vectors.
   Continue with execute?"

Selecing "Yes" allows execution to proceed.

New debugger internal variables
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
These options can also be dynamically changed through debugger internal
variables (subject to the debugger being used). Multi-ICE 2.2.5 adds
new debugger internal variables. The first two are called $cache_lovecs
and $cache_hivecs.

These variables specify the mode to be used by low and high vectors,
respectively. The value set corresponds to one of the five modes listed
above:

  1 => Shadow
  2 => Bounce
  3 => Preload
  4 => Overwrite memory
  5 => Ignore

In addition, there are 14 internal variables to control the values
loaded into the vectors if (and only if) the "preload" option is in use
for that set of vectors. These variables have names such as
$cache_lovecs_preload_undef (the value loaded into the low undefined
exception vector) and $cache_hivecs_preload_dabort (the value loaded into
the high data-abort exception vector).

Each of these variables is a 32-bit value, being the opcode to be loaded.

==== NOTE ====
These variables may only be changed when the processor is stopped.
Changing during execution has no effect until the next time the
processor is stopped.

These variables default to the values set in the "Processor Settings"
tab of the configuration dialog. However, changing their value does NOT
change the persistent value set in the configuration tab. The next time
you connect with Multi-ICE the values will be set back to the values
they have in the configuration tab.
===============

Other changes to support debugging processors based on Intel XScale
technology
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Multi-ICE 2.2.2 and 2.2.3 (build 1188) had a defect that cached the
wrong instructions when shadowing the exception vectors. This defect is
fixed in Multi-ICE 2.2.5.

All previous versions of Multi-ICE that support XScale did not set
breakpoints correctly when the FCSE was used. This defect is fixed in
Multi-ICE 2.2.5.

"Never use software breakpoints" Configuration Option
-----------------------------------------------------
The "Advanced" tab in the Multi-ICE configuration dialog contains
an additional checkbox that instructs Multi-ICE to never set software
breakpoints. If this option is checked, you will only be able to set
as many breakpoints as can be set using the EmbeddedICE logic on your
processor.

When Multi-ICE sets software breakpoints, it replaces instructions in
your program with special breakpoint instructions. This configuration
option prevents this from ever happening.

It also provides a workaround for a problem on ARM10-family processors,
as described in "Important Note for ARM10-family Users" below.

Refer to the Multi-ICE User Guide for details of how to access the
Multi-ICE configuration dialog.

"Reset system on startup" Configuration Option
----------------------------------------------
When using ARM7-family and ARM9-family processors, the "Processor
Settings" tab in the Multi-ICE configuration dialog contains an additional
checkbox that instructs Multi-ICE to assert System Reset with a breakpoint
set at address 0 when connecting a debugger.

With this checkbox selected, when the debugger is connected the system
will be reset and the processor stopped at the reset vector. If the
processor does not stop at the reset vector, the connection fails.

This provides a method by which users of these processors can connect to
a reset system without any system-resident initialization code having been
run. This may be important if, for example, devices within the system
require the processor to not be stopped once they are initialized.

NOTE: This feature is not available on ARM10-family or XScale
microarchitecture processors. (For processors based on Intel XScale
technology, this option is the default if "Hot-debug" is not selected.)

WARNING: This is a configuration option, and therefore also takes affect
every subsequent time the debugger connects to Multi-ICE if Multi-ICE is
not reconfigured.

NOTE: This option only has an effect if the debugger is configured to
"halt" the processor on connection. If using a running-system debug
option (for example, in AXD the "ATTACH" option) this will override the
"Reset system on startup" configuration option.

WARNING: This option resets the entire system, including the other
processors in a multi-processor system. It is not possible to stop all
processors on reset. If debugging multiple processors (either with
multiple debuggers such as AXD, or with a multi-processor capable
debugger such as ARM RealView Debugger) you are advised not to use this
option.

Maximum Combined IR Length Limit Increased
------------------------------------------
Previous versions of Multi-ICE server had a maximum limit on the total
length of all JTAG instruction registers (IR) in a system of 64 bits.
Exceeding this limit would produce the error message:

   "The combined length of all the devices' IRs must be <= 64 bits"

Multi-ICE 2.2.2 increases this limit to 256 bits, as the complexity of
devices has increased, and exceeding 64-bits is no longer uncommon.

The text of the error message produced has been changed accordingly.

Changed Behavior of $semihosting_vector
---------------------------------------
The behavior of $semihosting_vector has been changed with relation to
use of "hivecs". See "Important Note for Semihosting Users", below,
for details.

Improved Support for Coprocessors
---------------------------------
The 'Board' tab in the configuration dialog in Multi-ICE 2.2.2 now
contains a list of coprocessors. You can select any number of
coprocessors from this list. Selecting a coprocessor adds the registers
of that coprocessor to the 'Registers' view in AXD. (Support in other
debuggers may be limited.)

The coprocessors listed depend on the processor being used. Coprocessors
that are always present on a given processor (for example, the system
control coprocessor on cached processors, the MAC unit on XScale
processors and the VFP10 coprocessor on ARM10200) are not listed.

This feature is primarily intended to provide support for VFP9-S
coprocessor users. VFP9-S users should read "Important Note for
VFP9-S Users", below.


Important Note for ARM926EJ-S Users
===================================
The ARM926EJ-S rev 0.1 and ARM926EJ-S rev 0.2 contain an error that
causes hardware breakpoints in the upper 2GB of the address space
to be missed. When using these cores, Multi-ICE attempts to use only
software breakpoints in the upper 2GB of memory.

This error is fixed in revision 0.3 of the ARM926EJ-S

If a software breakpoint cannot be set, for example because the
address lies within ROM, Multi-ICE uses a hardware breakpoint with a
mask set to ignore bit 31 of the address. As a side-effect, this may
cause false breakpoint hits at the equivalent address in the lower 2GB
of memory.

This workaround is only enabled used on ARM926EJ-S if the revision is
lower than rev 0.3. Multi-ICE can only check for the revision when
setting breakpoints when the processor is in debug state; therefore
the workaround will be disabled on processors prior to rev 0.3 for
breakpoints set when the processor is not in debug state (for example,
if using RealMonitor).


Important Note for ARM7EJ-S and ARM9EJ-S Users
==============================================
The above problem ("Important Note for ARM926EJ-S Users") also affects
ARM7EJ-S rev 1 and ARM9EJ-S rev 0. No workaround is used for these
processors as the problem is fixed in later revisions, and Multi-ICE
has no means to determine the revision. (The processors do not
contain a coprocessor 15 identification register.)


Important Note for ARM920T Users
================================
When configuring Multi-ICE for use with an ARM920T processor, the
configuration dialog contains an entry for "cache clean code address"
within the processor settings tab.

This value is only used when debugging revision 0 of ARM920T. Although
a value must be supplied for rev 1 and later versions of the ARM920T,
Multi-ICE makes no use of the address. It can therefore safely be set
to any address in memory when debugging rev 1 or later versions of
ARM920T.


Important Note for ARM10-family Users
=====================================
ARM1020T, ARM1020E and ARM1022E processors include 'branch prediction'
hardware to accelerate the execution of code. A problem exists with
these processors if the predicted target of a branch instruction has
a software breakpoint set on it. The core will stop on the breakpoint
even if the prediction was incorrect.

Depending on the prediction, the predicted target may either be the
target of the branch or the following instruction. This results in the
wrong code path being executed. The problem does not occur with
hardware breakpoints.

Two workarounds are possible for this problem. Firstly, users can
disable use of 'branch prediction' when debugging the program, and
only enable it in the final released version. Alternatively, Multi-ICE
release 2.2.2 and later has an additional feature to prevent use of
software breakpoints. See "Never use software breakpoints" above for
further details.


Important Note for ARM1020E and ARM1022E Users
==============================================
If a data abort, IRQ or FIQ occurs on these processors shortly before
the processor would have stopped for a breakpoint or watchpoint, the
processor may halt on the Data Abort, IRQ or FIQ vector (as appropriate).

AXD will report "DBE Warning 00085: The target has stopped because of a
hardware breakpoint or watchpoint." in the Debug Log window, and shows
the processor stopped at the relevant hardware vector.

Note that if you have enabled vector catch for the exception, then the
processor would have stopped anyway; the problem is only significant if
vector catch is disabled -- the processor will erroneously stop at the
vector.

It may not be possible to cleanly restart the processor after such a stop;
users should refer to the relevant errata document for further details.


Important Note for Users of Processors Based On Intel XScale Technology
=======================================================================
Some XScale Microarchitecture processors implement fault status registers.
These are in addition to the Fault Address Register (FAR) and Fault
Status Register (FSR) found in coprocessor 15. For example, the XScale 
80200 processor Bus Control Unit (BCU) has ECC Error Registers. These 
registers may be corrupted when the processor is halted during debugging.

Some XScale Microarhitecture processors (for example the PXA family of
application processors) include a "PWRMODE" register. This register allows
the application to stop the clocks to the processor, and therefore save
power. However, when in such an idle or sleep mode it may be impossible
to stop the processor from the debugger. When debugging your application,
make sure to disable any parts which make use of such a low-power mode. The
message "Attempt to force processor to enter debug state failed - execution
continues" will be displayed.


Important Note for VFP9-S Users
===============================
The VFP9-S coprocessor "FPEXC" control register contains a global-enable
bit "EN". If this bit is not set, VFP9-S will return an error when any
register is read. This is the correct behavior for VFP9-S coprocessors.

This behavior differs from the support for VFP10 in Multi-ICE. When using
VFP10, Multi-ICE silently enables the VFP whilst accessing any registers.
This can lead to the false impression that the VFP registers are readable.
The behavior of the VFP10 support is not changed for this release.


Important Note for Adaptive Clocking Users
==========================================
The text used to describe Adaptive Clocking in the Multi-ICE User Guide
states:

   Adaptive   YES if the target drives RTCK. NO if not driven.