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.

Basic Clock Module is in different state when using the debugger

Other Parts Discussed in Thread: MSP430F2618, MSP430F2619, MSP430F2013

Dear Wizards,

   This code is executed during startup (it is called from xdc_runtime_Startup_reset__I )

static void spin_100_uS (void) {
volatile unsigned char count = 79u; /* Empirically determined */
while (--count > 0u)
; /* Busy Wait */
}


extern "C" {
void CSL_Init_Basic_Clock (void)
{
int index;

BCSCTL1 = 0xFDu; /* ACLK <-- LFXT1CLK / 8; XT2 Off; RSELx=13($D) */
BCSCTL2 = 0xC0u; /* MCLK, SMCLK <-- DCOCLK/1 */
BCSCTL3 = 0xF0u; /* External Clock Source */

for (index = 0; index < 3; ++index) { /* Try 3 times */
IFG1 &= ~0x02u; /* Clear Oscillator fault flag */
spin_100_uS(); /* Wait at least 50 uS */
if (0u == (IFG1 & 0x02u)) {
break;
}
}
DCOCTL = 0x80u; /* DCO = 4 */
}


void CSL_Disable_Watchdog (void)
{
WDTCTL = 0x5A00u + WDTHOLD + WDTSSEL;
}

} /* extern "C" */

When the target is running standalone the clocks are correct.  When debugging the clock module always has the PowerUp Reset values:
DCOCTL = 0x60
BCSCTL1= 0x87
BCSCTL2= 0x00
BCSCTL3= 0xF0

 It feels like I have not setup the debugger properly.  Any suggestions?

  Target: MSP430F2618
Debugger: MSP-FET430UIF
     CCS: 5.2.0.00069
Compiler: 4.1.0
    BIOS: 6.33.4.39
RTSC/XDC: 3.23.3.53 

Thank you,

