CCS5.3 Acting strange

Did you disable optimization? 

Regards,
Maciej 

I did turn it off, see below.

Any thing else I can check? here is some more detail below.  The g_time_msec is initialzed and set to zero on line 17, but when main is entered g_time_msec is at 9.  Why? 

when line 22 is executed, g_time_msec changes to zero.

When line 25 gets executed, g_time_msec goes back to 9 Why? there is no interrupts on the background that would do that.

As I step through program the g_time_msec stays at 9.

Can you post the linker .map file, so can check where in memory the global g_time_msec has been placed?

Linker.map file is in project below.

Silver Diamond said:

The g_time_msec is initialzed and set to zero on line 17, but when main is entered g_time_msec is at 9.  Why?

Was this something that worked correctly at one point and then stopped working? Would you be willing to zip up and share your project with us so we can see if it is reproducible at our end?

Sure, the attached is just the I2C communications development for project.  It might be OK when it is running in uC, but I think that CCS shows wrong value.  I have been using IAR kick started to develop it but I would like to be able to work with CSS.

1200.I2C_Develop.zip

Thanks...

Silver Diamond said:

Sure, the attached is just the I2C communications development for project.  It might be OK when it is running in uC, but I think that CCS shows wrong value.  I have been using IAR kick started to develop it but I would like to be able to work with CSS.

I also note that the attached 1200.I2C_5F00_Develop.zip is a cut-down version compared to the previous posted linker map file, in that when the attached project is compiled the .text segment only contains 0x288 bytes whereas the posted linker map had 0xd62 bytes in the .text segment. Has removing some of the code changed the behavior?

On a possibly related subject, http://e2e.ti.com/support/development_tools/code_composer_studio/f/81/p/260400/913428.aspx#913428, sounds like it might be a similar problem in that global variables are also not displaying correctly, but I can't repeat that problem either. 

I did water the project down before sending it out, but that project does the same thing as I describe above.  This is still happening to me.  The program in micro is running correctly but debugger does not seem see the right values.  Are there settings in CCS that I need to change.  Are all of the settings particular to project or are there settings that are common to all of the projects that is causing this?

Is your issue present under both Windows and Linux?

Have not tried windows, but in Linux for sure.  Actually the program runs correctly, its just the right numbers are not getting to the debugging interface.

This might be an os-specific bug. Cannot reproduce on Windows.

I was told that Linux is supported.  How can this be debugged?

I ran it in Windows using MSP430-FET430UIF, same issue, then I connected the MSP-EXP430FR5739, the FR series launch pad, no issue, it worked OK.  Here is the Summary:

MSP-FET430UIF CCS5.3 on Windows 7 - Debugger does not update

MSP-FET430UIF CCS5.3 on Linux Ubuntu 12.03 - Debugger does not update

MSP-FET430UIF IAR Workbench Windows 7 - Debeger does update

MSP-EXP430FR5739 Launchpad - CCS5.3 and Windows 7 - Debugger does update

My FET has white label on the back "V1.4a" and another label says "10086552009R", so what the heck is going on?

Can I assume the FETUIF is bad? 

I have been trying to recreate the problem on CCS 5.3.0.00090 in Windows XP SP3, MSP430 compiler 4.1.5 and a MSP430FR5739 in a MSP-EXP430FR5739.

 Initailly I was debugging using the emulator built into the MSP-EXP430FR5739, and didn't see the problem.

Having now disconnected the MSP-EXP430FR5739 emulator, and debugging via a MSP-FET430UIF connected to the MSP430FR5739 with Spy-Bi-Wire I am now seing the problem where the g_time_msec global variable is not being displayed correctly in the debugger. The MSP-FET430UIF hardware is V1.4a and the MSP430.dll is 3.3.0.6.

Will try and determine the cause.

Will other revisions of FET work OK?  I just ordered https://www.olimex.com/Products/MSP430/JTAG/MSP430-JTAG-ISO-MK2/ I hope it will work, I need to get my project moving.

Chester Gillon said:

Having now disconnected the MSP-EXP430FR5739 emulator, and debugging via a MSP-FET430UIF connected to the MSP430FR5739 with Spy-Bi-Wire I am now seing the problem where the g_time_msec global variable is not being displayed correctly in the debugger.

Thank you for confirming that you are able to reproduce the issue with this configuration. I have contacted some colleagues who are trying it out and investigating at our end as well and we will post additional information as soon as we have an update. Thanks for your patience and I apologize for the delay and inconvenience caused.

Chester Gillon said:

