Code Composer clock

My own tests, using a CC430F5137 connected via a Olimex JTAG-TINY and a MSP-EXP430FR5739, showed that CCS 5.1 does support Clock count. However, when Clock count is selected the target is not run at full speed. Instead, the debugger single steps the target one instruction at a time to get the Clock count measurement. e.g. it took around 10 minutes elapsed time to get the Clock count for a piece of code which executed approx 2000 clock cycles.

On the same hardware IAR Embedded Workbench Kickstart V5.40.3 is able to get the Clock count measurement with the target running at full speed.

Not sure why CCS 5.1 doesn't support the Clock count measurement with the target running at full speed, and haven't found any options to change it.

Alessandro Fulignani said:

Clock count under CCS Version 5.1.1.0003 does not work, of course all the flags that enable this function are on. Any suggestion?

Previously with CCS 5.2 found that the clock count did work with a MSP-EXP430FR5739, but with a MSP-FET430UIF the clock count reported was always zero. The problem when using a MSP-FET430UIF was using the MSP430.dll version 3.2.3.15

Today loaded the latest CCS 5.2 updates, the MSP430.dll was updated to version 3.2.4.5 and with the MSP-FET430UIF the clock count is now working (albeit stepping runs more slowly when the clock count is enabled as previously noted with an Olimex Olimex JTAG-TINY)

Thank you Chester. Now, after the update of my ccsv5 to  5.2.0.00069 the CLK counter is displaying data ! Of course wrong as usual.

It is very fun because in the clk counter my MSP430F 5638 Rev D is faster then a rocket, but when i put the oscillscope on the pin, to chek for the real time....the CPU come back to true.

What can i say? It is better to switch off this function, i think. I will wait for the next update... i will be more lucky !

Thank you !

Test instructions (From the msp430f5xx user's manual)

            add        #33,&temp
            MOV     R5,&temp
            XOR     @R5,&temp
            ADD     4(R4),6(R9)
            XORX.B  2(R6),temp
            XORX     #0A5A5h,temp
            ANDX.B  &temp,4(R6)

Alessandro Fulignani

Chester Gillon said:

However, when Clock count is selected the target is not run at full speed. Instead, the debugger single steps the target one instruction at a time to get the Clock count measurement

So the MSP doesn't count the clock cycles, the debugger tracks the actual execution chain and calculates the cycles based on a cycle table.

Since all MSP instructions have a fixed execution time, this works fine without any hardware cycle counting support.
(On X86, many instrucitons have a variable execution time, depending on parameter values or register contents, so the Pentium got its internal hardware cycle counter)

If course, this kind of cycle counting utterly fails if one tries to measure the excution time of code that waits for a hardware event - especially an external one. Since single-stepping is terribly slow, but external hardware events happen when they happen, the 'counted' execution time of a waiting loop is short, while in full-speed mode, it is way longer (in terms of clock cycles). External events are, beside e.g. incoming SPI /I2C data transfers, also ADC conversion or timer capture or port interrupts.

Jens-Michael Gross said:

If course, this kind of cycle counting utterly fails if one tries to measure the excution time of code that waits for a hardware event - especially an external one.

Jens-Michael Gross said:

Indeed. Clock counting seems to work by reading the actual instruciton and pickign its execution time (in clock cycles) from a table, then executing it with single-stepping.

The MSP430 EEM is documented as containing one or more Cycle Counters (number depends on type of EEM). However, the documentation I have found isn't specific on exactly how the EEM Cycle Counter operates (in terms of when clocked / reset / read out). Not sure if that is because TI haven't released detailed EEM documentation for IP reasons.

Chester Gillon said:

The MSP430 EEM is documented as containing one or more Cycle Counters (number depends on type of EEM).

One more advantage of the 'single steppign' approach: the EEM cycle counter owuld count the cycles of interrupting ISRs too. The single-stepping approach won't as the next 'step' breakpoint would simple ignore the ISR execution.

However, IAR has a built-in simulator which can of course run cycle-counting without the slow single-stepping overhead. It won't work with hardware events, of course. Maybe that's the explanation for your apparently 'full speed' counting.
I don't think that IAR will implement a feature that requires in-depth information for some specific hardware while CCS won't. Of course it' spossible, just not tha tlikely. I'd expect TI taking advantage of new and rather hidden hardware features first. :)

Hi dear,

As explained before i tryed the clk count with fixed instruction taken from the F5xx manual. My test has been done with INT disabled and using the assembly step by step function.

And the clk count differ costantly by several clk count.

As example                                                            CLK Count on manual (SLAU208J)                               CLK displayedt by CCSV5

             add          #33,&temp                                                       5 clk                                                                               3 clk
            MOV         R5,&temp                                                         4 clk                                                                               2 clk                                                                      
            XOR         @R5,&temp                                                     5 clk                                                                               3 clk                                                                     
            ADD         4(R4),6(R9)                                                      6 clk                                                                               5 clk                                                                        
            XORX.B   2(R6),temp                                                       5 clk                                                                               6 clk                                                                        
            XORX       #0A5A5h,temp                                                 6 clk                                                                              4  clk                                                         
            ANDX.B   &temp,4(R6)                                                    7 clk                                                                               6 cllk

Code Composer Studio

 Version: 5.2.0.00069

Licensed to Alessandro Fulignani

Alessandro Fulignani said:

            XORX.B   2(R6),temp                                                       5 clk                                                                               6 clk

I don't think this one is right. The X instrucitons have another cycle for the extension word.
And "XOR x(Rn), TONI" is 6 cycles, so in total 7 for XORX,
.

However, due to instruction prefetch, you cannot really use the cycle counter on one individual instruction.
Nevertheless, the CCS output is obviously wrong. The maximum error due to this is +-1 for the total command chain, depending on the last instruction in the chain. But some individual readings are 2 off, which is simply wrong, even if taking the prefetch jitter into accoount (and on the instructions you used, there is no prefetch at all, since they all write to memory as their last action).

Thank you Mr Jens-Michael Gross.

But i wonder how usuful is a CLK count function that in fact does not work correctly.

Just to be annoying, the errors in 20Bit instructions is +- 4 Bits

Alex

Alessandro Fulignani said:

But i wonder how usuful is a CLK count function that in fact does not work correctly.

Alessandro Fulignani said:

Just to be annoying, the errors in 20Bit instructions is +- 4 Bits

Jens-Michael Gross said:

Looks like they are reading the info from a wrong table. Or, maybe they use the hardware counter and the function is buggy, either the hardware in MSP or the MSP430.dll.
Or both ;)

typedef enum EMEX_MODE {
     /// Device has no Emex module.
     EMEX_NONE = 0,
     /// Device Emex module has two breakpoints.
     EMEX_LOW = 1,
     /// Device Emex module has three breakpoints and range comparison.
     EMEX_MEDIUM = 2,
     /// Device Emex module has eight breakpoints, range comparison, state storage, and trigger sequencer,
     EMEX_HIGH = 3,
     /// Device Emex module has 2 breakpoints and range comparison
     EMEX_EXTRA_SMALL_5XX = 4,
     /// Device Emex module has 4 breakpoints and range comparison
     EMEX_SMALL_5XX = 5,
     /// Device Emex module has 6 breakpoints, range comparison and trigger sequencer,
     EMEX_MEDIUM_5XX =6,
     /// Device Emex module has 8 or 10 breakpoints, range comparison, state storage, and trigger sequencer,
    EMEX_LARGE_5XX = 7
} EMEX_MODE_t;