Troubles to measure CPU clocks in CCS 5.5

Hi Haroldo,

Thank you for bringing this problem to our attention, and I apologize for any delays it is causing in your development. 

I have tested the clock feature in Code Composer Studio v5.5.0.00077 in an attempt to reproduce your issue.  I found that the clock feature worked with some devices, but not others.

My results:

1. MSP430G2231 (Value Line):     FAIL (Garbage cycle counts like those you show above)
2. MSP430G2553 (Value Line):     FAIL (Also garbage cycle counts like those you show above)
3. MSP430F5529 (x5xx Series):    PASS (Valid cycle counts - 1 cycle per NOP)
4. MSP430FR5969 (Wolverine Series):    PASS (Valid cycle counts - 1 cycle per NOP)

I also tested with two different eZ-FET emulators and observed the same results with each.

I am going to pass this information along to our CCS team to see if they can resolve this issue.  Would you be able to elaborate on what your specific test setup and fail case is so that I can provide that feedback to the CCS team?

It would be helpful to know the following:

1. Device under test (MSP430xxxxx?)

2. Hardware platform (Target board, LaunchPad, custom board)

3. Emulator used (MSP-FET430UIF, eZFET, ect)

4. Version of CCS (v5.5.xxxx?)

5. Windows version (XP, Vista, 7, 8 ?)

Thanks for your patience while we work through this.  As an alternative benchmarking method, you can toggle GPIO pins upon entry and exit of the software routine of interest, and capture those edges with a logic analyzer or oscilloscope.  Then you would just need to divide out by the clock period to determine the approximate number of cycles (keep in mind that this will be a few cycles off due to the toggle instructions).

Hopefully there will be a fix for this.

Regards,
Walter

Hi Walter Schnoor, thank you for attention.

I noted this error when i was using the launchpad Value line G2 with the MSP430G2553. The version of CCS is v5.5.0.00077, the same of your test. In the last version (5.4) this doesn't happen.

I finished other test with the MSP430G2955, using the MSP-FET430UIF and a custom (hand made) board. The error persist. I use the 4-wires mode for the JTAG.

In both tests the code work fine, just de clock don't work fine. Other thing, with the clock enabled, after you stop in a breakpoint or pause de execution you can't use the "soft reset". Whean I use the soft reset the compiler break in a indetermined point and just return after I disable the clock.

Tomorrow i will test with the MSP430F5172 in other custom board.

I guess that is interesting make this test with the new launchpad and other members of Value line like G2452.

My operational system is the Win 7 64bits

Hi, i realized the same test on the MSP430F5172 and the result is the same.

I don't know if this is a bug or my mistake but when i tried to debug the same project on the MSP430F5172 with two break-points inserted (in the _nop();) the ccs reported this error.

I'm using a custom board, the MSP-FET430UIF and I configurated the FET to 3300mV at CCS.

Devices tested
- MSP430G2553 - FAIL
- MSP430G2955 - FAIL
- MSP430F5172 - FAIL

Haroldo Amaral said:

I don't know if this is a bug or my mistake but when i tried to debug the same project on the MSP430F5172 with two break-points inserted (in the _nop();) the ccs reported this error.

The executiuon apparently stops inside the C startup code, before entering main. The startup code is linked from the runtime library which is part of the compiler/linker combo. The debugger gets information that the breakpoint is within this startup code, but it doesn't have access to the source code that was used to build the library (of course). All you can do is to look at the assembly code of these functions.

 Walter Schnoor, You saw the second test with de MSP430F5172?

Thanks. 

Not that this helps solve the problem, but I too am having these clock issues with the MSP430G2553 and Lanchpad with CCSv5.  Unfortunately I started a similar thread in the forums 2 days ago before being pointed here, but just thought I would post and confirm the bug still persists on version 5.5.0.00077 of CCS.

Thanks

-Kyle

Confirming Haroldo's bug:

Lauchpad G2

CCS version: 5.5.0.00077

Windows 8 - 64 bits

Additional observation: when the clock is enabled, the board doesn't run (blink program), despite the fact that the debugger shows that the program is running.

Kyle,

Thanks for sharing the details of your bug as well, we are looking into a solution for this.

Daniel,

