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/MSP430FR2675: CCS v9 - problem with profile clock using Captivate library functions

Part Number: MSP430FR2675
Other Parts Discussed in Thread: MSP-FET

Tool/software: Code Composer Studio

Hello,

During debugging in CCS 9.2.0 with MSP-FET i am trying to measure the time between two breakpoints using the profile clock. There seems to be a problem counting CPU cycles in case CapTivate library functions are used.

In the following example main_loop_timer counts the milliseconds that are incremented in Timer0_A3 ISR which is called with period 1ms. The endless main loop has a defined period of 10ms. At Breakpoint2 the profile clock correctly shows 159922 CPU Cycles (=10ms @16MHz):

while (1) {

   timer_start(&main_loop_timer);   <-- SWBreakpoint1: CPU cycles = 0

   while (timer_get(&main_loop_timer) < 10);    // wait the remaining time of the main loop period

   timer_stop(&main_loop_timer);   <-- SWBreakpoint2: CPU cycles = 159922
}

Now if I add a call to CapTivate library function CAPT_updateSensorWithEMCAuto() to the loop, the profile clock shows '123064' at Breakpoint2 and not the expected 159922 CPU Cycles:

while (1) {

   timer_start(&main_loop_timer);   <-- SWBreakpoint1: CPU cycles = 0
   /* update and processing of the touch sensor data */
   CAPT_updateSensorWithEMCAuto(&CS_0, g_uiApp.ui8AppLPM);

   while (timer_get(&main_loop_timer) < 10);    // wait the remaining time of the main loop period

   timer_stop(&main_loop_timer);   <-- SWBreakpoint2: CPU cycles = 123064
}

A measurement of function CAPT_updateSensorWithEMCAuto() itself returns 6220 CPU Cycles.

Do you have an idea why the library function manipulates the result of the measurement?

Thanks
Ralph

 

  • Hi Ralph,

    If you manually step through instead, do the cycle count values become more in line with what is expected?

    Thanks

    ki

  • Hi ki,

    Thank you for your response. Manual stepping gets closer to the expected CPU cycles (=147600), but there are still a lot of cycles lost.

    What can be the reason for that and is there another workaround than manual stepping?

    Thanks

    Ralph

  • Ralph Braeumer said:
    What can be the reason for that and is there another workaround than manual stepping?

    It is hard to say without more details.

    If it is not too much trouble, can you try installing the latest CCS 10.1.0 and see if the same issue occurs? You can install in a separate directory and keep you 9.2.0 intact.

    Thanks

    ki