• Menu
  • Product
  • Email
  • PDF
  • Order now
  • Debugging Sitara AM2x Microcontrollers

    • SPRAD28 October   2022 AM2431 , AM2432 , AM2434 , AM2631 , AM2631-Q1 , AM2632 , AM2632-Q1 , AM2634 , AM2634-Q1 , AM263P4 , AM263P4-Q1 , AM26C31 , AM26C31-EP , AM26C31M , AM26C32 , AM26C32-EP , AM26C32C , AM26C32M , AM26LS31 , AM26LS31M , AM26LS32A , AM26LS32AC , AM26LS32AM , AM26LS33A , AM26LS33A-SP , AM26LS33AM , AM26LV31 , AM26LV31E , AM26LV31E-EP , AM26LV32 , AM26LV32E , AM26LV32E-EP , AM26S10 , AM2732 , AM2732-Q1

       

  • CONTENTS
  • SEARCH
  • Debugging Sitara AM2x Microcontrollers
  1.   Abstract
  2.   Trademarks
  3. 1 Building for Debug
    1. 1.1 Disable Code Optimization
    2. 1.2 Using the Debug SDK Libraries
  4. 2 Code Composer Studio Stop-Mode Debugging
    1. 2.1 Configuring the Debugger
    2. 2.2 Breakpoints and Watchpoints
      1. 2.2.1 Software Breakpoints
      2. 2.2.2 Hardware Breakpoints
      3. 2.2.3 Watchpoints
    3. 2.3 Inspecting Device Registers
    4. 2.4 Inspecting Disassembly
  5. 3 Debug Logging
    1. 3.1 Logging Methods
    2. 3.2 Log Zones
    3. 3.3 Asserts
    4. 3.4 Example Usage
  6. 4 Multi-Core Debug
    1. 4.1 Grouping Cores
      1. 4.1.1 Fixed Group
      2. 4.1.2 Hiding Cores
    2. 4.2 Using Multiple Workbench Windows
    3. 4.3 Global Breakpoints
  7. 5 Debugging Arm Cortex-R5 Exceptions
    1. 5.1 Exception Priority Order
    2. 5.2 Aborts
      1. 5.2.1 Data Aborts
        1. 5.2.1.1 Alignment
        2. 5.2.1.2 Background Aborts
        3. 5.2.1.3 Permission
        4. 5.2.1.4 Synchronous/Asynchronous External
        5. 5.2.1.5 Synchronous/Asynchronous ECC
      2. 5.2.2 Synchronous/Asynchronous Aborts
        1. 5.2.2.1 Changing an Asynchronous Abort to a Synchronous Abort
        2. 5.2.2.2 Synchronous Abort
        3. 5.2.2.3 Asynchronous Abort
        4. 5.2.2.4 Debugging Asynchronous Abort
      3. 5.2.3 Prefetch Abort
        1. 5.2.3.1 Possible Reasons for Prefetch Abort
        2. 5.2.3.2 Handling Prefetch Abort Exception
      4. 5.2.4 Undefined Instruction
        1. 5.2.4.1 Possible Reasons for Undefined Instruction Exception
        2. 5.2.4.2 Handling Undefined Instruction Exception
    3. 5.3 Fetching Core Registers Inside an Abort Handler
  8. 6 Debugging Arm Cortex-M4 Exceptions
    1. 6.1 Exception Entry and Exit Sequence
      1. 6.1.1 Entry Sequence
      2. 6.1.2 Exception Exit Sequence
      3. 6.1.3 Decoding EXC_RETURN Value
    2. 6.2 Faults Handling
      1. 6.2.1 There are 15 System Exceptions by Arm Cortex M Processors
        1. 6.2.1.1 Causes of Faults
      2. 6.2.2 HardFault Exception
        1. 6.2.2.1 Causes of HardFault Exception
      3. 6.2.3 Configurable Fault Exceptions
        1. 6.2.3.1 Mem Manage Fault Exception
        2. 6.2.3.2 BusFault Exception
        3. 6.2.3.3 Usage Fault Exception
      4. 6.2.4 Control Registers
        1. 6.2.4.1 SHP - System Handler Priority Register
      5. 6.2.5 Status Registers
        1. 6.2.5.1 Undefined Instruction Handling Example
        2. 6.2.5.2 Invalid State Handling Example
      6. 6.2.6 Printing the Stack Frame
  9. 7 Debugging Memory
    1. 7.1 Viewing Device Memory
    2. 7.2 Linker Command File (linker.cmd)
      1. 7.2.1 The Memory Directive
      2. 7.2.2 The Sections Directive
    3. 7.3 Stack Overflow
      1. 7.3.1 -fstack-protector
      2. 7.3.2 -fstack-protector-strong
      3. 7.3.3 -fstack-protector-all
      4. 7.3.4 Enabling Stack Smashing Detection
      5. 7.3.5 Enabling Stack Smashing Detection
    4. 7.4 Variables and Expressions View in CCS
    5. 7.5 Understanding Your Application's Memory Allocation
    6. 7.6 FreeRTOS ROV
  10. 8 Debugging Boot
    1. 8.1 ROM Boot
    2. 8.2 SBL Boot
    3. 8.3 GEL Files
      1. 8.3.1 Debugging Init Code
        1. 8.3.1.1 Disable Auto-Run to Main
  11. 9 Debugging Real-Time Control Loops
    1. 9.1 Trace
      1. 9.1.1 Processor / Core Trace
      2. 9.1.2 How to Use CCS to Capture Trace Data on an AM243x
    2. 9.2 Code Profile / Coverage
      1. 9.2.1 CCS Count Event
    3. 9.3 Real-Time UART Monitor
      1. 9.3.1 Confirm CCS Features
      2. 9.3.2 Create Target Configuration File
      3. 9.3.3 Add Serial Command Monitor Software
      4. 9.3.4 Launch Real Time Debug
  12. 10E2E Support Forums
  13. IMPORTANT NOTICE