With regard to your observations on program execution: when the Code Composer Studio "Clock" feature is enabled for cycle counting, the actual perceived program execution time is drastically longer (several orders of magnitude) than if the device were to free run.  This is due to the JTAG-initiated execution breaks that are being inserted to count cycles in this device.  If you allow the device to run for a longer period of time (10's of seconds), you should see the program executing.  However, since you mention that you are running the blinky code (which should not be more than a few lines), the execution time from breakpoint to breakpoint to do that should not be more than a few seconds- so maybe there is another issue here.  Are you using a specific MSP430Ware example project for the blinky application?

Walter

 Walter, thanks for paying attention to the problem.

 My program (see below) is a slight modification of the original blinky program to make both LEDs flashing slowly.

 Here is what I observe, after a hard reset:

  Both LEDs flash once (green, red, green) and then, the green LED remains indefinitely ON (a few minutes).

#include <msp430.h>

int main(void) {

 WDTCTL = WDTPW | WDTHOLD; // Stop watchdog timer

 P1DIR |= 0X41;   // Set P1.0 and P1/6 to output direction

 P1OUT = 1;

 BCSCTL1 -= 4;   // slowing the blinking speed

 for(;;) {

  volatile unsigned int i; // volatile to prevent optimization

  P1OUT ^= 0x41;  // Toggle P1.0 and P6.0 using exclusive-OR

  i = 10000;  // SW Delay

  do i--;

  while(i != 0);

 }

  return 0;

}

Hi.

I performed the same test using the Lauchpad Value line with a MSP430G2553 in the beta version of CCS6 and e error persisted.

Daniel Herman said:

  volatile unsigned int i; // volatile to prevent optimization

Daniel Herman said:

  P1OUT ^= 0x41;  // Toggle P1.0 and P6.0 using exclusive-OR

Daniel Herman said:

 BCSCTL1 -= 4;   // slowing the blinking speed

Haroldo,

I have the same problem with launchpad and CCS5.5. I am a little worried about this bug in CCS6...

Regards

Mirek

Testing the CCS 6 beta I found the same bug for both, launchpad and MSP430UIF.

I'm thinking of back to the version 5.4

I just wanted to add that I'm having the same exact problem and symptoms with the exact same device and tool.

-------------------------------------------------------------

Problem: Profile clock seems to be highly inaccurate

CCS version: 5.5.0.00077 running on Windows Vista

MCU: MSP430G2553 running on the MSP-EXP430G2 development tool

My profile clock says that it takes 65,540 cycles to set P1.0 to the output direction. That's for this tiny line of code: "P1DIR |= 0x01." This behavior persists for every line of code in the program, but grows ever higher.

The program is "blinky," the example program in MSP430ware supplied by TI. 

We are facing the same problem with an MSP430F2274 (same CCS version, Windows XP).

Best regards,

Eric.

Same problems with many of our customers here.
Any solutions?
Should we use the older versions of CCS?

Prad

Hi Prad,

I asked our team about the status of this issue. It sounds like CCSv5.5 is the only version affected, so reverting to 5.4 is an option. However, I've also been told that the fix has been implemented in CCSv6 which will release this year. The Beta 3 version of CCSv6 is available here if you would like to try it: http://processors.wiki.ti.com/index.php/Category:Code_Composer_Studio_v6

I hope this helps, and sorry for the inconvenience that this issue has caused.

Regards,

Katie

Hi Katie,

Thank you for the confirmation.
For time being we shall use the older version(V5.4).
Please let us know if there are any updates on this.

Regards
Prad

I want to inform you that I am a user CCS v5.4, and the problem exists in that version too.

The source of this problem might not be CCS; it might be the emulation firmware supplied with the USB driver. This is what I mean.

I don't think the emulator for these LaunchPads have any emulation firmware loaded in them when shipped from the factory. I think the firmware is shipped with CCS. CCS may come with the USB driver for those kits having a built-in emulator, so when you connect your USB-based emulator to your computer, your computer establishes a connection by creating a COM port with that USB driver, and inside the driver, sort of, is the firmware for the emulator. After the USB driver installation, CCS recognizes the new USB-based emulator then removes the firmware from the driver and then loads it into the emulator.

At least that's how it works with the external emulators (programmer-debuggers) TI sells.

Somebody please correct me if I'm wrong.

The problem still happens in the new CCS 6 beta 3.

I tested with a Launchpad Valueline MSP430G2553, Win 7 64.

I didn't mention an important factor in all this. Each MSP430 has it's own unique emulation module the provides your IDE the ability to step through each instruction, set breakpoints, and such while testing and debuging. I hope that module isn't the source of this problem.

I wonder if this bug has been formally reported to the CCS and MSP430 QA engineering departments?

my Debug Server component: 6.0.0.506.

Thanks

Good news, in the beta version of CCS 6 (beta 4) the count of the CPU cycles works fine.

I tested with the MSP430G2955 using the MSP-FET430UIF and works fine. I will test with the launchpad valueline G2.

This new version have good improvements. Now I can study and test the optimization of code.

Device under test: MSP430G2553

Hardware platform: MSP430 Launchpad

Version of CCS: v5.4

Windows version: XP

Fail with __delay_cycles(); when debugging :'(