OMAP4 Debug and Trace Tools

From Texas Instruments Wiki
Jump to: navigation, search

Features and Use Case Overview

Ti-omap4.jpg XDS560V2-STM.JPG CCSv4 LinuxAware07.PNG

Feature/Use Case Subsystems Brief Description Details Availability                 

Stop mode JTAG debug

Cortex A9 MPU subsystem

Cortex M3 MPU subsystem

IVA-HD subsystem

DSP subsystem


Reset, wait-in-reset, connect/disconnect, run, low-power run, halt, step, file load, memory, registers, breakpoints and watch-points etc

CCS getting started


Available now

CCS v5.1      

In-package JTAG debug support

Cortex A9 MPU subsystem
Cortex M3 MPU subsystem

IVA-HD subsystem

DSP subsystem

SD MMC interface adapter support for JTAG debug and STM


CCS v5.1

Kernel aware debug

Cortex A9 MPU subsystem
 Cortex A9 stop mode kernel aware debug CCSv4 kernel aware debug

Available now

CCS v5.1

Run mode debug Cortex A9 MPU subsystem
 GDB based Cortex A9 run mode debug How to run GDB in CCSv5

Available now

CCS v5.1

MMU/Cache/Security advanced feature control

Cortex A9 MPU subsystem

MMU and L1 cache control operations view

Cortex A9 advanced feature view

Available now

CCS v5.1

Determine cache performance


Cortex M3 MPU subsystem

DSP subsystem

Subsystem timing and counting modules for cache performance measurements

How to enable SCTM on OMAP4430


 Available now

CCS v5.1

Multi-Core System Trace (STM) based software messages

System level

Hardware accelerated printf based on MIPI STM software generated messages. All cores can generate software messages and the system will provide a time-wise correlated view.  STM SW messages should be collected with XDS560v2 or on-chip ETB.

How to use STM

Available now

CCS v5.1

Linux device driver for character mode messaging

Cortex A9 MPU subsystem

Character mode device driver for Linux which allows STDIO to be used directly in Linux and Andrioid. Create a device driver for each channel. ex: "/dev/stm1" is a linux device which allows commands like "ls -l > /dev/stm1" to output to MIPI STM.

STM Linux device driver

Available now

CCS v5.1

Power and clock management profiling

System level

Configure, capture, and display PRCM events via CCS. STM messages should be collected with XDS560v2 or on-chip ETB.

How to use Power/Clock management

Available now

CCS v5.1

Debug and profile IVA-HD

System level

Activity tracing from SMSET of the IVA-HD system for performance optimization and debugging of all functional units. Should be able to see start/stop times for each functional unit. STM SW messages should be collected with XDS560v2 or on-chip ETB.

How to use IVA-HD SMSET

Available now

CCS v5.1 

Profile performance and latency of functional interfaces

System level

Setup, collect and display performance and latency of functional interfaces. Focus  on bytes/cycle (throughput), latency (stalls), and transfer sizes (efficiency). Priority on DDR interface. STM messages should be collected with XDS560v2 or on-chip ETB.

How to use STM Statistics Collector 

Available now

CCS v5.1 

Remote/In-product debugging System level

Program CTools capabilities (SW Message, Statistics Collectors, PMI/CMI etc.) with software, collect STM information in ETB, customer transfers BIN file to PC, decode and display.


Available now

CCS v5.1 

Processor Trace Cortex A9 MPU subsystem

Cortex A9 processor trace collected with XDS560 class receiver or on-chip ETB.


3Q 2011

Hardware Requirements

NOTE: Board modifications may be required for OMAP4 SDP and Blaze board fixing MIPI-60 pin connector so that STM trace can be collected successfully via XDS560v2. Please contact support for details.

Configuration and GEL Files

  • Latest OMAP4 support package containing the GEL files
  • If you are manually creating a CCSv4 target setup configuration, you need to add the following GEL files to your configuration:
    For ICEpick-D, you need to add: omap4430_ICEPickD_Utility.gel
    For CS_DAP_debugSS, you need to add: omap4430_dap_startup.gel
    For the CS_DAP_PC, you need to add: omap4430_CS_DAP_PC_Utility.gel
    For CortexA9_0, you need to add: omap4430_cortexa9_cpu0_startup.gel after commenting out the attempt to load DSS_gel_wrapper.gel

Getting Started

  • Make sure that you have correct CCS version installed on your PC
  • OMAP4 HW is connected to a XDS560 class emulator and with the host PC
  • Everything is powered on
  • Launch CCS
  • First time users
    • Create a CCS connection setup for your target  and specify the right GEL files in the settings. Watch a demo here
  • Select your target setup configuration and launch debugger
  • Connect to the target core(s)