search No matches found.
  • Full reading width
    • Full reading width
    • Comfortable reading width
    • Expanded reading width
  • Card for each section
  • Card with all content

 

APPLICATION NOTE

Debugging Sitara AM2x Microcontrollers

Abstract

This application note covers the various debugging tools and techniques available to users developing applications with Sitara™ AM2x microcontrollers (MCUs).

Trademarks

Sitara™ and Code Composer Studio™ are trademarks of Texas Instruments.

Arm® is a registered trademark of tm.

Cortex® is a registered trademark of Arm Limited (or its subsidiaries) in the US and/or elsewhere.

All trademarks are the property of their respective owners.

1 Building for Debug

This section covers how to build your application for optimal debugging.

1.1 Disable Code Optimization

Before debugging your code, disable any compiler optimization. When compiler optimization is enabled, stepping through code can become unpredictable, and breakpoints sometimes cannot be set to the exact line in the C source code. This is because the optimizer can condense code and impact the correlation between the assembly instruction and the C source. Due to this, the recommendation is to turn off compiler optimization when stepping through code.

To disable compiler optimization, go to your project's properties > Build > Arm Compiler > Optimization, and set the optimization level to none or 0. If building with makefiles, this can be done by modifying the makefiles directly. For MCU+ SDK, this is typically done within the submodule's makefile (not the top-level makefile).

1.2 Using the Debug SDK Libraries

The SDK provides two versions of libs: "Debug" and "Release". The "Debug" version is built with optimization disabled, while the "Release" version is built with optimization enabled. The recommendation is to use the "Debug" version of an SDK lib when debugging.

The SDK libs follow the naming convention: "{library name}.{device}.{core}.{compiler}.{version}.lib"

For example, "drivers.am243x.m4f.ti-arm-clang.release.lib" implies the following:

  • Library Name: Drivers Library
  • Device: AM243x MCU
  • Core: Arm® Cortex®-M4F Core
  • Compiler: TI Arm Clang Compiler
  • Version: Release

The libraries that are linked to your project can be configured in the project properties under Build > Arm Linker > File Search Path.

2 Code Composer Studio Stop-Mode Debugging

