Device configuration settings

You can configure settings that are specific to a target device on your development platform. The settings available depend on whether the device is a processor or a non-processor CoreSight device.

Show/hideProcessor device settings

Depending on the processor that you have selected, a selection of the following controls is available:

Allow execution with T-Bit Clear

The Cortex-M series processors can only execute Thumb2 code. However, their xPSR contains a bit to configure ARM/Thumb state, that is initialized from the reset vector. This enables you to test the exception handler associated with this exception type.

Bypass memory protection when in debug

This option enables the bypass of any memory protection provided by hardware (such as a memory management or protection unit) whenever the target hardware enters debug state. This means that you can access protected memory to set software breakpoints in it, or to alter its contents.

Clear breakpoint hardware on connect

This control is available if you are using the ARM11 family of processors. The debug logic of an ARM11 processor is not reset when a Test Access Port (TAP) reset is applied. Set this option to True to instruct the debug hardware unit to perform reset the debug logic each time you connect.

Code Sequence settings

Most systems store variables and the stack and heap in RAM. However, in some systems only Flash or ROM is mapped in memory at power-up and RAM must be enabled by software in the boot code.

To perform certain operations with some targets, the debug hardware unit must download a piece of code into memory and make the processor execute it. This code must be located in a writable area of memory (RAM) and must be accessed only by the JTAG tool.

You can set the address and size of this code using the Code Sequence Address and the Code Sequence Size (bytes) settings.

When you connect with a debugger to one of these targets, make sure that RAM is mapped in memory and that the cache clean code or code sequence address is mapped correctly. You can run a script from the command line to configure the target memory map straight after connecting to the target.

This area of memory must be:

  • unused by the target

  • readable

  • writable

  • non-cacheable (for cached targets)

  • at least 128 bytes in size.

The debug software downloads code sequences to this area to perform various tasks, such as cleaning the cache and accessing certain system registers on targets such as ARM920T™ and ARM1136JF-S. It does not preserve the contents of this area.

Note

You must ensure that the Code Sequence Address and the Code Sequence Size (bytes) values are correctly set up before you attempt to write to any of the Cache Operations or TLB Operations in the your debugger Registers view. If you do not set these values correctly, your debugger gives one or more of the following errors:

  • Error V28305 (Vehicle): Memory operation failed

  • Warning: Code sequence memory area size error

  • Unable to load code sequence into defined memory area.

The Code Sequence Timeout (ms) value sets a timeout for execution of the uploaded code sequence. For most targets, a 500ms timeout is sufficient.

The Use code sequence to clean cache option enables you to configure how the caches are cleaned if you are using ARM 920T or ARM922T processors. Set this option when using the debugger to access IO memory, for example peripheral control registers for Universal Asynchronous Receiver/Transmitters (UARTs), when caches are enabled.

CoreSight AP index

The AP index of the corresponding device.

Available only for processors that are part of a CoreSight system.

CoreSight base address

The base address of the CoreSight registers for the processor on the Advanced High-performance Bus (AHB) or Advanced Peripheral Bus (APB).

Available only for processors that are part of a CoreSight system.

Debug acceleration level

This controls the level of acceleration used in debug operations.

Select one of the following options:

0 - Full

This is the default. It enables full use of the performance features of RVI and the target processor.

1 - Partial

This results in a lower performance than for the Full option.

2 - None

Select the None option to use only basic operations. This results in the lowest performance available.

Note

In most instances, select the Full option unless advised otherwise by an ARM support engineer.

Default Gateway

Default gateway for the target when using virtual Ethernet. Used with the IP Address and Network Mask settings to enable access to your target from the network.

Fast Memory Download

This configuration item is available only for processors connected to a JTAG-AP port. Set this to False if you experience problems using fast memory downloads.

Ignore bad JTAG IDCODE

By default, debug hardware reads the device JTAG IDCODE to verify the integrity of the JTAG connection. The JTAG standard restricts the JTAG IDCODE value to be 32 bits long and requires the least significant bit to be a 1. If debug hardware reads an invalid (bad) JTAG IDCODE, it assumes that the JTAG connection is not functioning properly, and fails the attempt to connect to the processor.

You must set the Ignore bad JTAG IDCODE option according to whether you want to instruct debug hardware to enable connection to the processor even if it detects that the JTAG IDCODE is invalid.

Ignore debug privilege errors when starting core

When the SPIDEN line is changed from HIGH to LOW, the following errors might be seen:

  • Insufficient debug privilege to restore core state for restart.

  • Insufficient debug privilege to write software breakpoint to memory.

  • Set Ignore debug privilege errors when starting core to suppress these errors.

