• State TI Thinks Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 456 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Original question:

RM48L952: execution time calculation

RM48L952: RM48L952 PMU seems to be counting twice as many (2x) cycles as expected using EVENT == cycle count

Kip Leitner
Prodigy 196 points
Part Number: RM48L952
Other Parts Discussed in Thread: HALCOGEN

Tool/software:

I am using the PMU as recommended in TI literature SPNA138A

I configured event counter 0 to count processor cycles. 

When I run the loop below, doing a "free run", after the loop finishes, there are about twice as many cycles counted as I expect.

Each iteration through the for loop is 10 asm instructions (shown in picture)

If I run the loop 500 times, I get about 10,000 in the counter, where I expect 5,000

If I run the loop 1,000 times, I get 20,000 in the counter, where I expect 10,000.

So the value in the counter is twice as big as I expect

Processor clock speed is 200 MHz, but I don't think this matters.

  • 0
    TI__Guru*** 135355 points

    Hello,

    Our expert for this topic is out of office today, please expect a reply early next week, thanks.

    Best Regards,

    Ralph Jacobi

  • 0 in reply to Ralph Jacobi
    TI__Guru 71221 points

    Hi Kip,

    Apologies for the delay in late response.

    This is first time i come across this application notes.

    If possible, can you please share your sample code for quick debugging at my end?

    --

    Thanks & regards,
    Jagadish.

  • 0
    Prodigy 196 points

    Any progress on this at TI?

  • 0 in reply to Kip Leitner
    TI__Guru 71221 points

    Hi Kip,

    My sincere apologies for the delay in late reply, i am on vacation for few days and followed by a weekend.

    I don't see any issues with your code, and it looks fine for me. The only thing i am suspecting is below:

    (+) [RM57L LaunchPad] Execution Time Measurement - Arm-based microcontrollers forum - Arm-based microcontrollers - TI E2E support forums

    If you verify above thread, it is mentioned that:

    The PMU runs on CPU's clock frequency (GCLK) not on System module clock frequency (HCLK).

    I think in our case also we are using HCLK instead of GCLK.

    I think here also HCLK is is half of the GCLK, that is the reason we are getting double the clock for measurement using PMU. I mean the count given by PMU is inters of GCLK but we are calculating the period with HCLK (which is half of the GLCK), this is the reason we are getting double the period value for PMU execution measurement.

    --
    Thanks & regards,
    Jagadish.

  • 0
    Prodigy 196 points

    jagadish -- You comment is interesting but doesn't solve my problem.

    In my system, the HALCoGen is configured so that GCLK ==  HCLK == 200 MHz., so I don't think that the clock source for PMU is involved. 

    Just load the program into the CCS debugger with Hercules Dev Kit and count the assembly instructions in the "for" loop and you will see that the counter counts MORE than two times (2x) of processor cycles than are ACTUALLY IN THE FOR LOOP. 

              $C$L1:
    0000d028:   E59F012C            ldr        r0, [pc, #0x12c]
    0000d02c:   E590C000            ldr        r12, [r0]
    0000d030:   E28CC001            add        r12, r12, #1
    0000d034:   E580C000            str        r12, [r0]

     56           for (uint32 i= 0; i<LOOP_COUNT; i++)

    0000d038:   E59DC000            ldr        r12, [r13]
    0000d03c:   E28CC001            add        r12, r12, #1
    0000d040:   E58DC000            str        r12, [r13]
    0000d044:   E59DC000            ldr        r12, [r13]
    0000d048:   E35C0F7D            cmp        r12, #0x1f4
    0000d04c:   3AFFFFF5            blo        $C$L1

    It looks to me like all these ASM instructions are 1 processor clock cycle

    My test conditions are:

    All refresh of vars, register, expressions, etc are DISABLED so the JTAG is NOT refreshing Data

    Free Run then manual halt at breakpoint.

    So, some things that might be causing this problem:

    • Blackhawk SDS200 Debug probe inserting many, many instructions in secret

    This is not a floating point problem, as I am just talking about processor cycles.

  • 0
    Prodigy 196 points

    jagadish -- You comment is interesting but doesn't solve my problem.

    In my system, the HALCoGen is configured so that GCLK ==  HCLK == 200 MHz., so I don't think that the clock source for PMU is involved. 

    Just load the program into the CCS debugger with Hercules Dev Kit and count the assembly instructions in the "for" loop and you will see that the counter counts MORE than two times (2x) of processor cycles than are ACTUALLY IN THE FOR LOOP. 

              $C$L1:
    0000d028:   E59F012C            ldr        r0, [pc, #0x12c]
    0000d02c:   E590C000            ldr        r12, [r0]
    0000d030:   E28CC001            add        r12, r12, #1
    0000d034:   E580C000            str        r12, [r0]

     56           for (uint32 i= 0; i<LOOP_COUNT; i++)

    0000d038:   E59DC000            ldr        r12, [r13]
    0000d03c:   E28CC001            add        r12, r12, #1
    0000d040:   E58DC000            str        r12, [r13]
    0000d044:   E59DC000            ldr        r12, [r13]
    0000d048:   E35C0F7D            cmp        r12, #0x1f4
    0000d04c:   3AFFFFF5            blo        $C$L1

    It looks to me like all these ASM instructions are 1 processor clock cycle

    My test conditions are:

    All refresh of vars, register, expressions, etc are DISABLED so the JTAG is NOT refreshing Data

    Free Run then manual halt at breakpoint.

    So, some things that might be causing this problem:

    • Blackhawk SDS200 Debug probe inserting many, many instructions in secret

    This is not a floating point problem, as I am just talking about processor cycles.

  • 0 in reply to Kip Leitner
    TI__Guru 71221 points

    Hi Kip,

    Kip Leitner said:
    It looks to me like all these ASM instructions are 1 processor clock cycle

    No Kip, all these instructions will not take single clock cycles, some of them might take more than one clock cycles.

    Please refer below links to understand this in detailed:
    (+) cortex R4 execution cycles - Arm-based microcontrollers forum - Arm-based microcontrollers - TI E2E support forums

    why does LDR takes two cycle to be executed - Architectures and Processors forum - Support forums - Arm Community

    --
    Thanks & regards,
    Jagadish.