• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 83 subscribers
  • Views 112 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.

TMS320F28384D: Question regarding IPC free-running counter

Marvn Arcangel
Genius 16530 points

Part Number: TMS320F28384D
Other Parts Discussed in Thread: SYSCONFIG

Hi Experts,

I initially planned to use the IPC free-running counter, described below per TMS320F2838x technical reference manual, to measure the execution time between two breakpoints.

16.5 Free-Running Counter

A 64-bit free-running counter is present in the device and can be used to timestamp IPC events between processors. The counter is clocked by PLLSYSCLK and reset by SYSRSn. The counter is implemented as two 32-bit registers, IPCCOUNTERH and IPCCOUNTERL. When IPCCOUNTERL is read, the value of IPCCOUNTERH is saved. A subsequent read to IPCCOUNTERH returns this saved value. Therefore, the user must always read IPCCOUNTERL first then read IPCCOUNTERH next. This design prevents race conditions due to IPCCOUNTERL overflowing between reads of the two registers. The free-running counter stops only when emulation is suspended (when debugger hits a breakpoint) on all CPUs. If any core is executing, the counter runs.

My approach was as follows: I first halted both CPUs, then executed the CPU under test until it hit the first breakpoint, recording the value of the free-running counter at that moment. Next, I resumed execution of the CPU independently until it reached the second breakpoint, where I captured the counter value again. Based on my understanding, the difference between the counter values at the first and second breakpoints should represent the time (in CPU cycles) required to execute the instructions between those two points. (I also confirmed that the IPC counter was halted and did not continue counting during the capture of both measurements.)

However, the measured value did not match what I had expected when comparing to the expected frame time. After some further testing, I observed that the counter produced the expected frame time when the CPU was running freely. However, when halting the CPU and measuring the counter using breakpoints, the recorded values deviated from the expected frame time. Is it possible that a delay occurs when halting the CPU with the debugger, relative to when the counter stops, which could be affecting the timing measurements between breakpoints? I would greatly appreciate any insights into the potential cause of this discrepancy or suggestions for alternative approaches to accurately measure the execution time between two breakpoints.

Regards,

Marvin

  • 0
    TI__Intellectual 2220 points

    Hi Marvin,
    Expert is OOO, please expect response by tomorrow.

  • 0 in reply to Lakshya Verma
    TI__Expert 5075 points

    Hi Marvin

    Yes, there is a timing artifact when using breakpoints, and it stems from how the CPU pipeline interacts with the halt mechanism. When a hardware breakpoint triggers, the CPU halts when the instruction reaches the DECODE 2 (D2) phase of the pipeline, not at the exact moment the instruction executes. This pipeline delay introduces a small but consistent offset between when the breakpoint logically fires and when the counter actually freezes. Since you have two breakpoints (start and end), these offsets may not cancel out perfectly—especially if the pipeline state differs at each breakpoint location—explaining why your breakpoint-based measurements deviate from free-running behavior.

    Additionally, there's a secondary consideration: reading the 64-bit counter requires two 32-bit read cycles on the C28x's 32-bit data bus. By the time the second read completes, the counter has incremented by two cycles. However, since you confirmed the counter was halted during your reads, this particular artifact shouldn't apply in your case.\

    Which CCS version are you using? If you're using a newer version of CCS, I would recommend using the built-in clock to measure the CPU cycles instead of the IPC Counter. 

    Rather than using the IPC counter (which is designed for timestamping IPC events, not precise execution profiling), consider these purpose-built options:

    CCS Profile Clock 
    The profile clock uses silicon resources to count CPU cycles between two breakpoints. To use it:
    • In CCS: Run → Clock → Enable
    • Set breakpoints at your two measurement points
    • At the first breakpoint, reset the clock counter
    • Run to the second breakpoint and read the cycle count

    This method is specifically designed to compensate for the pipeline effects you're encountering.

    Could you please try using this approach and let me know if it works for you?

    Thanks,

    Ira

  • 0 in reply to Ira Thete
    TI__Genius 16530 points

    Hi Ira,

    Good day.

    Thank you for the detailed explanation regarding the IPC counter—it all makes sense now. After downloading the latest version of CCS (20.5.1), I attempted to use the CCS Profile Clock. However, I encountered a similar issue where the reported cycle count doesn't align with what I had expected. I'm expecting ~40,000 CPU cycles per frame (which I confirmed is correct when running the CPU freely and measuring IPC counter between frames without using breakpoints) but the CCS Profile Clock is consistently reporting 123 CPU cycles per frame. Is the CCS Profile Clock derived from the system clock and can I assume it is operating at the same frequency as the system clock?

  • +1 in reply to Marvn Arcangel
    TI__Expert 5075 points

    Hi Marvn,

    I am assuming that when you say "per frame" you are trying to measure the cpu cycles between 2 breakpoints once. In TMS320F28384D the CCS Profile clock is based on the device's CPU frequency defined by  DEVICE_SYSCLK_FREQ in device.h.

    Can you make sure this is correctly set to the actual device frequency?

    Also can you make sure these 2 options are enabled in the debugger settings options?

    Also, in case this approach doesn't work you can consider

    1. CPU Timer -> This will need to be converted to CPU Cycles by multiplying it by the CPU frequency. You can find the CPU Timer instance in Sysconfig

    2. Toggling a GPIO -> This would be a less ideal but workaround solution if the cycles are to be measured only a small number of times

    Thanks,

    Ira