ARM Registers
-Registers are the register contents of the central processing unit (CPU) of the targeted device. When debugging projects on a device, only the target device registers are visible, for example the ARM registers. The ARM microprocessor has 16 general-purpose registers. THUMB has eight general-purpose registers, R0-R7, and access to the high registers, R8-R15. Note that registers R0 through R3 hold the first four words of incoming arguments. The microprocessor constructs remaining arguments in the calling function's argument build area, which does not provide space into which R0 through R3 can be spilled.
-Three registers are best left for special uses. These are:
--
-
- R13 for stack operations -
- R14 is the link register (it is used for storing return addresses in the construction of sub routines) -
- R15 is the program counter (PC) -
In most cases, the contents of all the registers can be modified. However, when debugging applications on a target device with Application TRK, you cannot change the LR, SP, and CPSR registers.
-NOTE When opening the Registers view, the list of available registers will vary depending upon the target devices being debugged.
-
Figure 1 - ARM Registers
-Related concepts
- -Related tasks
- -Related references
--
-
- View Registers -
FPU Registers
-The FPU Registers are the register contents of the floating-point unit (FPU) of the host computer. The exact listing of these registers depends on the host FPU and current build target.
-Related concepts
- -Related tasks
- -Related references
--
-
- View Registers -
General Registers
-The General Registers are the register contents of the central processing unit (CPU) of the host computer. The exact listing of these registers depends on the host CPU and current build target.
-Related concepts
- -Related tasks
- -Related references
--
-
- View Registers -
Host-specific Registers
-The Registers view also lists additional register contents for registers specific to the host. The exact listing of these registers depends on the host computer and current build target.
-Related concepts
- -Related tasks
- -Related references
--
-
- View Registers -
Registers
-Registers are the register contents of the central processing unit (CPU) of the host computer or the targeted device. When debugging projects using the emulator, only the host computer x86 registers are visible in the Registers view. When debugging projects on a device, only the target device registers are visible.
+Use the Registers view to view the general and specific registers central processing unit (CPU) of the host computer. The exact listing of these registers depends on the host CPU and current build target.
+ +General registers
+Registers are the register contents of the central processing unit (CPU) of the host computer or the targeted device. When debugging projects using the emulator, only the host computer x86 registers are visible in the Registers view. When debugging projects on a device, only the target device registers are visible.
In most cases, the contents of all the registers can be modified. However, when debugging applications on a target device with Application TRK, you cannot change the LR and SP registers.
Figure 1. Registers view with possible register types
@@ -22,6 +28,17 @@NOTE When opening the Registers view, the list of available registers will vary depending upon the target devices being debugged.
+ARM registers
+The ARM microprocessor has 16 general-purpose registers. THUMB has eight general-purpose registers, R0-R7, and access to the high registers, R8-R15. Note that registers R0 through R3 hold the first four words of incoming arguments. The microprocessor constructs remaining arguments in the calling function's argument build area, which does not provide space into which R0 through R3 can be spilled.
+Three registers are best left for special uses. These are:
+-
+
- R13 for stack operations +
- R14 is the link register (it is used for storing return addresses in the construction of sub routines) +
- R15 is the program counter (PC) +
In most cases, the contents of all the registers can be modified. However, when debugging applications on a target device with Application TRK, you cannot change the LR, SP, and CPSR registers.
+
Figure 2 - ARM Registers
Other references
- Registers view diff -r e3bac873e5c8 -r 0142fe025ce6 core/com.nokia.carbide.cpp.doc.user/html/concepts/tcf.htm --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/core/com.nokia.carbide.cpp.doc.user/html/concepts/tcf.htm Fri Aug 20 09:39:24 2010 -0500 @@ -0,0 +1,24 @@ + + + + + + +
- Environment (Eclipse)
- Debugger
- Executables -
- x86 Exceptions +
- x86 Exceptions
- Arguments (Eclipse)
- Source (Eclipse)
- Common (Eclipse) diff -r e3bac873e5c8 -r 0142fe025ce6 core/com.nokia.carbide.cpp.doc.user/html/projects/launch/emulation.htm --- a/core/com.nokia.carbide.cpp.doc.user/html/projects/launch/emulation.htm Thu Aug 19 16:56:56 2010 -0500 +++ b/core/com.nokia.carbide.cpp.doc.user/html/projects/launch/emulation.htm Fri Aug 20 09:39:24 2010 -0500 @@ -20,7 +20,7 @@
- The Environment tab (standard CDT page) defines the environment variable values to use when running or debugging a program. By default, the environment is inherited from the Eclipse runtime. You may override or append to the inherited environment.
- The Debugger tab provides common debugger options for the project.
- The Executables tab allows you to specify which executables are debugged by your project. -
- The x86 Exceptions tab lists all the x86 exceptions that the debugger can catch. +
- The x86 Exceptions tab lists all the x86 exceptions that the debugger can catch.
- The Source tab (standard CDT page) defines the location of source files used to display source when debugging an application. By default, these settings are derived from the associated project's build path. You may override these settings here.
- The Common tab (standard CDT page) defines general information about the launch configuration. You may choose to store the launch configuration in a specific file and specify which perspectives become active when the launch configuration is launched.
Target Communication Framework (TCF)
+TCF (Target Communication Framework) is a vendor-neutral, lightweight, extensible network protocol used mainly for communicating with embedded systems (targets). Its most distinguishing feature is that TCF is designed to transparently plug in value-adding servers between the tool and the target. TCF is protocol agnostic in that it does not depend on a specific transport like TCP/IP, serial, SSH tunnel, or other. It also supports auto-discovery of targets and services, so any tool can determine which services are available from the target.
+Carbide.c++ uses TCF to communicate with TRK, Trace, and other services on a target device. For example, the Carbide debugger uses TCF to communicate with the TRK remote agent to control debuggable programs running on the target. Other Carbide plug-ins can also use TCF to communicate with their specific services.
+Related tasks
+ +x86 Exceptions page
-Use the x86 Exceptions page in the Emulation launch configuration to set the x86 exceptions the debugger should catch. If you want the debugger to catch all the exceptions, enable all of the options in this page. However, if you prefer to handle only certain exceptions, enable only those options that reflect the exceptions you want to handle.
-
Figure 1 - x86 Exceptions page
-Table 1. x86 Exceptions page —items
-| Item | -Explanation | +Item | +Explanation |
|---|---|---|---|
| Exceptions to catch | -Click to enable by exception which x86 exceptions the debugger should catch. | +Stop thread on panic | +Choose one of the options below to handle panic exceptions: +
|
| Check All | -Enables catching all exceptions. | +Stop thread on software exception | +Choose one of the options below to handle software exceptions: +
|
| Clear All | -Disables catching all exceptions. | +Stop thread on hardware exception | +Choose one of the options below to handle hardware exceptions: +
|
Other references
diff -r e3bac873e5c8 -r 0142fe025ce6 core/com.nokia.carbide.cpp.doc.user/html/projects/launch/page_x86_exceptions.htm --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/core/com.nokia.carbide.cpp.doc.user/html/projects/launch/page_x86_exceptions.htm Fri Aug 20 09:39:24 2010 -0500 @@ -0,0 +1,41 @@ + + + + + + +x86 Exceptions page
+Use the x86 Exceptions page in the Emulation launch configuration to set the x86 exceptions the debugger should catch. If you want the debugger to catch all the exceptions, enable all of the options in this page. However, if you prefer to handle only certain exceptions, enable only those options that reflect the exceptions you want to handle.
+
Figure 1 - x86 Exceptions page
+Table 1. x86 Exceptions page —items
+| Item | +Explanation | +
|---|---|
| Exceptions to catch | +Click to enable by exception which x86 exceptions the debugger should catch. | +
| Check All | +Enables catching all exceptions. | +
| Clear All | +Disables catching all exceptions. | +
Other references
+ + ++ + diff -r e3bac873e5c8 -r 0142fe025ce6 core/com.nokia.carbide.cpp.doc.user/html/projects/launch/pages_overview.htm --- a/core/com.nokia.carbide.cpp.doc.user/html/projects/launch/pages_overview.htm Thu Aug 19 16:56:56 2010 -0500 +++ b/core/com.nokia.carbide.cpp.doc.user/html/projects/launch/pages_overview.htm Fri Aug 20 09:39:24 2010 -0500 @@ -19,7 +19,7 @@
Figure 2. Available remote connection trim indicator
Remote Connections view toolbar icons
The following commands appear on the toolbar within the Remote Connections view:
-| Item | Icon | Explanation |
|---|---|---|
| Toggle periodic service testing | + |
+ Toggles service testing on or off. | +
| Refresh Connections | 
@@ -69,7 +74,7 @@
|
Remote Connections view Status icons
The following status indicators appear in the Remote Connections view:
-| Item | Icon | @@ -100,8 +105,7 @@Not Accessible | 
- |
+
Cannot access the connection type within the connection setup. |
|---|
Based on the current selection, one or more of the following commands appear on the context menu when you right-click within the Remote Connections view. For example, if no connections are defined, only the New Connection command is available on the context menu.
Figure 3 - Remote Connections context menu
-| Item | Icon | diff -r e3bac873e5c8 -r 0142fe025ce6 core/com.nokia.carbide.cpp.doc.user/html/reference/view_carbide_portal.htm --- a/core/com.nokia.carbide.cpp.doc.user/html/reference/view_carbide_portal.htm Thu Aug 19 16:56:56 2010 -0500 +++ b/core/com.nokia.carbide.cpp.doc.user/html/reference/view_carbide_portal.htm Fri Aug 20 09:39:24 2010 -0500 @@ -4,12 +4,12 @@ -
|---|
(Show Overview) icon to show an information popup with additional information on the selected plug-in.
| Button | +Icon | +Function | +
|---|---|---|
Refresh data |
+  |
+ Click this button to force a refresh of data in the view. Use the Carbide.c++ Debugger preference panel Time interval for auto-refreshing OS View option to control the automatic refreshing of data. |
+
Enable/disable auto-refresh |
+  |
+ Click this button to turn on/off auto refresh of data. |
+
Debug process or thread |
+  |
+ Click the Debug button to attach to the process and debug the selected process or thread. Or right-click an item and choose Debug. This applies to both TRK (run mode) and TCF (stop mode). + |
+
Properties |
+  |
+ Click this button to show properties of currently selected item in the Properties view. Or right-click an item and choose Properties. |
+
Timer |
+  |
+ Click this button to define the time interval for auto-refreshing data. This applies to run mode debugging only. |
+
| Collapse All | + |
+ Click the Collaps All command to collapse all of the currently elements in the view. | +
Processes
+The Processes tab (Figure 2) provides a flat list of corresponding kernel objects. +Click a column title to sort the list by the title attribute in alternating ascending and descending order. For example, you may choose to sort the process list by Name, ID, or by Priority.
+
Figure 2. Processes Pane of Symbian OS View
+The process(es) being debugged will be shown in bold font. You can debug (attach debugger to) any process in the Processes tab by selecting it and clicking the "Debug" button or just by double clicking on it. In that case a new process item will show up in the Debug View if the process is not being debugged. Otherwise, you will get a message saying it's already under debug.
+Threads
+The Threads tab (Figure 3) provides a flat list of corresponding kernel objects. The list will display “sortable” attributes of that type of object in columns. The “sortable attribute” means you can sort the list by that attribute. For example, you may want to sort the list by the owning process name. Sort the list of any column by clicking on the column header. The thread(s) being debugged will be shown in bold font.
+NOTE You can debug (attach debugger to) any thread in the Thread tab by double clicking on it or selecting it and clicking the Debug button. In that case, a new thread item will show up in Debug view if the thread is not being debugged.
+
Figure 3. Threads Pane of Symbian OS View
+Chunks
+Chunks are an area of contiguous linear memory. It is the unit of memory allocation where a region of RAM is mapped into contiguous logical addresses. Chunks are allocated during boot for such things as the Kernel's data and stack.
+The Chunks tab (Figure 4) provides a flat list of corresponding kernel objects. The list will display “sortable” attributes of that type of object in columns. The “sortable attribute” means you can sort the list by that attribute. For example, you may want to sort the list by the owning process name. Sort the list of any column by clicking on the column header.
+NOTE Chunks data is not available during TRK debugging.
+
Figure 4. Chunks Pane of Symbian OS View
+Libraries Tab
+The Libraries pane (Figure 5) in the Symbian OS view provides information on libraries in the Symbian OS residing on the target.
+NOTE Library data is not available during TRK debugging.
+
Figure 5. Libraries Pane of Symbian OS View
+Attaching to a Process
+If you double click on a thread item in the Thread tab, or right-click and choose Debug, the owning process of the thread will be attached. The thread with an attached process will appear in bold. You can also select a thread and click the bug icon in the Symbian OS Data toolbar. You can also view properties for the attached process by clicking the "Show properties of the selected item" icon () in the Symbian OS Data toolbar or right-click the thread and choose Properties.
+NOTE If an executable is not part of a project in the workspace use the Executables view to import an executable to make it visible to the debugger. Once included in the Executables list, the symbolics for that executable can be loaded and breakpoints resolved and hit. Open a source file in an editor view or use the Breakpoints view to verify that the executable breakpoints have been resolved.
+IMPORTANT In stop mode debugging when debugging multiple processes at the same time, selecting a process in the Debug pane and clicking Terminate disconnects the attached process on the board, leaving all other processes running. It does not terminate the debug session. However, if there is only one debug process when you click Terminate the CPU is suspended until the next debug session.
+WARNING Detaching from a system process or any process not initiated by the program you are attempting to debug may cause the device to stop working, forcing a restart of the device.
+
Other references
+ + + + + diff -r e3bac873e5c8 -r 0142fe025ce6 core/com.nokia.carbide.cpp.doc.user/html/reference/view_sym_os_data_process.htm --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/core/com.nokia.carbide.cpp.doc.user/html/reference/view_sym_os_data_process.htm Fri Aug 20 09:39:24 2010 -0500 @@ -0,0 +1,37 @@ + + + + + + +Symbian OS Data view: Process
+The 
Symbian OS Data view displays the processes and threads for the suspended debug session based on the selection in the Debug view. Read-only data is displayed for ARM build configurations. Data to be viewed includes:
+
Processes
+The Processes tab (Figure 2) provides a flat list of corresponding kernel objects. +Click a column title to sort the list by the title attribute in alternating ascending and descending order. For example, you may choose to sort the process list by Name, ID, or by Priority.
+
Figure 2. Processes Pane of Symbian OS view
+The process(es) being debugged will be shown in bold font. You can debug (attach debugger to) any process in the Processes tab by selecting it and clicking the "Debug" button or just by double clicking on it. In that case a new process item will show up in the Debug View if the process is not being debugged. Otherwise, you will get a message saying it's already under debug.
+Other references
+ + + + + diff -r e3bac873e5c8 -r 0142fe025ce6 core/com.nokia.carbide.cpp.doc.user/html/reference/view_sym_os_data_threads.htm --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/core/com.nokia.carbide.cpp.doc.user/html/reference/view_sym_os_data_threads.htm Fri Aug 20 09:39:24 2010 -0500 @@ -0,0 +1,36 @@ + + + + + + +Symbian OS Data view: Threads
+The Symbian OS Data view displays the processes and threads for the suspended debug session based on the selection in the Debug view. Read-only data is displayed for ARM build configurations. Data to be viewed includes:
+
Threads
+The Threads tab (Figure 3) provides a flat list of corresponding kernel objects. The list will display “sortable” attributes of that type of object in columns. The “sortable attribute” means you can sort the list by that attribute. For example, you may want to sort the list by the owning process name. Sort the list of any column by clicking on the column header. The thread(s) being debugged will be shown in bold font.
+NOTE You can debug (attach debugger to) any thread in the Thread tab by double clicking on it or selecting it and clicking the Debug button. In that case, a new thread item will show up in Debug view if the thread is not being debugged.
+
Figure 3. Threads Pane of Symbian OS view
+Other references
+ + + + + diff -r e3bac873e5c8 -r 0142fe025ce6 core/com.nokia.carbide.cpp.doc.user/html/tasks/debugger/soft_attach_debug.htm --- a/core/com.nokia.carbide.cpp.doc.user/html/tasks/debugger/soft_attach_debug.htm Thu Aug 19 16:56:56 2010 -0500 +++ b/core/com.nokia.carbide.cpp.doc.user/html/tasks/debugger/soft_attach_debug.htm Fri Aug 20 09:39:24 2010 -0500 @@ -74,18 +74,9 @@- Enable the "Open launch configuration for additional customization of launch settings" option -
- Click Finish +
- Click Finish
-
-
- Enable the "View messages between Carbide and Trace32" -
- Click Debug -
If the View messages between Carbide and Trace32 option is enabled, the Console view will show the communications between the debugger and the hardware (Figure 1). If you do not see the messages, verify that the Trace32 Communications Log is the active log view.
-
Figure 1. Debugger log showing .cmm file being used to initialize hardware
Figure 2. Debugger stopping at a random address using soft attach
diff -r e3bac873e5c8 -r 0142fe025ce6 core/com.nokia.carbide.cpp.doc.user/html/tasks/debugger/stop_mode_debug.htm --- a/core/com.nokia.carbide.cpp.doc.user/html/tasks/debugger/stop_mode_debug.htm Thu Aug 19 16:56:56 2010 -0500 +++ b/core/com.nokia.carbide.cpp.doc.user/html/tasks/debugger/stop_mode_debug.htm Fri Aug 20 09:39:24 2010 -0500 @@ -15,7 +15,7 @@With stop mode debugging you can use the Carbide.c++ IDE and a JTAG interface to communicate between the debugger and a board to debug any target type within the Symbian OS.
@@ -28,7 +28,6 @@Related Tasks
diff -r e3bac873e5c8 -r 0142fe025ce6 core/com.nokia.carbide.cpp.doc.user/html/tasks/debugger/stop_mode_debug_jtag.htm --- a/core/com.nokia.carbide.cpp.doc.user/html/tasks/debugger/stop_mode_debug_jtag.htm Thu Aug 19 16:56:56 2010 -0500 +++ b/core/com.nokia.carbide.cpp.doc.user/html/tasks/debugger/stop_mode_debug_jtag.htm Fri Aug 20 09:39:24 2010 -0500 @@ -1,49 +1,49 @@ - - - - - -Installing JTAG
-Install the JTAG Software
-Using Lauterbach Hardware
--
-
- Program Lauterbach with Proper License -
- Run the Trace32 Installer
-
-
-
- Run the Setup.bat file. During installation select the following options:
- Product Type: In-Circuit Debugger
- ICD interface Type: USB Interface
- Selection of license for new software: License key not necessary
- CPU selection: ICD ARM7 ARM9 ARM10 ARM11 ICD XSCALE
-
- - Run the Setup.bat file. During installation select the following options:
- Install the USB Drivers -
- Place a Trace32 CD into the host machine. -
- Plug in the USB connector from the Lauterbach into the host machine. -
- Once the host machine detects the connection, install the drivers from the CD. -
- Copy Trace32 License File to T32 Folder -
- Copy Trace32 Configuration File -
- Set up the Board -
You will need a Trace32 (Lauterbach), a USB cable, and a Lauterbach power supply. You will need to program the Lauterbach with licenses for the particular processors you will be targeting.
-Older Lauterbachs have Xscale for Lubbock and ARM9 for H2/Renesas licenses installed on them already. Newer Lauterbachs should have ARM9 for H2/Renesas and ARM11 for H4 licenses installed on them already. If you don’t have the proper license installed on the Lauterbach for the processor you want to work with, you will receive an error when launching a debug session.
--
-
The newer Lauterbachs require a license file in the T32 folder. Copy the trace32 license file called license.t32 to your C:\T32 folder.
- -For H4 board: Copy the trace32 configuration file for the non-ARM11 processor, called config_arm11.t32, to your C:\T32 folder. You can also modify the default config_arm11.t32 file. This file needs to be modified to specify the port number and also enable T32 to support debugger commands outside T32. Carbide.c++ provides specific T32 config files in the support folder. The default config file will be called carbideconfig.t32.
-Power up the board. You should now be able to download the image.
-Related Tasks
- - - - + + + + + +Installing JTAG
+Install the JTAG Software
+Using Lauterbach Hardware
+-
+
- Program Lauterbach with Proper License +
- Run the Trace32 Installer
+
-
+
- Run the Setup.bat file. During installation select the following options:
+ Product Type: In-Circuit Debugger
+ ICD interface Type: USB Interface
+ Selection of license for new software: License key not necessary
+ CPU selection: ICD ARM7 ARM9 ARM10 ARM11 ICD XSCALE
+
+ - Run the Setup.bat file. During installation select the following options:
- Install the USB Drivers +
- Place a Trace32 CD into the host machine. +
- Plug in the USB connector from the Lauterbach into the host machine. +
- Once the host machine detects the connection, install the drivers from the CD. +
- Copy Trace32 License File to T32 Folder +
- Copy Trace32 Configuration File +
- Set up the Board +
You will need a Lauterbach, a USB cable, and a Lauterbach power supply. You will need to program the Lauterbach with licenses for the particular processors you will be targeting.
+Older Lauterbachs have Xscale for Lubbock and ARM9 for H2/Renesas licenses installed on them already. Newer Lauterbachs should have ARM9 for H2/Renesas and ARM11 for H4 licenses installed on them already. If you don’t have the proper license installed on the Lauterbach for the processor you want to work with, you will receive an error when launching a debug session.
+-
+
The newer Lauterbachs require a license file in the T32 folder. Copy the trace32 license file called license.t32 to your C:\T32 folder.
+ +For H4 board: Copy the trace32 configuration file for the non-ARM11 processor, called config_arm11.t32, to your C:\T32 folder. You can also modify the default config_arm11.t32 file. This file needs to be modified to specify the port number and also enable T32 to support debugger commands outside T32. Carbide.c++ provides specific T32 config files in the support folder. The default config file will be called carbideconfig.t32.
+Power up the board. You should now be able to download the image.
+Related Tasks
+ + + + diff -r e3bac873e5c8 -r 0142fe025ce6 core/com.nokia.carbide.cpp.doc.user/html/tasks/debugger/stop_mode_debug_launchcfg.htm --- a/core/com.nokia.carbide.cpp.doc.user/html/tasks/debugger/stop_mode_debug_launchcfg.htm Thu Aug 19 16:56:56 2010 -0500 +++ b/core/com.nokia.carbide.cpp.doc.user/html/tasks/debugger/stop_mode_debug_launchcfg.htm Fri Aug 20 09:39:24 2010 -0500 @@ -5,17 +5,6 @@Defining a Stop Mode Debug Configuration
@@ -46,7 +35,7 @@Click Debug after all the preference panels have been set. The Debug window closes and the Carbide.c++ debugger begins a debugging session using the new configuration. The next time you click the Debug icon, this debug launch configuration is used to start a debug session.
The Main pane shown in Figure 2 defines the project to be launched on the target device. Table 1 defines the fields.
-
Figure 2 - Debug Window - Main Tab
Table 1. Main pane
| Explanation | |||
|---|---|---|---|
| Project | +Project | The project to associate with this debug launch configuration. Click Browse to select a different project. |
|
| Executable | +Executable | This is the name of the executable that is linked to the project. Click Browse to select a different executable. | Explanation |
| - - + |
Trace32 Executable |
Specify the path to the Trace32 executable. The default path assumes that the Trace32 executable is installed in the default location: C:\T32\T32marm.exe. |
|
| - - + |
Trace32 Configuration File |
Specify the path to the config.t32 file or other custom configuration file. The default path assumes that the Trace32 configuration file is installed in the default location: C:\T32\config.t32.
For arm11 processors copy the trace32 configuration file for non-ARM11 processor (config_arm11.t32) to your C:\T32 folder and specify it in the edit box. @@ -95,20 +80,14 @@ PORT=20000 |
|
| - - + |
- Trace32 Initialization Script |
Specify the path to the initialization cmm file. This script will be run in T32 after connecting to T32. You can specify your own scripts for the targets used. |
|
| - - + |
- View messages between Carbide and Trace32 |
Enable to log communications with Trace32 to the console window. | Explanation |
| Break at entry point | +Break at entry point | When checked, break at the specified entry point entered in the text field. For .EXE targets, the default entry point is set to E32Main. By default, the Break at entry point option is unchecked for all other target types. |
|
| Target Processor | +Target Processor | A drop down with a list of all supported processors. The process selection should help in determining the memory model. This will in turn help determine the base address and the offsets for the Symbian OS kernel aware information. | |
|
-
-
-
- Target Initialization File |
+ Check this box to have the debugger run an initialization script when the debug session starts. For example, if a target device requires initialization for the debugger to be able to read and write memory or registers, you can specify an initialization script here. Click Browse to select a script file using a standard file selection dialog box. When using T32, most of the initialization is done in the CMM script file. With other debug protocols you specify the initialization file, which can be run after connecting to the target. |
||
|
-
-
-
- Memory Configuration File |
+ Controls whether the debugger uses a memory configuration file when a debug session starts. The Carbide debugger uses this configuration file to know which memory is accessible, readable, and writable on the target. | ||
|
-
-
-
- Reset target at the start of each debug session |
+ Forces the Carbide IDE to reset the target at the start of each debug session. This ensures that the debugging session uses the most up-to-date program code. | ||
Default Instructon Set |
+ Default Instructon Set |
Specifies the default instruction set to use if the debugger cannot determine the processor mode in order to set breakpoints and to disassemble code. This can happen at addresses for which we have no symbolic information. The debugger uses the mode when setting breakpoints and disassembling code. The options are:
Explanation |
|
| - - + |
- Start Address |
Enter the physical address in memory where the Symbian OS start code begins execution. This address is target-specific. The address should be in hexadecimal format with the 0x prefix. For example, 0x8000000 is a valid entry. NOTE The address entered in this field must match the start address specified in the source code used to build the Symbian OS ROM image to be debugged. The Start address must match the Download address. |
|
| - - + |
- Debug from Start address |
Select this option to have the debugger halt the program at the address specified in Start Address once the target initialization is done and the OS is downloaded; if the user has chosen to download the OS. You can then step through start-up code or run the target in bare-board mode. | |
| - - + |
- - Run from start address |
Select this option to have the debugger start the code at the address specified in Start Address once the target initialization is done. If you have breakpoints set, the debugger stops at the first breakpoint encountered. You can click the Break button to halt the device. | |
| - - + |
- - - Symbian ROM Log file |
Check the Parse ROM Log File option and specify the information that the debugger needs in order to show detailed stack information, set breakpoints, and show source level debugging information for ROM images. In the first text field, browse to or enter the full path and name of the log file that corresponds to the ROM image on the target device. This log file is generated by default when the ROM image is built. | |
| - - + |
- - Symbian OS Kit EPOC32 Directory |
Specifies the epoc32 directory in which the ROM image and log files are stored. Since the log file may not contain full paths to the ROM components on the host PC, you need to enter this epoc32 directory. NOTE Always include the epoc32 folder in this path. |
|
| - - + |
- - - - Log unresolved modules |
Check this box to have the debugger output a list of components from the specified ROMBUILD log file that do not have debugger symbolic information. The list is displayed in the debugger console window at the beginning of the debug session. NOTE You cannot perform source-level debugging on components that do not include symbolic information. |
|
|
-
-
- - - - - - Debug non-XIP Executables |
+
+ Debug non-XIP Executables |
Check this box to debug a project, or a dynamically loaded module, that is loaded from NAND-Flash or other removable media (MMC, memory stick, etc.) at run time and executed in RAM. Use this option to debug modules that work fine when executed in place as part of the ROM image, but sometimes fail when placed in NAND-Flash or other removable media. NOTE Selecting this option will affect debugging performance. When the debugger needs to load a module (DLL, EXE, etc.) it will stop the target, read information from it, then restart it. |
|
|
-
-
- - - - - Symbian ROM Image |
+
+ Symbian ROM Image |
Controls the logging of communication with Trace32. Enable to log communications with Trace32 to the console window. | |
| - - + |
Download Address (hex) |
Enter the physical address in memory at which the debugger should place the ROM image. This address is target-specific. The address should be in hexadecimal format with the 0x prefix. For example, 0x000FFF00 is a valid entry. NOTE The address entered in this field must match the download address specified in the source code used to build the Symbian OS ROM image to be debugged. If you leave this field blank, the debugger does not download the ROM image to the device at the beginning of the debug session. The Download address must match the Start address. |
|
| - - + |
Ask for download at the start of each debug session |
Check this box to have the debugger display a dialog box at the beginning of every debug session that lets you choose whether or not you want the debugger to download the ROM image to the device. |