This section covers the key debug features offered by Code Composer Studio™ (CCS) for stop-mode debugging. Stop-mode debugging refers to debugging where stopping or halting the core is involved, as opposed to real-time debugging, which involves debugging without stopping the core (real-time debug is discussed in this application note in a later section).

2.1 Configuring the Debugger

The chip can be debugged using CCS via the JTAG port. If using a Sitara AM2x MCU evaluation board, you can use the on-board JTAG debug probe. There is also typically support for using your own JTAG debug probe via an external header.

To setup your board and debugger for CCS debug, see the EVM Setup section of the MCU+ SDK Getting Started guide for your device to setup your board and debugger for CCS debug.

2.2 Breakpoints and Watchpoints

This section covers breakpoints and watchpoints and how to use them.

Breakpoints are program locations where the processor must halt so that debugging can occur. Both hardware and software break points allow the core to halt at a given PC location.

Watchpoints are breakpoints that can be triggered to halt program execution when a particular memory read or write occurs. Watchpoints are extremely useful to catch exceptions, invalid memory boundary accesses, overrun buffers, and so forth and can be set to access any memory region, including Memory Mapped Registers (MMRs).

2.2.1 Software Breakpoints

A Software breakpoint is implemented as an opcode replacement. The debugger modifies the opcode by inserting an estop_0 instruction where the previous instruction was. The program counter stops immediately before it executes the software breakpoint instruction. In general, this instruction is hidden from the main interface, but in certain instances this instruction is displayed in the Disassembly View. Software breakpoints can only be set in memory regions with write access (RAM), therefore, there is no theoretical limit to the number of software breakpoints that can be used.

To toggle a breakpoint, either double-click on the left side of either the line number in the source code view or the address in the disassembly view, or right-click → Toggle Breakpoint.

CCS allows you to single-step through the code in your program. With the breakpoint set, select Run > Step Into to step into a given function.

You can also select Run > Step Over that executes the function in a single step. This is useful when you do not want to enter a certain function when single-stepping through code.

2.2.2 Hardware Breakpoints

A Hardware breakpoint is implemented internally by the target hardware. The method used to do this is heavily dependent on the device or core, but typically the debugger writes the address to a register on the device and sets a flag to enable breakpoints. These registers are not exposed to the IDE. A hardware breakpoint can be set in any memory type (RAM, Flash or ROM), but it is limited by the number of registers on the device. This is mandatory for the types of console I/O devices. Hardware breakpoints can also have a count, which determines the number of times a location is encountered before a breakpoint is generated. For example, if the count is 2, a breakpoint is generated every second time. Hardware breakpoints make use of dedicated registers and hence are limited in number. The AM243x supports 8 hardware breakpoints and 8 watchpoints. To see how many hardware breakpoints and watchpoints are supported per device family, see the device-specific technical reference manual.

2.2.3 Watchpoints

Watchpoints are a special category of hardware breakpoints that can be triggered for a particular memory read or write. Watchpoints are extremely useful to catch exceptions, invalid memory boundary accesses, overrun buffers, and so forth and can be set to access any memory region, including Memory Mapped Registers (MMRs).

To set a Watchpoint, highlight a variable in the source code editor, right click and select Breakpoint → Hardware Watchpoint. For example, right click on the variable gGpioIntrDone and add a watchpoint. Whenever you press the general-purpose input/output (GPIO) push button, a breakpoint will trigger when gGpioIntrDone increments at the line gGpioIntrDone++; in GPIO_bankIsrFxn().

A common issue causing software instability is stack overflow. When building a project, the stack size is typically specified in the project linker, that corresponding size is allocated for the stack by the linker. A hardware watchpoint can be set to monitor when the location __STACK_END - 2 is written to, which indicates that a stack overflow has occurred.

2.3 Inspecting Device Registers

To open the Registers view: View → Registers.

The Registers view allows for viewing and editing the contents of core and peripheral registers of the device, including bitfields and individual bits.

Type Ctrl+F or right click → Find to search for any register in the register window.

 

Texas Instruments

© Copyright 1995-2025 Texas Instruments Incorporated. All rights reserved.
Submit documentation feedback | IMPORTANT NOTICE | Trademarks | Privacy policy | Cookie policy | Terms of use | Terms of sale