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.

Profile clocks differ

Other Parts Discussed in Thread: OMAPL138, TMS320C6748

Hi E2Er's

Have migrated a project from CCS3.3 (aimed at OMAPL138 on EVM boad) to CCS4.2 (aimed at OMAPL138 on eXperimenter board). All builds and runs as expected except when it comes to profiling with the supplied XDS500 V1 emulator.

CCS3.3 allows us to profile functions

CCS4.2 does not give any active confgurations hence cannot profile functions.

1 : If we can profile functions in CCS3.3 why not CCS4.2. - NB I am aware that the cache based nature of the c6000 devices may affect the profile results especially around branchs. The question here is if the profile functions works for CCS3.3 (albeit with issues) is it meant to be supported for OMAPL138 in CCS4.2 or has that been depricated ?

2 : We tried using CCS3.3 to profile function X with the simple profile clock. The clock is set to measure CPU execution cycles. Breakpoints are set around the function X and over several runs we see a fairly consistant average of 17,000 cycles to execute function. We do a similar thing with the CCS4.2 version - it again is consistant but specifies 3,000,000 cycles. I would expect the function to take longer than the 3,000,000 CPU instruction cycles. Any ideas on why such a discrepency ? Functionally, memory layout etc is same and I know the function should be executing at approx the same  speed as they are both called from a period thread and both operate correctly at a specified period and beak at the same reduced period setting.

BR

Barry

  • Hi Barry,

    barry mohan said:
    1 : If we can profile functions in CCS3.3 why not CCS4.2. - NB I am aware that the cache based nature of the c6000 devices may affect the profile results especially around branchs. The question here is if the profile functions works for CCS3.3 (albeit with issues) is it meant to be supported for OMAPL138 in CCS4.2 or has that been depricated ?

    We removed support for profiling on C6000 HW in v4 because for the reasons you already mentioned (the intrusive method of how it collected the data and how multiple branches can lead to inaccurate results).

    barry mohan said:
    2 : We tried using CCS3.3 to profile function X with the simple profile clock. The clock is set to measure CPU execution cycles. Breakpoints are set around the function X and over several runs we see a fairly consistant average of 17,000 cycles to execute function. We do a similar thing with the CCS4.2 version - it again is consistant but specifies 3,000,000 cycles.

    This is surprising. What emulator are you using? Did you mean XDS100v1? Is that the onboard emulation you are using?

    Thanks

    ki

  • Hi Ki

    We are indeed using the onboad XDS100v1 emulator in both instances in trying to communicate with OMAPL138 SOM-M1 on the EVM and the eXperimenter. Am very familiar with CCS3.3 but this is fist delve into CCS4.2 so apologies for any silly questions.

    The configuration file I am using for the eXperimenter has :

    Connection : Texas Instruments XDS100v1 USB emulator

    Board: TMS320C6748

    My build properties:

    CCS Build:

    Generic c674x device

    Device Endianness : Little

    CGT : TI v7.0.3

    Runtime Support Library : <automatic>

    DSP/BIOS version : 5.41.10.36

     

    C/C++ Build:

    c6000 compiler -> basic options -> Target processor version  -> 6740

    - Does the runtime model option "compile for breakpoint based profiling" have any effect then ?

    - I am building with -g though under linker ->Symbol  Management -> Strip symbol tables and line number entries is used - would this cause an issue ?

     

    My *.tcf settings:

    System -> Global Settings -> target board Name c6748

                                               -> Processor ID 0   ??????

                                               -> Board Clock KHz 20000     ???????

                                               -> DSP  Speed MHz (CLKOUT) 300.0000

                                               -> Specify RTS library false

                                               -> Use instrumented BIOS library false

     

    Note ; I am a bit confused between the CCS build options and the *.tcf settings eg I specify a RTS library as automatic in  build settings but not in *.tcf ? Which superceeds which ?

    Also am a bit concerned about the RTSC setting which is new to me.

    Windows-> settings->CCs->RTSC

    ie I have nothing specified here and there is no dropdown selection available for the RSC platform

    hence when I look under Tools->RTSC->path I have

    and under Tools -> RTSC ->platform-> edit/view

    again here there are no highligyted options for the Package Name and CPU core.

    Does the RTSC configuration apply to the DSP under DSP/BIOS or just the ARM uner SYS/BIOS ? This I'm not sure about. the project builds and runs OK but think if it is required it could be causing some of the issues with the profiling.

    Appear to have expanded the questions here Ki - apologies for that however am hoping if you know what I am not sure about it will help focus on where I may be configuring this project wrongly (if in fact that is the real issue).

    Many thanks in advance

    BR

    Barry

     

     

     

  • Hi Ki

    Had some screen shots which pasted directly into the post message but appear not to have been sent - will try to add them as an attachment in a moment when i put them toether again.

    BR

    Barry

  • Hi Again Ki

    And the attachments detailing RTSC options.

    BR

    Barry

    RTSC_Configuration.doc
  • Barry,

    I have the same issue with an L138 EVM, XDS510 ICE and CCS4.2. I am seeing huge profile clock counts which do not correspond at all to real time, I get about 20000000 cycle counts per assembly step in the debugger disassembly window. The other thing is that my code seems to be running much slower than I expected but I cannot find any benchmark source to compare with. Did you ever find a solution to this?

    Thanks

    Keith.

  • Hi Keith

    Never got a final reply and had to move on to other things.

    Have updated emulators etc though haven't had to profile yet with the new configurations.We have brought out an GPIO line which we can use now for profiling.

    BR

    Barry