| Copyright © 2003, 2004 ARM Limited. All rights reserved. | ARM DUI 0234B |
| Non-Confidential | |
 PDF version | |
| Home > Connection Properties Reference > Target configuration reference > The Advanced_Information block |
| |||
| Home > Connection Properties Reference > Target configuration reference > The Advanced_Information block | |||
The Advanced_Information block enables
you to provide ETV information, for example about extended memory
mapping, mapped registers, and peripherals. Because more than one
device might be present, and each might have different details,
you can create more than one information block. The base block is
called Default and is used if you provide no
other information. Entry names can be the same as processor or device names
in .jtg files. These apply more specifically
to matching devices. Advanced information settings can be nested
so that one might refer to another which might refer to another.
These references cause the information to be concatenated. References
are made to board and chip definitions.
The Default group in an Advanced_Information block
contains:
Use the Application_Load block to change
the way that an executable image is loaded into target memory. The
default is to write the memory using the emulator or EVM board.
This block can be used to override the default and so disable all
image load, for pure ROM or EPROM systems, or to run an external
program to do the load.
The Application_Load block contains the
following settings:
Specifies how to perform the load.
This
defines a shell command run to perform the load. The command might
contain $ variables which are substituted by RealView Debugger before
calling. The possible $ variables are:
$Ddirectory of the application
$Pfull path of the application
$Ffilename of the application
$Nname of the application without the extension.
If the command starts with an exclamation mark (!),
the return value of the shell command is not used to stop the load,
otherwise a non-0 return aborts the load. In all cases, the output
of the command is shown in the Log tab in
the Output pane.
This
controls how the program counter is initialized during an image load.
The default is to set the program counter to the entry point if
an entry point is defined and symbols are loaded and this is not
an appended load (it is replace or new). This enables you to disable
setting the program counter under any situation, or to set it specifically
to address 0.
Memory_block entries are used to build
up fixed, enabled, or based memory regions. A fixed block is one
that refers to memory that is always enabled, always at the same place,
and always the same size. An enabled memory block is enabled or
disabled by a register value, see Map_rule. A based memory block has its start or
length adjusted or set by a register value. This value might be
added to an offset or might itself be the required value.
This contains the following settings:
Additional attributes can be specified for the memory. These are used by the simulators and guide the debugger in access to this block of memory. The following settings are available:
This memory is internal to the processor core and not treated as external. This affects wait-state timings and other factors.
The access rule information is only used in simulators to control timing issues. It is noted if a link command file is generated.
This field enables control of how the memory is accessed by the debugger internally. For external memory with only byte-wide or halfword-wide access enabled, this can be used to ensure proper access to the memory. Depending on the processor, this might have no effect.
True if access destroys contents or the contents change in response to external events.
This field indicates if the memory is shared with other processors. If it is, it also indicates if directly shared (accessed directly using the bus) or indirectly shared (using the host workstation port of this processor). If this is set, this field indicates what other processors or devices see this memory.
This field contains a number that identifies this memory block. You must use the same number for each device when referring to it. RealView Debugger can then correctly update all device views when this memory is modified.
Used when one or two memory-mapped registers
are used to set the base address and length of the memory block,
such as for cross-bar switches, and chip-selects. These are not
used for enables which are set using map rules, see Map_rule. The following
settings are available:
Enables you to specify a memory block position based on a memory-mapped register. The value of the register is added to the start field to construct the block start address. It can be masked and scaled (multiplied or divided) first.
Mask to apply to register.
Use
this to change the value of the register contents, after masking,
to define the actual base. If the number is positive, it is multiplied
against the register content. If the number is negative, it is divided
from the register content. For example, a byte register might select
the 64KB region to map to. If the scale is 0x10000 (64K),
then register values of 0, 1, 2, 3, ... each select a 64KB region.
If the selector occupies part of a register, the mask is applied
to select only the selector portion and the scaling value itself
might be scaled. Using the example above, if the byte selector portion
is the upper byte of a register, the scale value is 0x10000/0x100=0x100 (256).
So, mask with 0xFF00 and multiply by 256 to get
a 64KB selection.
Enables a block of memory to be sized by a register. This is commonly used in multi-processor shared memory systems. The content of the register is added to the specified length to compute the block length.
Mask to apply to register.
Used like Base_scale.
Enables table indexing for the length. The length register is masked and scaled and then used as an index in a table of values. The last value is used if the scaled register value is too large. The table value is added to the length field of the block.
Indicates how often to check the register to see if the mapping has changed. For cases where the mapping is set by jumpers, which read as registers, it must be inspected only when first connecting to the device. If the program changes it, it must be tested on each stop. Valid values are:
init_timeTest when connecting to device.
update_initTest on connect and when register changes.
stop_updateTest on connect, change, and execution stop.
The base address of the block. If the block is mapped using a register, this is the offset from that register.
The block length
of this memory unit. If Length is set by a register,
this must be 0 or the amount to add to that register.
The type of memory is dependent on the device type. The default is to map to data space. Otherwise, a memory space can be specified. Valid values are:
Default
Program
Data
IO.
Indicates how the memory is to be treated. For simulators, this affects the target use of the memory. For real targets, this only affects how the debugger uses the memory and any generated linker command files.
Used with simulators to calculate the cycles used when accessing this memory. The default is based on the wait-state model used by the processor for external memory. This value is noted when link command files are generated from this data to enable careful positioning of sections to this memory.
Contains the
name of a file containing the Flash programming code and information
for this processor. Example files are provided in the directory
installed as part of the root installation. These files have the
file extension program_directory\flash\examples.fme.
By using the routines in this file, RealView Debugger can erase, modify and verify the contents of Flash memory.
Description of memory space.
Enables you to
define ranges of a memory block that is volatile on read (and so
is marked specially in the Memory pane). The format is an offset from
within this block (0 relative). A range can be specified, for example 0x10..0x20 or 0x40..+4.
If not a range, it defines a single value.
These entries control the enabling and disabling of memory blocks using target registers. You specify a register to be watched, and when the contents match a given value, a set of memory blocks is enabled. You can define several map rules, one for each of several memory blocks. The following settings are available:
This is the name
of a memory-mapped target register that controls the visibility
of a memory block. This register is read to determine the current mappings.
You must define the register using the Register block, see Register.
You are recommended to name the register itself instead of the bit fields within it when more than one bit field controls the mapping.
This is ANDed with
the contents of the register as described in Value.
This is compared
with the register contents after the mask is added. The comparison
is (reg-value & mask) == value. For example,
if bit 3 being HIGH means the map is enabled, mask is 0x8
(1<<3) and value is also 0x8.
This contains the name of one or more memory blocks to enable when the value matches, or disable when it does not match. To replace one block with another, create one rule that tests for one value and another that tests for a different value.
Indicates how often to check the register to see if the mapping has changed. For cases where the mapping is set by jumpers, which read as registers, it has to be inspected only when first connecting to the device. If the program changes it, it must be tested on each stop. Valid values are:
init_timeTest when connecting to device.
update_initTest on connect and when register changes.
stop_updateTest on connect, change, and execution stop.
Enumerations can be used, instead of values, when a register is displayed in the Register pane. This setting enables you to define the names associated with different values. Names defined in this group are displayed in the Register pane, and can be used to switch the register.
Register bit fields are numbered 0, 1, 2,... no matter where they are positioned in the register.
The following setting is available:
You can specify a list of names,
either in the form name,name,name,...name=value,name=value,name=value,...
This entry enables you to define memory-mapped registers provided at the board or ASIC level. Each register is named and typed and can be subdivided into bit fields (any number of bits) which act as subregisters.
The Register entry contains a group called Bit_fields which
in turn contains the Default settings:
Bit position from 0 (LSbit).
Size in bits.
True if signed, false if unsigned.
Enumeration name
to show values to show values in the Register pane, derived from Register_enum group.
True if read-only (cannot modify).
Indicates that the register has side-effects when it is read or written. A common read side-effect is loss of data (when pulled from a UART, for example). A common write side-effect is for the device to take some action on write (triggering a DMA, for example). This information is used in the Register pane.
Optional name for showing in Register pane.
Other settings in the Register entry are:
The base address
of the block. If the register is mapped using a memory block, this
is the offset from that register (see Base).
The block length
of this memory unit. If Length is set by a register,
this must be 0 or the amount to add to that register.
This specifies how
to interpret Start. If Base is Absolute, Start is
the memory address of the register. Otherwise, Base can
be set to the name of a memory block, and Start is
an offset from the base address of that memory block.
The type of memory is dependent on the device type. The default is to map to data space. Otherwise, a memory space can be specified. Valid values are:
default
program
data
IO.
Specifies how to interpret the value contained in the register. The type names are as in the C language.
If this value
is True, the register is read-only and the debugger
does not let you write to it. Otherwise, you can modify the value
using the Register pane in the Code window and using CLI expressions.
If this value
is True, the register cannot be read. The debugger
does not attempt to query the hardware for the current value when
the Register pane is displayed.
If this value
is True, the register value can change without
the debugger explicitly modifying it. For example, a hardware timer
continues to count even when the processor is halted.
The name of a Register_enum block
that maps a register value to a textual string describing the value.
The name of the register as it appears in the Register pane.
You can define a concatenated register that is built up using specific bits from other registers. Concatenated registers are usually used only for memory mapping, but you can also use them for control and status. The suggested approach is to name two registers and then shift and mask them into the new register. If you want to concatenate parts from more than two registers, you can build them up in stages.
The following settings are available:
Name of low register.
Amount to shift low register by (<0 for left shift).
Amount of low register to mask (after shift).
Name of high register.
Amount to shift high register by (<0 for left shift).
Amount of high register to mask (after shift).
Length of register, in memory units.
An explicit type for the register. If you do not specify the type, the default is the signed scalar C type based on the register size.
Enumeration name
to show values to show values in the Register pane, derived from Register_enum group.
Optional name for showing in Register pane.
This entry enables you to define block peripherals so they can be mapped in memory, for display and control, and accessed for block data, when available. You define the peripheral in terms of the area of memory it occupies (for all its registers), and a breakdown of the registers used for access and control. The following settings are available:
This applies only when you can access blocks of data, and contains:
Method used to extract data.
Name of access method function if required.
Buffer or DMA start address.
Buffer or DMA length.
Used to add memory mapped registers provided at the board or ASIC level. Each register is named and typed and can be subdivided into bit fields (any number of bits) which act as subregisters. See Register for details.
Start address of first peripheral register.
Block length.
Controls how the start field is interpreted. The default is Absolute (from 0), but can be relative to a memory block (if the block is disabled, the peripheral is too).
Basic type of the device. The available values are:
Serial
Parallel
Block
Network
Display
Other.
Description of the device.
This entry contains a set of lines to show in the Register pane. The name of the block is the tab name used for the lines. Each line contains a list of mapped registers displayed in the Register pane, see Register_enum, Register, and Concat_Register for more details.
The format of a line is name,name,name,...name
If the string starts with an equals sign, =,
all the registers are shown as name=value in
the window, else shown in table form (the name is above the value).
If a line starts with an underscore character, _,
the line shows as a comment label (non-active).
If the line starts with an exclamation mark, !,
it provides a description line for the tab.
If the line starts with:
the next line starts or ends an expansion
block, controlled by + or -.
indicates a collapsed block
indicates a expanded block
this ends a previously opened block.
This entry enables control of the ARM® architecture-based processor used for emulators or monitors. The features controlled are semihosting, vector catching, and memory top control (for stack and heap assignment). These must be set or unset depending on the type of runtime you have linked into your application.
You can also set many of these at runtime using pseudo-registers.
To do this, name the block Default if it applies
to all devices or give it the name of the scan chain device to which
it applies.
The following settings are available:
The ARM tools automatically set the stack and heap based on the top of memory using semihosting. The following settings are available:
Bottom of stack (lowest address).
Size of stack in bytes.
Bottom of heap (lowest address).
Size of heap in bytes.
If Vector_catch is
set to True, the fields within this block enable
individual control over each vector.
Contains:
Address of SWI vector catch to use.
ARM SWI instruction for semihosting.
Thumb SWI instruction for semihosting.
This is not supported.
Enables
the semihosting mechanism to return the top of stack and base of heap.
If not defined here, the default for each tool is used. Any defined value
is set into each tool to force this address base. You can use explicit stack
and heap sizes and locations below, but this might not be supported by
all target debug targets. You can also set this during a debugging session
using the @top_mem pseudo-register.
Used
to catch possible program errors by setting breakpoints on (or otherwise
trapping) the vectors. The default is to catch error-type vectors but
leave IRQ, FIQ, and SWI alone. SWI is caught separately by semihosting
if enabled. To use this, the vectors must be writable. These can
also be set during debugging using the @vector_catch pseudo-register. In
this case, each bit, starting with 1, represents the vectors from reset to FIQ.
Enables programs
to communicate with the host workstation. Semihosting operations
supported include stack and heap assignment and console I/O (printf and scanf type
calls). Semihosting is implemented using the SWI instruction. You
can change the semihosting vector during debug using the @semihost_vector pseudo-register.
You can also define a window number to display semihosting printf messages
using @semihost_window. The window numbers match
the VOPEN command numbers.
This enables
free-form definition of the properties required by a vehicle. The
form of the string is name=valuenamevalue
This entry enables automatic loading of RTOS and kernel awareness. This entry enables forced loading of RTOS support or symbol hooking. When the RTOS is symbol-hooked, support is only loaded when the RTOS, or its symbols, are loaded to the target. See the instructions from your vendor for proper setup. If supporting your own RTOS and kernel, use the method that best matches your DLL.
The following settings are available:
Select the manufacturer of the RTOS from a popup list.
Accepts a keyword from a list to specify when to load RTOS, for example on connection (connect), or when image is loaded (image_load).
Defines a base address for RTOS data structures. See the documentation for your specific RTOS support code.
Forces an order for device connection. When you connect to
a device within the .jtg file, this ensures
that one or more specific devices are connected first no matter
which you selected for connection. This enables pre-setup of the
specific devices to guarantee correct operation, such as initializations.
You can specify the device(s) to connect to first by name, by processor
name, or by processor type.
This enables you to specify RealView Debugger commands to run after
a connection is established. The most common example is INCLUDE to
include commands from a file. The commands are run after the connection
is completed. If Pre_connect is set, and the pre-connected
device is running this command, the command executes before the original
device is connected.
This setting defines the connection mode, described in Setting connect mode, when you connect
by checking the check box in the Connection Control window, or when
the debugger automatically connects on start-up. If you connect
using the CONNECT command, or using the File menu,
the connection mode is set in other ways. The options include:
Connect in the standard way for this connection type.
Prompt for the connection mode to use.
Stop the target, placing it in debug state.
Reset the target and place it in debug state
Leave the target running, making use of non-stop debug facilities of the connection, if available, to display memory.
The options available for Connect_mode settings
are generic to all vehicles and supported processors.
This setting defines the disconnection mode, described in Setting disconnect mode, when you disconnect
by checking the check box in the Connection Control window, or when
the debugger automatically disconnects on exit or when making a
new connection in single-connection mode. If you disconnect using
the DISCONNECT command, or using the File menu,
the disconnection mode is set in other ways. The options include:
Disconnect in the standard way for this connection type.
Prompt for the disconnection mode to use.
Leave the target in the state it is in. That is, if it is stopped, leave it stopped, if running then leave it running. Breakpoints that are currently set are not deleted.
Leave the target stopped, in debug state
Leave the target running, with breakpoints deleted.
The options available for Disconnect_mode settings
are generic to all vehicles and supported processors.
The chip-id, or silicon-id, is loaded from the processor normally.
When accessing special custom chips, it might be necessary to force
the ID explicitly. The ID can be expressed as a 16-bit number or
in num.num.num
This contains the expected silicon ID from the processor.
If it does not match this value, you are prompted to choose whether
or not to continue the connect operation. The ID can be expressed
as a 16-bit number or in num.num.num
This defines the manufacturer name of the actual device, such
as family name or core name. The Chip_name field
enables you to specify a name to use in messages and lists displayed
by RealView Debugger. It does not enforce the chip family selection. For
that, you must use the Id_chip field.
| Copyright © 2003, 2004 ARM Limited. All rights reserved. | ARM DUI 0234B |
| Non-Confidential | |
| PDF version | |
| Home > Connection Properties Reference > Target configuration reference > The Advanced_Information block |