• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 53 subscribers
  • Views 686 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

no trace data on CCS5.1.1

Weichun Yuan
Expert 1210 points
Other Parts Discussed in Thread: SYSBIOS

We use CCS 5.1 .1 to debug a C6657 based system built above sysBios. We use XDS100v2 with ETB to debug an exception, based on http://processors.wiki.ti.com/index.php/Trace_ETB_Use_Cases_Quick_Reference#Using_Trace_to_Capture_Processor_Exceptions_Quick_Reference.

After we configured the trace job and started the code, I could trigger an exception, but nothing came out on the trace display. I am including the screen shot for the trace job. Could anyone get me some tips?

thanks

Weichun7120.trace_setup.ppt

  • 0
    TI__Guru**** 169894 points

    Weichun,

    If you were able to perform trace before, then I suspect the debug configuration may have become somehow corrupt - I would strongly recommend to inspect the troubleshooting steps shown at topics General IDE and Debugger of the CCSv5 Troubleshooting page. To reinforce this, by looking at the screenshot the Trace Display is completely blank and not showing zero trace data (as it would in case no data was collected due to other reasons). The procedure you sent looks fine, but could you try to trace a region of your code (before the exception happens) just to see if Trace is not being influenced by the exception itself?

    If you never tried (or was never able to) perform trace, then I strongly recommend updating your copy of CCS. The main reason is that several issues were fixed in subsequent releases of CCS and I can't recall if the behavior you described was a known bug. For example, I can capture ETB data on my C6678 EVM using XDS100v1, CCSv5.3 and 5.4 (I don't have a C6657, but they are very similar devices).

    For the updating process I strongly recommend downloading a full copy of CCSv5.4, installing it in a different directory and using a different workspace - this way you don't disrupt your current development environment.

    Hope this helps,

    Rafael

  • 0 in reply to desouza
    Expert 1210 points

    Hi, Rafael,

    thanks for the help. I saw trace data before, but could not analyze it properly. As I tried to reproduce it, no trace_data were displayed.

    I tried to capture the log following your instruction, but I could not see the log in the specified directory. More interesting, I started to see error messages as in the errorLog.log. I could not start tools/trace control either -- after clicking, nothing pops up. I also include the env.log which include the env setting tracelogging level.

    Could you please give me some pointers on how to proceed?

    thanks

    Weichun

    4666.errorLog.log

    6153.env.log
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    Setting environment for using Microsoft Visual Studio 2005 x86 tools.
    C:\Program Files\Microsoft Visual Studio 8\VC>set
    ALLUSERSPROFILE=C:\Documents and Settings\All Users
    APPDATA=C:\Documents and Settings\wyuan\Application Data
    BIOS_INSTALL_DIR=C:\CCStudio_v3.3\\bios_5_33_01
    CLASSPATH=.;C:\Program Files\Java\jre6\lib\ext\QTJava.zip
    CommonProgramFiles=C:\Program Files\Common Files
    COMPUTERNAME=WYUAN-GX270
    ComSpec=C:\WINDOWS\system32\cmd.exe
    CPP_LIBS=C:\depot\Support\cpp_libs
    DEFLOGDIR=C:\Documents and Settings\All Users\Application Data\McAfee\DesktopProtection
    DevEnvDir=C:\Program Files\Microsoft Visual Studio 8\Common7\IDE
    FP_NO_HOST_CHECK=NO
    FrameworkDir=C:\WINDOWS\Microsoft.NET\Framework
    FrameworkSDKDir=C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0
    FrameworkVersion=v2.0.50727
    HOME=c:\wyuan
    HOMEDRIVE=H:
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

  • 0 in reply to Weichun Yuan
    Expert 1210 points

    Hi, Rafael,

    I un-install and re-installed my ccs, so the trace data does come back, following the configuration described in the ppt in the previous post in the same thread. But somehow I can only see sysBios call (after I set start trace and stop all trace at ti_sysbois_family_c64p_Hwi_int1 on my c6657 running MCSDK 2.1.2.6, sysBios 6.34.4.22).

    I setup a call which access null pointer, which is called by uart task, as the following

    int crash_trigger(void)
    {
        memset(0,0x12,10);
    }

    I would expect that I could find this in my trace buffer. But I only saw the sysbios acitivities. I am attaching the trace log, in which I can not find anything related to memset or crash_trigger. I would expect that the tracing would stop at the time of exception. Is there anything I missed in the setup or I could run into jtag problem?

    thanks a lot

    Weichun

  • 0 in reply to Weichun Yuan
    Expert 1210 points

    I tried several more cases, by forcing an exception at different location in the code, but the trace buffer never contains any of my code except sysBios code. I even set break point at ti_sysbios_family_c64p_Hwi_int1.

    I confirmed that the crashing did happen within my code, not in the sysBios code because after crash, the console log shows where my crash pc, which matches my expectation, is where I force the exception.

    Any idea why the trace buffer does not work as expected?

    thanks for any tip

    Weichun