SPRUIY2 November   2024 F29H850TU , F29H859TU-Q1

 

  1.   1
  2.   Read This First
    1.     About This Manual
    2.     Related Documentation from Texas Instruments
    3.     Glossary
    4.     Support Resources
    5.     Trademarks
  3. 1Architecture Overview
    1. 1.1 Introduction to the CPU
    2. 1.2 Data Type
    3. 1.3 C29x CPU System Architecture
      1. 1.3.1 Emulation Logic
      2. 1.3.2 CPU Interface Buses
    4. 1.4 Memory Map
  4. 2Central Processing Unit (CPU)
    1. 2.1 C29x CPU Architecture
      1. 2.1.1 Features
      2. 2.1.2 Block Diagram
    2. 2.2 CPU Registers
      1. 2.2.1 Addressing Registers (Ax/XAx)
      2. 2.2.2 Fixed-Point Registers (Dx/XDx)
      3. 2.2.3 Floating Point Register (Mx/XMx)
      4. 2.2.4 Program Counter (PC)
      5. 2.2.5 Return Program Counter (RPC)
      6. 2.2.6 Status Registers
        1. 2.2.6.1 Interrupt Status Register (ISTS)
        2. 2.2.6.2 Decode Phase Status Register (DSTS)
        3. 2.2.6.3 Execute Phase Status Register (ESTS)
    3. 2.3 Instruction Packing
      1. 2.3.1 Standalone Instructions and Restrictions
      2. 2.3.2 Instruction Timeout
    4. 2.4 Stacks
      1. 2.4.1 Software Stack
      2. 2.4.2 Protected Call Stack
      3. 2.4.3 Real Time Interrupt / NMI Stack
  5. 3Interrupts
    1. 3.1 CPU Interrupts Architecture Block Diagram
    2. 3.2 RESET, NMI, RTINT, and INT
      1. 3.2.1 RESET (CPU reset)
      2. 3.2.2 NMI (Non-Maskable Interrupt)
      3. 3.2.3 RTINT (Real Time Interrupt)
      4. 3.2.4 INT (Low-Priority Interrupt)
    3. 3.3 Conditions Blocking Interrupts
      1. 3.3.1 ATOMIC Counter
    4. 3.4 CPU Interrupt Control Registers
      1. 3.4.1 Interrupt Status Register (ISTS)
      2. 3.4.2 Decode Phase Status Register (DSTS)
      3. 3.4.3 Interrupt-Related Stack Registers
    5. 3.5 Interrupt Nesting
      1. 3.5.1 Interrupt Nesting Example Diagram
    6. 3.6 Security
      1. 3.6.1 Overview
      2. 3.6.2 LINK
      3. 3.6.3 STACK
      4. 3.6.4 ZONE
  6. 4Pipeline
    1. 4.1  Introduction
    2. 4.2  Decoupled Pipeline Phases
    3. 4.3  Dual Instruction Prefetch Buffers
    4. 4.4  Pipeline Advancement and Stalls
    5. 4.5  Pipeline Hazards and Protection Mechanisms
    6. 4.6  Register Updates and Corresponding Pipeline Phases
    7. 4.7  Register Reads and Writes During Normal Operation
    8. 4.8  D2 Read Protection
    9. 4.9  E1 Read Protection
    10. 4.10 WAW Protection
    11. 4.11 Protection During Interrupt
  7. 5Addressing Modes
    1. 5.1 Addressing Modes Overview
      1. 5.1.1 Documentation and Implementation
      2. 5.1.2 List of Addressing Mode Types
        1. 5.1.2.1 Additional Types of Addressing
      3. 5.1.3 Addressing Modes Summarized
    2. 5.2 Addressing Mode Fields
      1. 5.2.1 ADDR1 Field
      2. 5.2.2 ADDR2 Field
      3. 5.2.3 ADDR3 Field
      4. 5.2.4 DIRM Field
      5. 5.2.5 Additional Fields
    3. 5.3 Alignment and Pipeline Considerations
      1. 5.3.1 Alignment
      2. 5.3.2 Pipeline Considerations
    4. 5.4 Types of Addressing Modes
      1. 5.4.1 Direct Addressing
      2. 5.4.2 Pointer Addressing
        1. 5.4.2.1 Pointer Addressing with #Immediate Offset
        2. 5.4.2.2 Pointer Addressing with Pointer Offset
        3. 5.4.2.3 Pointer Addressing with #Immediate Increment/Decrement
        4. 5.4.2.4 Pointer Addressing with Pointer Increment/Decrement
      3. 5.4.3 Stack Addressing
        1. 5.4.3.1 Allocating and De-allocating Stack Space
      4. 5.4.4 Circular Addressing Instruction
      5. 5.4.5 Bit Reversed Addressing Instruction
  8. 6Safety and Security Unit (SSU)
    1. 6.1 SSU Overview
    2. 6.2 Links and Task Isolation
    3. 6.3 Sharing Data Outside Task Isolation Boundary
    4. 6.4 Protected Call and Return
  9. 7Emulation
    1. 7.1 Overview of Emulation Features
    2. 7.2 Debug Terminology
    3. 7.3 Debug Interface
    4. 7.4 Execution Control Mode
    5. 7.5 Breakpoints, Watchpoints, and Counters
      1. 7.5.1 Software Breakpoint
      2. 7.5.2 Hardware Debugging Resources
        1. 7.5.2.1 Hardware Breakpoint
        2. 7.5.2.2 Hardware Watchpoint
        3. 7.5.2.3 Benchmark Counters
      3. 7.5.3 PC Trace
  10. 8Revision History