If set to True, debug hardware starts the processor running even though the breakpoints/processor state is incorrect.

If set to False (the default), debug hardware refuses to start the processor and reports the errors.

IP Address

IP address of the target when using virtual Ethernet. Used with the Default Gateway and Network Mask settings to enable access to your target from the network.

JTAG timeouts enabled

JTAG timeouts are enabled by default. You must disable these when debug hardware is connected to a processor using a low clock speed and adaptive clocking, because debug hardware cannot detect the clock speed when adaptive clocking is used, so cannot scale its internal timeouts. If a JTAG timeout occurs, the JTAG is left in an unknown state, and debug hardware cannot operate correctly without reconnecting to the processor.

Network Mask

Net Mask of the target when using virtual Ethernet. Used with the IP Address and Default Gateway settings to enable access to your target from the network.

No error if step-instr can't stop.

Controls generation of error messages if a debugger step instruction operation fails because a timeout attempts to stop the SecurCore processor after a step is complete. This can occur on the SecurCore if an instruction execution results in the processor clock being disabled using CLKEN. The processor appears to be in a running state.

If set to True (the default), then no error message appears if an instruction step results in the processor running.

If set to False, then an error dialog box is displayed in your debugger.

Post Reset State

Set to the required state for the target hardware:

Running

The target hardware is running.

Stopped

Controls the state of a processor after a reset. It is only available for devices that are capable of running (such as ARM processors). Each device on the scan chain does not have to be set to the same value, so it is valid to have one processor running and another stopped.

Note

If you want to connect to a running target without performing a reset and without stopping the target, you must do both of the following:

  • In debug hardware, set the Post Reset State to Running.

  • In your debugger, connect using the No Reset/No Stop connection mode.

Soft TAP reset on JTAG sync loss

In some situations, such as a processor entering low power mode, the synchronization between the debug unit and the TAP controller in the JTAG system can be lost. This can result in invalid values for the debug status register being read. To regain the synchronization, a soft TAP reset must be performed to get the TAP controller into a known state.

If Soft TAP reset on JTAG sync loss is checked, a soft TAP reset is performed to get the TAP controller into a known state if the debug unit reads invalid values for the debug status register.

Software breakpoint mode

If supported by your processors, this control enables you to configure how the debug hardware unit handles software breakpoints. Select the required breakpoint mode:

AUTO

This is the default mode for all templates:

  • If the processor being debugged supports BKPT instructions, debug hardware automatically uses the BKPT instruction for software breakpoints.

  • Only one watchpoint resource is used for multiple software breakpoints. Therefore, if the processor being debugged does not support BKPT instructions, debug hardware uses the watchpoint unit resource when you set a software breakpoint. The debug hardware unit automatically frees the watchpoint unit resource when all software breakpoints are cleared.

NONE

When this mode is selected, you cannot set software breakpoints. If you attempt to set a software breakpoint, debug hardware gives an error message telling you that there are no free resources to set the breakpoint.

WATCHPOINT

This mode instructs debug hardware to use one watchpoint unit to provide software breakpoint instructions, whether or not the processor being debugged supports BKPT instructions. Select this option if the processor supports BKPT instructions but you want to use a watchpoint unit.

BKPT

This mode instructs debug hardware to use the BKPT instruction to provide software breakpoint instructions, whether or not the processor supports this instruction. Select this option if you want to make sure that no watchpoints are used.

Unwind vector when halt on vector catch

This control is available if you are using an ARM10 processor. It instructs the debug unit to unwind the vector if you have set a vector catch on a SWI, an Undefined instruction, a Prefetch Abort or a Data abort. Unwinding the vector sets the PC to the address of the code that caused the exception instead of leaving it at the vector address. The LR and CPSR are restored, and debugger displays the code at this address. This enables you to more easily examine the code that caused the exception. If you want to run the exception handling code, you must leave this option unchecked.

Note

This option is only activated if a vector catch occurs. If a vector catch is not set, then the exception handler is run as normal.

Unwind vector when halt on SWI

This control is available if you are using the following:

  • a Cortex-A8 or Cortex-R4 processor

  • ARM1136JFS-JTAG-AP, ARM1156T2FS-JTAG-AP, or ARM1176JZF-JTAG-AP device.