Hints and Tips

  • Show ICEPick and DAP in debug view: ICEPick and DAP can provide additional debug information. They are hidden from CCCv4 by default. To display them, select menu item "window - preferences" and then check "show non-processor device" under debug option
  • Debug JTAG connectivity with DBGJTAG utility: DBGJTAG utility is a powerful tool to debug JTAG scan chain issues.
  • If you are using Blaze board with ES2.0 chip, please use 1 pin STM trace instead of 4 pins due to a known issue.


Please post support questions to the appropriate internal forums below.


Q1. Board connection seems to be unstable and gets disconneced randomly?

A. Pelase make sure that you have inclueded all the GEL files for ICEPICK_D, DAP_PC and the cores to initialize board correctly before you starate debug. Also, you may want to set JTAG clock a lower fixed frequency (~5 mHz) from CCS connection setup. Please see the "GEL files" section for more details.

Q2. Are the tools reporting a DAP slave error?

A. This is a symptom of an illegal access made over the DAP port It is also a symptom of the CPU in a locked up state
Check if \ccsv4\DebugServer\bin\win32\FlashStellaris.dll is present. If present, delete it.

Q3. Are the tools reporting error messages like RESET EMULATOR and/or disconnect?

This is a symptom of an illegal access made over the DAP port. It is also a symptom of the CPU in a locked up state
Check if the L2MMU is enabled, If enabled, configure MMU to generate interrupts on internal events (See L2MMU: MMU_IRQENABLE register)
Re-run the scenario to re-create the failing condition. Upon failure, check the interrupt status register to see which failure occurred (See L2MMU: MMU_IRQSTATUS register).
Read the address causing the fault via the fault address register (See L2MMU: MMU_FAULT_AD).Determine why the address is causing the MMU translation fault.
Is spinlock register programming causing SWBP not working?
The SPINLOCK register located at the physical address 0x4A0F6800, from the Chiron perspective is actually located at the virtual address 0xAA0F6800 from Cortex M3 subsystem side. (L2_MMU Mapping). The application was corrected to access the register at the correct address to resolve the MMU translation fault. Note that when an MMU translation fault occurs the CPU will lock up and basically no debug support is available.

Q4. Are old applications giving SW breakpoint errors?

Older applications inherited from previous programs may not have been completely ported over, resulting in these class of issues.

If SWBPs are still non-functional, check from other issues like is the code running out of ROM/FLASH, is the memory map setup correctly, is there smoke from the target, is target on fire:-) etc. If none of these issues exist, then report the issues .

Q5. Cortex A9 memory download (via memory window) is slow for multi-MB files.

In order to download very large memory images, it is recommanded to turn off memory verification option for a faster download. However, with this option, any possible errors encountered during download would be reflected after the download is done and user is doing other debuggers steps (not during the download). You need to do so from Tools->Debugger Options->Generic Debugger Options  ("No Verificaton" checked in Program Verification Option). for a core selected in the debug view. Please remember the settings are only for a gien core aand for a given target configuration. If you change any of that, please make sure to turn off the option again.

Q6. Loadig a very large image via XDS560v2 USB connection seems to hang the emulator.

There is a known defect with the XDS560v2 USB driver where it hangs for the images above 20 MB. This issue is being worked out by Spectrum Digital Inc. Meanwhile, you can continue with XDS560v2 Ethernet connection.

Q7. How does CCS make the target halt so that a user can debug his application?

Halting the target is the most fundamental and most critical aspect of debug. On any target, entry into debug state is very much like interrupt generation and interrupt handling. When a user wants to debug his application and issue a Halt Request via the CCS menu, CCS will post this request to the target CPU. This is typically called a Debug Request. The CPU will complete the current instruction that it is processing and then respond to the request with a Debug Acknowledge.

Once an acknowledge is received, it immediately begins processing the sequence for entry into debug state. Once this is complete, CCS allows the user to debug his/her application.

Q8. Is it possible that sometimes CCS may not be able to Halt the processor?

Yes, if the application is executing in lost space and the CPU is unable to complete the current instruction that it is processing then the Debug Request from the CPU will never receive the corresponding Debug Acknowledge. This happens rarely and is typically due to the application in a very bad state OR a hardware issue that causes the application to go into a very bad state. In either case, the ability of CCS to perform the traditional stop mode debug is severely compromised.

Q9. What is the impact of the Unicache HW bug on a user's ability to debug their applications.

Please read earlier FAQs. The Unicache issue cripples the ability of the user of CCS to debug applications. The following scenario has been observed multiple times:

1. Cortex M3 subsystem is initialized, application is loaded and it runs.

2. The fact that it is running properly is indicated by CIO (printf to the console) being performed in a console window.

3. At some point in the course of running (for varying periods of time) CIO simply stops.

4. As indicated in FAQ, the symptom merits investigation of the L2-MMU programming.

5. At this time, Checking the L2-MMU state via the L3 slave port access from Debug DAP for a TLB interrupt or any other interrupt reveals that this is not an L2-MMU stall.