7.4 Execution Control Mode

The C29x CPU supports stop mode debug execution control mode. Stop mode provides complete control of program execution, allowing for the disabling of all interrupts. In this execution mode program execution is suspended at break events, such as occurrence of software breakpoint instructions or specified program-space or data-space accesses.

Stop mode causes break events, such as breakpoints and watchpoints, to suspend program execution at the next interrupt boundary (which is usually identical to the next instruction boundary). When execution is suspended, all interrupts (including NMI and RS) are ignored until the CPU receives a directive to run code again.

In stop mode, the CPU can operate in the following execution states:

  • Debug-halt state: In the stop mode debug-halt state, the CPU is halted. This state is entered when the CPU is running with debug enabled and encounters a break event such as a breakpoint or watchpoint, hardware trigger or user initiated halt request.
    • User Halt: User issues a Debug-halt request from the debugger.
    • Hardware Breakpoint : ERAD can be setup to generate hardware breakpoints on a specified Program Address. This causes the CPU to go to a halted condition, if the instruction packet at the designated address is about to enter the Decode2 phase of the CPU pipeline.
    • Software breakpoint : This is setup by the debugger by putting the EMUSTOP0 instruction at a desired program address. This causes the CPU to go to a halted condition, if the EMUSTOP0 is about to enter the Decode2 phase of the CPU pipeline.
    • Watchpoint : ERAD can be configured to generate a watchpoint when the CPU makes a designated data memory access or some other system condition or a combination of these. Once this defined event occurs, ERAD generates a Watchpoint request to the Debug controller that can cause the CPU to halt.
    • External Triggers: Triggers at the device level coming from various sources outside the CPU can be configured to make a HALT request to the CPU and can also cause the CPU to HALT. This is typically used when halting of one CPU requires triggering the halt of another CPU when multiple CPUs are being controlled by the Debugger.

    In the debug-halt state, since the CPU is halted, the CPU cannot service any interrupts, including NMI and RS (reset). When multiple instances of the same interrupt occur without the first instance being serviced when the CPU is in halted debug state, the later instances are lost.

  • Single-Step state: This state is entered when the user indicates to the debugger to execute a single instruction packet. The CPU executes the single instruction packet pointed to by the PC and then returns to the debug-halt state (the CPU executes from one interrupt boundary to the next). The CPU is only in the single-instruction state until that single instruction is done. If an interrupt occurs in this state, the command used to enter this state determines whether that interrupt can be serviced. If DINT is set, the CPU can service the interrupt;.if DINT is not set, the CPU can not service interrupts even if the interrupt is NMI or RS.
  • Run state: This state is entered from a halted condition when user issues a run command from the debugger interface while stop debug mode is enabled. The CPU executes instructions until a debugger command or a debug event returns the CPU to the debug-halt state. The CPU can service all interrupts in this state. When an interrupt occurs simultaneously with a debug event, the debug event has priority; however, if interrupt processing began before the debug event occurred, the debug event cannot be processed until the interrupt service routine begins.
  • Free-run: This state is entered from a halted condition when user issues a run command from the debugger interface after disabling stop mode debug mode. The CPU resumes execution and ignores further debug events like breakpoints, watchpoints and triggers and continues execution as if the debugger is no longer connected.
  • Synchronous Run: This is merely an extension of the basic run state. Based on the configuration, the debug controller can be configured to receive a run request such that the CPU starts the actual run only on a certain global synchronization signal going active. This method is used when starting execution simultaneously on multiple CPUs being controlled by the debugger.