The MSP-FET430UIF hardware is V1.4a and the MSP430.dll is 3.3.0.6.

Debugging a MSP430FR5739 via Spy-Bi-Wire in CCS 5.4 with a MSP-FET430UIF V1.4a and MSP430.dll V3.3.0.6 the first 0x78 bytes of RAM can be affected.

e.g. having downloaded the program and having hit the breakpoint at main the memory is:

Used the CCS memory browser to fill the first 256 bytes of RAM with the pattern DEAD:

Step one source line, and the CCS memory browser says the first 0x78 bytes of RAM change unexpectedly:

The word at 0x1c02 has changed to the value 0x01BA, whereas the other words which have changed have reverted to the reported values prior to the memory fill.

1300.FR_RAM_corruption_fix.zip

Chester Gillon said:

The word at 0x1c02 has changed to the value 0x01BA, whereas the other words which have changed have reverted to the reported values prior to the memory fill.

FramMemoryAccessBaseFR57<MPU>::restoreRam gets called to restore the RAM following an erase operation when the program is downloaded by CCS. The problem is that FramMemoryAccessBaseFR57<MPU>::restoreRam doesn't clear the ramBackup vector, so when it is called on subsequent memory operations it restores "stale" data.

 The proposed correction is to add a ramBackup.clear call into FramMemoryAccessBaseFR57<MPU>::restoreRam thus:

template<class MPU>
void FramMemoryAccessBaseFR57<MPU>::restoreRam()
{
   if (!ramBackup.empty())
   {
    if ( MemoryArea* ram = mm->getMemoryArea("system", 0) )
    {
      size_t count = ramBackup.size();
      vector<uint32_t> tmp(count);
      for (size_t i = 0; i < count; ++i)
        tmp[i] = ramBackup[i];

      ram->write(0, &tmp[0], count) && ram->sync();
    }
    ramBackup.clear();
   }
}

I have attached the modified MSP430.DLLv3_OS_Package-3.2.4.005\DLL430_v3\src\Ti\Dll430\FramMemoryAccessBaseFR57.cpp source file and re-built MSP430.dll in case anyone wants to try it.

Is there a work-around?  Another version of FET?

Silver Diamond said:

Is there a work-around?

Have you tried the MSP430.dll posted by Chester Gillon? That is the only available workaround at the moment.
Just save the MSP430.dll in your <ccs_install_dir>\ccsv5\ccs_base\DebugServer\drivers directory to a different name and replace it with the one posted in this thread. I verified that the updated one works with your test project. You can use this as a temporary fix until TI releases an official update.

I am using Linux, any way to compile the Linux drivers?  I do not know how to do it.

Silver Diamond said:

I am using Linux, any way to compile the Linux drivers?  I do not know how to do it.

Silver Diamond said:

Will other revisions of FET work OK?  I just ordered https://www.olimex.com/Products/MSP430/JTAG/MSP430-JTAG-ISO-MK2/

If you want Linux support, the Olimex web site doesn't have a libmsp430.so for Linux. For Linux support the Olimex web site has a link to http://freemsp430debug.sourceforge.net/ which say it supports the (now obsolete) OLIMEX MSP430 JTAG ISO. Not sure if it will work with the newer MSP430-JTAG-ISO-MK2.

Thank's a lot Chester Gillon!!

Chester Gillon said:

FramMemoryAccessBaseFR57<MPU>::restoreRam gets called to restore the RAM following an erase operation when the program is downloaded by CCS. The problem is that FramMemoryAccessBaseFR57<MPU>::restoreRam doesn't clear the ramBackup vector, so when it is called on subsequent memory operations it restores "stale" data.

The proposed correction is to add a ramBackup.clear call into FramMemoryAccessBaseFR57<MPU>::restoreRam thus:

AartiG said:

We are also tracking the bug internally at TI and the fix should be in an upcoming release. At this time we do not have an exact date but as soon as we know when the fix will be available we will post an update.

Looking at the source code shows the classes for programming FRAM devices have been re-factored, such that the previous FramMemoryAccessBaseFR57<MPU>::restoreRam and FramMemoryAccessBase<MPU>::restoreRam functions which had the bug no longer exist.

I assume that there will shortly be a CCS update which makes MSP430.dll v3.3.1.3 (or later) available to fix the problem.

Edit: While there has been no update for CCS yet, Download DLL Developers Package v3.3.1.3 Released 06/28/2013 contains a pre-compiled MSL430.dll v3.3.1.3 (but only for Windows)