6. Investigating this further, if a read is tried from the M3 (DAP) via AHB interface onto the system bus to any address (e.g. 0x20000000, 0x40000000, 0x55………) then the ICODE bus completes whatever access was ‘hung’ (in the arbitration of unicache slave ports for example?) and system bus access goes through also and the CPU can be halted.

7. Once the CPU resumes correctly, it continues for some time and hits the same condition again. Repeating the actions outlined in step 6, corrects the problem once again.

8. If the application is run with the Unicache turned off, it runs without any issues.

From a tooling perspective, there are very limited options on what CCS can do due to this class of a hardware issue.

Q10. How to use System Trace (STM) in embedded linux environment?

  • In embedded linux environment, both coretxA9s are running linux. Thus, we cannot execute gel functions in omap4430_stm.gel from cortexA9s to enable system trace features.
  • The solution is that first, make sure no other gel files are associated to any nodes in omap4430 configuration. Then attach omap4430_stm.gel to CS_DAP_DebugSS node. After connecting to CS_DAP_DebugSS node, click on "Script->STM Utility" to execute GEL functions to enable STM.
  • To use software message feature only, it is not necessary to connect to cortexA9.
  • To use performace probe, user has to first connect to cortexA9; while cortexA9 is hatled after connection, user then creates trace job from breakpoint manager. After enable all the trace job, use has to run cortexA9 so that linux can be active.
  • Details on using statistics collectors can be found here

Q11: How big is the receiver buffer on XDS560v2 emulator.

  • XDS560v2 supports up to 128MB as receiver buffer size. User can select this buffer size from Trace Control's Receiver Configuration section. 

Q12: What pins do I need for STM?

  • STM can operate in 3 modes: 4 pin, 2, and 1 pin. For 4 pin STM you need the EMU0-4 pins for a 4 pin STM channel (4 data/1 clock). For 2 pin, you need EMU0/1 for 1 pin STM, and EMU 0/1/2 for 2 pin STM. Please note that these pins can be running at higher frequency, so attention must be paid to layout/routing and signal integrity.

Q13: OMAP4: Can I get STM information from a finshed product / closed phone? / Can I get STM data through the SD/MMC card interface?

  • A: The STM port is normally on EMU[0:4], but can be sent out via EMU [15:19] which is on the MMC1 pins. This is based on the MIPI NIDnT (Narrow Interface for Debug and Test). The purpose is to re-use application interface pins. In the context of the OMAP4430 device, the application interface that can serve as a NIDnT port is the MMC1 interface. To use the NIDnT port, the relevant MMC1 pins must be set to the appropriate MUX mode through control module. Please check the datasheet/TRM for details on how to setup the STM port to these pins.
  • A: Spectrum Digital is bulding an adapter hardware for this

Q14: When I use Spetrum Digital XDS560v2 USB emulator to collect STM data, CCS seems to hang for a few minutes and then comes back live. what happened?

  • A: You may experience a firmware bug in SD XDS560v2 USB emulator. One work around is to use LAN option instead. SD provided a bug fix and it required user to download SD's firmware and do a upgrade to the emulator. The instructions are listed below:
  1. Install CCSV4.2 or later 
  2. Launch CCS. Select Help->Software Updates->Find and Install... to bring up Install/Update window.
  3. Choose "Search for new features to install"
  4. Check the box in front of "Spectrum Digital CCS4.2 Emulation Updates" and click on Finish button.
  5. Check the box in front of "Spectrum Digital CCS4.2 Emulation Updates" again in the next window. Make sure the version is or later. Follow the window promts to download and install this update.
  6. Make sure the emulator's USB cable is plugged to the PC that install with this update.
  7. Open a DOS command prompt and go to [CCSV4_INSTALL_DIR]\ccsv4\common\uscif
  8. type in "dtc_conf update sd560v2u 0 .\sd560v2_updates\sd_xds560v2_firmware_2.2.0.2" (the firmware version may be different)
  9. follow the instruction on DOS command prompt. It will take a couple minutes to finish the firmware update.

Q15: How can I determine whether STM module is active in my configuration?

  • A: In order to use STM, some clock and firewall settings needed to be properly configured. These settings are mostly done through GEL files that listed in GEL package. However, some customer chip settings or in HS devices, the clocks and firewall configuration regions are not exposed. Thus, user cannot use GEL functions to configure and enable STM module. To check whether STM module is active even after executing proper gel, please load this gel file (needs to unzip first) to cs_dap_debugSS and execute STM_Diagnosis() function. If user cannot see "STM Diagnosis is done. STM is ready to be used" from console window, then STM is not active. Please analysis the cost of failure based on diagnosis message shown on console.

Q16: Is it okay to have other devices (FPGAs, CPLDs, etc.) on the JTAG chain or will the JTAG emulator pod have trouble with this when loading the flash that holds the programming contents for the OPEM processor?

  • A: ???