• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 53 subscribers
  • Views 434 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.

CCS/OMAP-L137: CCS 9.0.1 under Linux crashes when attempt to use PC trace for the ARM9 core of an OMAP-L137

Chester Gillon
Guru 92251 points
Part Number: OMAP-L137
Other Parts Discussed in Thread: OMAPL138

Tool/software: Code Composer Studio

When using the following I am getting CCS consistently crashing when attempt to use the hardware trace analyser to collect PC trace of the OMAP-L137 ARM9 core using the ETB:

- 9.0.1.00004 running in Ubuntu 18.04.2 LTS
- TI Emulators 8.1.0.00012
- OMAP-L137 on a MCBTMS570
- Blackhawk USB560-M, 20 pin JTAG cable

Steps to reproduce are:
- Download program which stops at main
- Use Hardware trace analyser to select PC trace using the ETB, selecting defaults.
- Step the program and CCS crashes.

Setting the environment variable TI_TRACE_LOGGING=6 before starting CCS shows the following final output on the console when CCS crashes:

M     15:03:40:827 | ETB Data Source: ELAPSED TIME Data Source, time to collect trace data + ICE, , , 0.000015 
*** buffer overflow detected ***: /home/mr_halfword/ti/ccs901/ccs/eclipse/ccstudio terminated

From a quick decode of the .dmp file generated when CCS crashes, libc-2.27.so is exiting CCS with a SIGABRT, when the C run time library was called from libEtmHistTI.so

71d0e5f9-6cb4-3b19-54e6db5c-48d25bb1.zip contains the .dmp file from one crash, along with the cTools/Trace log.

OMAP_l137_hello_ARM.zipis the simple "hello world" program used to create the crash. Originally I was getting the CCS crash attempting to use PC trace with one of the ti-processor-sdk-rtos-omapl137-evm-05.03.00.07 examples, but repeated the crash on a simple example.

  • 0
    TI__Guru**** 168267 points
    Chester,

    I can reproduce this issue as well, but on either ARM9 architectures: OMAPL137 and OMAPL138 - Windows works well, but Linux is corrupted during the data download phase (immediately after the Halt button is pressed).

    I filed the bug report DBGTRC-4943 and its status can be verified in the link SDOWP in my signature below. However, I am afraid it may not get much priority in the activity queue, given that both OMAPL137/L138 are older platforms.

    I apologize for the inconvenience,
    Rafael
  • 0 in reply to desouza
    Guru 92251 points

    desouza said:
    I can reproduce this issue as well, but on either ARM9 architectures: OMAPL137 and OMAPL138 - Windows works well, but Linux is corrupted during the data download phase (immediately after the Halt button is pressed).

    Thanks for confirming the crash with Linux.

    While I didn't get the crash with Windows, there was no PC trace collected from the ARM9 ETB under Windows (in that the trace window showed zero samples). In your tests with Windows did the PC trace capture contain sensible samples?

  • 0 in reply to Chester Gillon
    TI__Guru**** 168267 points

    Chester,

    Yesterday I thought I had captured the Trace information, but it seems the decoder is not gathering meaningful data. I tested with the latest emupacks to no avail and need to see if older versions work. 

    I will file a bug report later tomorrow. 

    Regards,

    Rafael

  • 0 in reply to desouza
    TI__Guru**** 168267 points
    Chester,

    I added the Windows scenario to the bug report above, since I believe the root cause for both issues is the same.

    I apologize for the inconvenience,
    Rafael
  • 0 in reply to desouza
    TI__Guru**** 168267 points

    Chester,

    The bug was fixed and will be made available in the August version of the emulation pack. 

    I apologize for the inconvenience,

    Rafael