OMAP4 Debug and Trace Tools

From Texas Instruments Embedded Processors Wiki

Jump to: navigation, search
Translate this page to   


Contents

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

TBD

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.

CtoolsLib

Available now

CCS v5.1 

Processor Trace Cortex A9 MPU subsystem

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

TBD

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

Getting Started


Hints and Tips


Support

Please post support questions to the appropriate internal forums below.


FAQ

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?

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

Q12: What pins do I need for STM?

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

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?

  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 4.2.2.2 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?

Leave a Comment
Personal tools
Namespaces
Variants
Actions
Navigation
Print/export
Toolbox