winIDEA HelpCore-specific options
This chapter explains core specific settings. Open Hardware | CPU Options | Core. Equivalent dialog is provided for each available CPU core.
Common
Use software breakpoints
Hardware Breakpoints are already provided by the CPU. The number of hardware breakpoints is limited to eight. The advantage is that they function anywhere in the CPU space. Software Breakpoints normally cannot be used in the non-writable memory (ROM) or self-modifying code. If the option Use software breakpoints is NOT enabled, only hardware breakpoints are used for execution breakpoints.
|
Setting a Software Breakpoint means modifying flash memory. Editing flash memory during debug session is disabled on some devices. In this case software breakpoints won't work. |
|
When executing source step debug command, BlueBox uses one breakpoint. When all available hardware breakpoints are used as execution breakpoints, the debugger may fail to execute debug step. The debugger offers Reserve one breakpoint for high-level debugging option in the Debug | Debug Options | Debugging to circumvent this. By default this option is checked and the user can uncheck it anytime. |
|
Memory protection unit must not be used while debugging the application. Hardware breakpoints and instruction step cannot be used in conjunction with Memory Protection Unit. Available hardware breakpoints often prove to be insufficient. Then the debugger can use unlimited software breakpoints to work around this limitation. |
Automatically observe this core
When checked, the debugger will attach to the core on a debug session start (Reset, Download and Load Symbols). This option is checked by default.
If the core is not automatically observed from the beginning of the debug session, it is possible observing it at any time later via View | Debug | Session Explorer.
Synchronize this core
Synchronize this core when the Hardware | CPU Options | Debugging | Synchronize selected cores (stop/run) when possible option is checked.
Debug Entry
This option allows you to configure per-core startup actions. The options to configure the boot core startup can be found in the SoCs Startup page or in the Basic Session Configuration dialog.
Debug entry type
Define how to connect to the non-boot core(s). The debug session reason (Download, Reset, Attach) dictates this for the boot core:
•Non intrusive - Execution is not obstructed and the core behaves as if in a standalone operation.
•Catch - Stop the core right after initial debug connection (e.g. immediately after it is released from reset).
•Force run - Run a core right after debug session is established.
Preset PC after stopped in init
Preset the PC after a core is stopped during a debug session start. Regardless of the Debug entry type option this option is applicable only for Download and Reset, but not for Attach. Also not used during active debug session, e.g. core stops on software reset catch or low power wakeup.
•No Preset - PC is not preset.
•Entry Point - Presets the program execution point to the program entry point which must be specified in the ELF file.
•Address - Preset to the specified address in the Preset PC address field.
|
Changing the execution point causes the application to behave differently than when ran without the debugger. This shouldn't be used in normal circumstances. Use with caution after consulting Technical support. |
PC Preset address
Preset the PC for a selected address via the Browsing Variables dialog. If you are using a symbol, make sure to select it from the correct boot process.
TriCore
Reserve breakpoint pair
One of possible operation modes for each of these events is execution breakpoint mode and by default all 8 eight are used by the debugger. When any (configurable in pairs) of these is not allowed to be used by the debugger, they can be reserved through these settings.