Fred

  • Fred,

    i had similar probelm from other customer before, and i believe this is a DLL issue however this is still under investigation. Which MSP430 DLL version are you using?

    http://processors.wiki.ti.com/index.php/MSP430_FAQ#Which_version_of_the_MSP430.DLL_is_used_in_my_IDE_.28IAR.28CCS.29.3F

    You can try to download the older DLL version here: http://processors.wiki.ti.com/index.php/MSP430_JTAG_Interface_USB_Driver

    I'll check with the tools team and come back to you later.

  • Hi Leo,

       I found this MSP430.DLL file:

    C:\ti\ccsv5\ccs_base\DebugServer\drivers\MSP430.dll 2,701KB Tuesday, October 18, 2011, 11:23:00 AM Version 3.2.1.9

    I'd be glad to try a different version.

    Regards,

    Fred

  • Hi Leo,

       I installed the earlier DLL file (ie replaced version 3.2.3.15 with 3.2.1.9) and the clock module is keeping my programmed values.

    Thank you for the help!

    Regards,

    Fred

  • I had a similar problem.

     I "Upgraded" to IAR 5.40.7 and to the new DLL for the FET ("version 3") . I found that after a break, DCOCTL, BCSCTL1 and BCSCTL2 ended up with the PUC (power up clear) values. I also noticed that I was having a "Stack Overflow" error every time I stopped the debugger. Even when my code was a minimal infinite loop doing nothing! In addition, the Workbench did not allow me to use the Enhanced Emulation Mode for my part (MSP430F2618). I was able to this with an older version of the Workbench.

    After a lot of aggravation (I tore my code appart, to no avail) and several exhcanges with IAR support, I decided to backtrack to IAR 5.30.4 and to the older DDL version of the FET ("version 2").  All my problems went away!

    I suspect IAR is not handling the new DLL for the FET properly. But that is just my guess.

    Since I am going to get started on another project, should I try to switch to CodeComposerStudio, v5? Any suggestions?

    Thank you!

     

     

    I backtracked to IAR 5.30.4.

    I also noticed that my target (MSP430F2618) was not supported

  • Hi Andres,

       I am also using the '2618.

       After you (re-) install 5.40.7 check what version of MSP430.dll is being used.  The dll might be found in:
    C:\Program Files\IAR Systems\Embedded Workbench 6.0\430\bin
    In Windows explorer just "hover" over the file for a few seconds and the File Version (and other information) will be displayed.  If it is version 3.2.3.15, go to the TI website referenced by Leo's email and download version 3.2.1.9.  Rename the original dll to something like MSP430_3_2_3_15.dll and then copy the downloaded version into the .\bin directory.  Finally, restart Embedded Workbench and see if your problem goes away.  Mine did.  If IAR is still using a version 2.x.y.z MSP430.dll this probably won't work.

    When IAR released 5.3 they discontinued support for their PowerPac RTOS so I was motivated to switch to CCS.  This is a non-trivial change, taking me about a month's work of effort over a 10 week period (your mileage is sure to vary ;-)  The MSP430F2618 is not yet officially supported and although it does work, I still get warnings and the occasional error message which can be disconcerting.

    Best Wishes,

    Fred

  • Hi Fred,

    I followed your instructions. I downloaded DLL version 3.2.1.9 and I am using IAR 5.40.7 and ... IT WORKS! No more corruption of the clock registers! Thank you for your help.

    On the other hand, IAR 5.40.7 dropped support for Enhanced Emulation Mode for the '2618. So, the incentive to remain at IAR 5.30.4 is still high. Plus, moving up to 5.40.7 forced me to use a new version of file "io430x26x.h" which is not as convenient to use as the old version. I do not know why they changed it.

    I do agree with you that switching to Code Composer Studio may be time consuming. Now that you have done it, was it worth your effort? I need to decide on this issue this week, I start on a new project next week. Please let me know your thoughts.

    Regards,

    Andres

  • Hi Andres,

       I am glad that Leo's work around worked as well for you as it did for me!   I'm inclined to stand aside and let a TI person take my place and perhaps give us an update on MSP430F2618 support in SYS/BIOS.

    To answer part of your question on CCS v5, the compiler itself and the IDE work well and the '2618 is completely supported.  There is even a configuration tool called GRACE, which I haven't used, to help setup all the multiplexed pins and peripherals of the MSP430.  The editor in the IDE (Eclipse) is not particularly good for multi-file editing although it works very well while doing compile-debug-edit sessions.  If you are doing a battery operated application the compiler provides remarks about code which is not power efficient.  For a list of some of the differences between the compilers look at the SLAU157T manual (Code Composer Studiov5.1 User's Guide for MSP430).  Was it worth the effort?  I really didn't have a choice, so of course for me, the answer is yes.

    Regards,

    Fred

  • I ran into the same issue (clock module change after restart from halt)  with a MSP430F2619.

    As others found reverting to an older DLL file seems to correct the issue.

  • Hi all,

    just to add information on this issue. so basically reverting the DLL to an older version was the fast workaround which i found myself. However after talking to the MSP430 tools team, the suggested workaround is to use the whole complete CCS IDE package with the older version of DLL. What i understand is that the DLL API between the different version might change, and changing the DLL only could fix one problem but cause another problem to arise due to the incompatibility of the DLL API which is used by the CCS IDE.

  • Hi all,

    New information from the tools team: this bug is already known, and will be fixed in the next release of CCS/IAR version (which should be soon enough). The message is also still the same: use the DLL together with the whole IDE package, since changing the DLL only can fix one thing, but cause another things to rise.

  • Hi,

    there is an update for the MSP430 Emulators (5.2.0.9 -> 5.2.1.4) available for CCSv5.2 (Help->Check for Updates). It updates the debug stack msp430.dll (3.2.4.5). Did anyone already installed this update? Does this one fix this clock register bug?

    I have tried to find a changelog but without success. The only information I found is that the cycle counter seems to work now:

    http://e2e.ti.com/support/microcontrollers/msp43016-bit_ultra-low_power_mcus/f/166/p/184025/707105.aspx#707105

    Regards,

    Christian

  • Christian Steffen said:
    Does this one fix this clock register bug?

    With CCS 5.2 and MSP430.dll v3.2.3.15, using a MSP430F2013, confirm that the Basic Clock Module registers get corrupted when single stepping.

    Changing to MSP430.dll v.3.2.4.5 and the Basic Clock Module resisters no longer get corrupted when single stepping. i.e. seems to have fixed this problem.

    Christian Steffen said:
    I have tried to find a changelog but without success.

    Agree that the update to MSL430.dll v.3.2.4.5 installed by the CCS update doesn't include a changelog for the MSP430.dll.

    However, slac430c (the source code for the MSP430.dll) does contain the following in it's revisions.txt:

    Rev 3.2.4.002

      Bug Fixes:
    - Correct DLL database entry for min. flash voltage on 471x devices
    - Fixed single stepping issues on L092
    -Fixed DCO calibration Bug, that the original DCO setting was not restored after debug break(device running slower after read)
    - Fixed DLL database entry for the EEM level of the MSP430F5228
    - Fixed disassembly window issues on MSP430FR59xx devices
    - Fixed issues with Fast port close/open

**Attention** This is a public forum