SourcePoint AMD Help
Table of Contents
- Using Help
- Contacting ASSET InterTech
- Introduction to SourcePoint
- SourcePoint Environment
- SourcePoint Overview
- SourcePoint Parent Window Introduction
- SourcePoint Icon Toolbar
- File Menu
- File Menu - Project Menu Item
- File Menu - Layout Menu Item
- File Menu - Program Menu Item
- File Menu - Macro Menu Item
- File Menu - Print Menu Items
- File Menu - Update Emulator Flash Menu Item
- File Menu - Program Target Device Menu Item
- File Menu - Other Menu Items
- Edit Menu
- View Menu
- Processor Menu
- Options Menu
- Options Menu - Preferences Menu Item
- Options Menu - Target Configuration Menu Item
- Options Menu - Load Target Configuration File Menu Item
- Options Menu - Save Target Configuration File Menu Item
- Options Menu - Emulator Configuration Menu Item
- Options Menu - Emulator Connection Menu Item
- Options Menu - Emulator Reset Menu Item
- Options Menu - Confidence Tests Menu Item
- Window Menu
- Help Menu
- How To -- SourcePoint Environment
- Add Emulator Connections
- Configure Custom Macro Icons
- Configure Autoloading Macros
- Display Text on the Icon Toolbar
- Edit Icon Groups to Customize Your Toolbars
- Modify a Defined Memory Region
- Refresh SourcePoint Windows
- Save a Program
- Start SourcePoint With Command Line Arguments
- Use the New Project Wizard
- Verify Emulator Network Connections
- SourcePoint Overview
- Breakpoints Window
- Code Window
- Command Window
- Command Window Overview
- Confidence Tests Window
- Descriptors Tables Window
- Devices Window
- Log Window
- Memory Window
- Page Translation Window
- Page Translation Windows Overview
- PCI Devices Window
- PCI Devices Window Overview
- How To - PCI Devices Window
- Registers Window
- Symbols Windows
- Viewpoint Window
- Watch Window
- Technical Notes
- SourcePoint Command Language
- Commands and Control Variables
- bell (beep)
- Character Functions
- cpubreak commands
- dbgbreak commands
- do while
- execution point ($)
- list, nolist
- log, nolog
- Memory Access
- print cycles
- Register Access
- softbreak, softremove, softdisable, softenable
- string [ ] (index into string)
- taskbreak, taskremove, taskdisable, taskenable
Breakpoint Types and Resources
The breakpoint types and the resources required are listed in the following table.
Data Access in SMM
Data Write in SMM
Execute in SMM
I/O Access in SMM
Hardware (Debug Register) Breakpoints
Hardware breakpoints rely on processor-specific registers to recognize events, such as instruction execution or data reads/writes at a memory or I/O address. Hardware breakpoints cause the processor to stop immediately; there is little or no "slide" for non-execution breaks (i.e., breaks occurring on Data Access, Data Write, and I/O Access break on types). Pre-fetched but unexecuted instructions do not cause the processor to stop. The code location of an execution breakpoint can be in ROM. Each processor has a maximum of four hardware breakpoints. Data values are not part of a breakpoint condition.
Hardware breakpoints can be set in the Add Breakpoint or Edit Breakpoint dialog boxes or, for execution breaks (only), from the Code window.
Note: Hardware breakpoints do not accept physical addresses.
Software breakpoints are implemented by placing a special instruction (such as a software interrupt) in memory. Software breakpoints cause the processor to stop immediately (there is no "slide"). Software breakpoints do not stop the processor on unexecuted pre-fetches.
Software breakpoints are limited to execution breaks. The location of the instruction to be executed must be writable (i.e., located in RAM). Code at the breakpoint location cannot be loaded or modified on the fly. Care must be taken to insure breakpoints are set at the first byte of an instruction.
After the Go command is issued, the instruction at the breakpoint location is replaced with a special instruction. When the processor stops, the original instruction is written back to the breakpoint location.
Note: If the processor writes a different (new) value to the breakpoint location before executing there, the breakpoint is ineffective until the processor is stopped and restarted with another Go command.
The Reset breakpoint uses a signal on the debug port to detect entry and exit from the reset state. When the exit from reset state is detected the emulator will halt the target.
The Init breakpoint stops the target when the processor encounters an Init event.
The BKPT IN breakpoint utilizes an input signal on the emulator itself to allow stopping the target via an external trigger signal. There may be a delay, or “slide”, from the BKPT IN signal edge to the time the target is stopped by the emulator.
SMM Entry and SMM Exit breakpoints stop the target when the processor is entering or exiting System Management Mode, respectively.
The Power Cycle breakpoint stops the target when it detects the target has gone from the power off state to the power on state.
The Machine Check breakpoint stops the target when a Machine Check exception occurs on the target.