It instructs debug hardware to unwind the Supervisor Call (SVC) vector if you have set a vector catch on an SVC. Unwinding the vector sets the PC to the address of the code that caused the exception instead of leaving it at the vector address. The LR and CPSR are restored, and your debugger displays the code at this address. This enables you to more easily examine the code that caused the exception. If you want to run the exception handling code, you must leave this option unchecked.

Note

This option is only activated if an SVC vector catch occurs. If an SVC vector catch is not set, then the exception handler is run as normal.

Use LDM or STM for memory access

This options controls whether or not to use Load Multiple Instructions (LDM) or Store Multiple Instructions (STM) to access target memory. You might need to set this option if you have a peripheral that is not fully compatible with the AMBA 2.0 standard, as in such cases LDM and STM might not be compatible.

Write-Through L2 Cache when in debug

This option is available if you are using an ARM11 processor.

Use this option with platforms that have a level 2 cache that interferes with debug operations. By default it is set to False, but the platform configuration files supplied for affected platforms set it to True.

Note

If you set this option for other platforms, unexpected behavior might result, and cause errors.

Show/hideNon-processor CoreSight device settings

For non-processor CoreSight devices, the following device configuration settings are available:

ARM11xx-JTAG-AP specific settings

The ARM1136JFS-JTAG-AP, ARM1156T2FS-JTAG-AP, and ARM1176JZF-JTAG-AP devices have the following CoreSight-specific controls:

JTAG-AP Port index for core

For CoreSight systems with processors connected to JTAG-AP, the port index on the JTAG-AP to which the processor is connected.

Pre-scan IR bits for Devices after the core on the JTAG-AP scanchain

The total length of the JTAG instruction registers (IRs) for devices appearing after the debugged target processor on the scan chain.

For example, if there are three devices after the processor with IR lengths of 5, 7, and 11, then set this to 23.

Post-scan IR bits for Devices before the core on the JTAG-AP scanchain

The total length of the JTAG instruction registers (IRs) for devices appearing before the debugged target processor on the scan chain.

For example, if there are two devices before the processor with IR lengths of 2 and 3, then set this value to 5.

Pre-scan DR bits for Devices after the core on the JTAG-AP scanchain

The total number of devices appearing after the debugged target processor on the scan chain.

For example, if there are three devices after the processor, then set this value to 3.

Post-scan DR bits for Devices before the core on the JTAG-AP scanchain

The total number of devices appearing before the debugged target processor on the scan chain.

For example, if there are two devices before the processor, then set this value to 2.

Fast memory download.

This control is available for those targets where the Debug Access Port (DAP) and the processor are running sufficiently fast enough to handle the data being sent to them by the debug unit. The debug unit does not have to check that each individual transaction with the DAP is successful.

Because the processor is behind the DAP, all processor accesses have to go through the DAP. As a guide, do not set this for FPGA-based targets, but only for real silicon.

If this option is set, then error checking is disabled and the user is not informed of any errors that occur. If problems are encountered when downloading images then uncheck this option to resolve them.

CoreSight AP index

The AP index of the device.

Available for all devices, except the ARMCS-DP, ARMJTAG-DP, and ARMSW-DP devices.

CoreSight base address

The base address of the CoreSight registers for the device on the AHB or APB.

Available for all devices, except the ARMCS-DP, ARMJTAG-DP, and ARMSW-DP devices.

Force ETM power up on connect

If the CoreSight ETM (CSETM) is powered down when your debugger attempts to connection to it, then power up the device.

Memory Access AP index

The index number of the AHB-AP memory bus on the DAP. The AHB-AP bus is used to perform memory operations within the CoreSight system.

Available for the ARMCS-DP, ARMJTAG-DP, and ARMSW-DP devices only.

The ARMCS-DP device represents the Debug Access Port (DAP) in a CoreSight system. This device is automatically detected when you autoconfigure a CoreSight system. However, any devices connected to the DAP are not detected. Therefore, you must read the CoreSight ROM table of the ARMCS-DP to determine the devices that are connected to the DAP.

The ARM11xx-JTAG-AP device represents the JTAG-AP in a CoreSight system. To debug CoreSight systems that have processors connected to the DAP the JTAG-AP, the debug unit must know the pre-scan and post-scan bits for JTAG operations.

Multiple devices on the JTAG scan chain are connected in series, with data flowing serially from TDI to TDO. This means that debugging a given target in the chain requires that certain pre-scan and post-scan bits are used. These bits ensure that the other devices are not affected by the data directed at the target device, and that the data is positioned correctly in the serial scan for the target device.

Show/hideSee also

Copyright © 2010-2011 ARM. All rights reserved.ARM DUI 0498D
Non-ConfidentialID071311