6.17 On-Chip Debug
Debugging a system that contains an embedded processor involves an environment that connects high-level debugging software running on a host computer to a low-level debug interface supported by the target device. Between these levels, a debug and trace controller (DTC) facilitates communication between the host debugger and the debug support logic on the target chip.
The DTC is a combination of hardware and software that connects the host debugger to the target system. The DTC uses one or more hardware interfaces and/or protocols to convert actions dictated by the debugger user to JTAG commands and scans that execute the core hardware.
The debug software and hardware components let the user control multiple central processing unit (CPU) cores embedded in the device in a global or local manner. This environment provides:
- Synchronized global starting and stopping of multiple processors
- Starting and stopping of an individual processor
- Each processor can generate triggers that can be used to alter the execution flow of other processors
System topics include but are not limited to:
- System clocking and power-down issues
- Interconnection of multiple devices
- Trigger channels
For more information, see chapter On-chip Debug of the Device TRM.
The device deploys Texas Instrument's CTools debug technology for on-chip debug and trace support. It provides the following features:
- External debug interfaces:
- Primary debug interface - IEEE1149.1 (JTAG) or IEEE1149.7 (complementary superset of JTAG)
- Used for debugger connection
- Default mode is IEEE1149.1 but debugger can switch to IEEE1149.7 via an IEEE1149.7 adapter module
- Controls ICEPick™ (generic test access port [TAP] for dynamic TAP insertion) to allow the debugger to access several debug resources through its secondary (output) JTAG ports (for more information, see ICEPick Secondary TAPs section of the Device TRM).
- Debug (trace) port
- Can be used to export processor or system trace off-chip (to an external trace receiver)
- Can be used for cross-triggering with an external device
- Configured through debug resources manager (DRM) module instantiated in the debug subsystem
- For more information about debug (trace) port, see Debug (Trace) Port and Concurrent Debug Modes sections of the Device TRM.
- JTAG based processor debug on:
- Cortex-A15 in MPU
- C66x in DSP1
- Cortex-M4 (x2) in IPU1, IPU2
- Arm968 (x2) in IVA
- Dynamic TAP insertion
- Controlled by ICEPick
- For more information, see , Dynamic TAP Insertion.
- Power and clock management
- Debugger can get the status of the power domain associated to each TAP.
- Debugger may prevent the application software switching off the power domain.
- Application power management behavior can be preserved during debug across power transitions.
- For more information, see Power and Clock Management section of the Device TRM.
- Reset management
- Debugger can configure ICEPick to assert, block, or extend the reset of a given subsystem.
- For more information, see Reset Management section of the Device TRM.
- Cross-triggering
- Provides a way to propagate debug (trigger) events from one processor, subsystem, or module to another:
- Subsystem A can be programmed to generate a debug event, which can then be exported as a global trigger across the device.
- Subsystem B can be programmed to be sensitive to the trigger line input and to generate an action on trigger detection.
- Two global trigger lines are implemented
- Device-level cross-triggering is handled by the XTRIG (TI cross-trigger) module implemented in the debug subsystem
- Various Arm® CoreSight™ cross-trigger modules implemented to provide support for CoreSight triggers distribution
- CoreSight Cross-Trigger Interface (CS_CTI) modules
- CoreSight Cross-Trigger Matrix (CS_CTM) modules
- For more information about cross-triggering, see Cross-Triggering section of the Device TRM.
- Suspend
- Provides a way to stop a closely coupled hardware process running on a peripheral module when the host processor enters debug state
- For more information about suspend, see Suspend section of the Device TRM.
- MPU watchpoint
- Embedded in MPU subsystem
- Provides visibility on MPU to EMIF direct paths
- For more information, see MPU Memory Adaptor (MPU_MA) Watchpoint section of the Device TRM.
- Processor trace
- Cortex-A15 (MPU) and C66x (DSP) processor trace is supported
- Program trace only for MPU (no data trace)
- MPU trace supported by a CoreSight Program Trace Macrocell (CS_PTM) module
- Three exclusive trace sinks:
- CoreSight Trace Port Interface Unit (CS_TPIU) – trace export to an external trace receiver
- CTools Trace Buffer Router (CT_TBR) in system bridge mode – trace export through USB
- CT_TBR in buffer mode – trace history store into on-chip trace buffer
- For more information, see Processor Trace section of the Device TRM.
- System instrumentation (trace)
- Supported by a CTools System Trace Module (CT_STM), implementing MIPI System Trace Protocol (STP) (rev 2.0)
- Real-time software trace
- MPU software instrumentation through CoreSight STM (CS_STM) (STP2.0)
- System-on-chip (SoC) software instrumentation through CT_STM (STP2.0)
- OCP watchpoint (OCP_WP_NOC)
- OCP target traffic monitoring: OCP_WP_NOC can be configured to generate a trigger upon watchpoint match (that is, when target transaction attributes match the user-defined attributes).
- SoC events trace
- DMA transfer profiling
- Statistics collector (performance probes)
- Computes traffic statistics within a user-defined window and periodically reports to the user through the CT_STM interface
- Embedded in the L3_MAIN interconnect
- 10 instances:
- 1 instance dedicated to target (SDRAM) load monitoring
- 9 instances dedicated to master latency monitoring
- IVA instrumentation (hardware accelerator [HWA] profiling)
- Supported through a software message and system trace event (SMSET) module embedded in the IVA subsystem
- Power-management events profiling (PM instrumentation [PMI])
- Monitoring major power-management events. The PM state changes are handled as generic events and encapsulated in STP messages.
- Clock-management events profiling (CM instrumentation [CMI])
- Monitoring major clock management events. The CM state changes are handled as generic events and encapsulated in STP messages.
- Two instances, one per CM
- CM1 Instrumentation (CMI1) module mapped in the PD_CORE_AON power domain
- CM2 Instrumentation (CMI2) module mapped in the PD_CORE power domain
- For more information, see System Instrumentation section of the Device TRM.
- Performance monitoring
- Supported by subsystem counter timer module (SCTM) for IPU
- Supported by performance monitoring unit (PMU) for MPU subsystem
For more information, see chapter On-Chip Debug Support of the Device TRM.