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/MSP430I2041: Improper Treatment of Global Variable in Interrupt Service Routine

Part Number: MSP430I2041
Other Parts Discussed in Thread: MSP-FET, MSP430F6659, MSP430F2274, MSP430WARE

Tool/software: Code Composer Studio

I have a small program for the MSP430i2041 chip that has some bizarre
behavior in its timer interrupt service routine (ISR). I am using CCS
version 9.2.0.00013 to which I have only recently upgraded. The timer ISR
is shown in its entirety at the end of this post.

The problem concerns the value of a global variable at interrupt-time.
I have an unsigned integer global variable named "sCountdown_dS" to which
I assign the value 100 at compile time.

When I run this program under the debugger, and examine the value of
sCountdown_dS as soon as the debugger stops at the entry-point of the
program, the variable does indeed contain the value 100. However, when
I let the debugger run to the first instruction in the ISR, the variable
sCountdown_dS contains the value ZERO. Oddly, the ISR has another
global variable (named sInitDelay_dS) that DOES have the correct value
upon entry to the ISR. It's apparently just sCountdown_dS that has the
problem.

The ISR also does not work properly, and it should, so I conclude that
this is a problem with the compiler or linker, not the debugger.

It seems as if sCountdown_dS is not being treated as a global variable,
even though sInitDelay_dS is. Strange! Any ideas? Are there any known
bugs associated with this?

-eNick

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

// TimerGen.c

//General program timer ISR for program CCSi2041

#include <msp430.h> //include TI definitions
#include "CCSi2041.h" //include my own program definitions


//Begin definition of global variables
//
U16 sInitDelay_dS = INIT_DELAY_DS; //program-initialization delay in dS
U16 sInitDoneFlag = 0; //will be non-zero JUST ONCE at end of program-initialization
U16 sCountdown_dS = 100; //countdown to next dS
U16 sAckhold_dS = 0; //"Ack Holddown" time in dS
U16 sAckHoldFlag = 0; //if non-zero, "Ack" held down long enough to clear counters
U16 sAckNowFlag = 0; //non-zero when "Ack" pushbutton is pressed
//
//End definition of global variables


//Begin references to external global variables
//
//
//End references to external global variables

#pragma vector=TIMER0_A0_VECTOR
__interrupt void TA0_ISR(void)
{
//get here 1,000 times per second

//will now countdown towards the next dS
sAckNowFlag = 0; //zzzz superfluous 1st instruction in ISR
sCountdown_dS--; //countdown towards the next dS
if (sCountdown_dS != 0) return; //all done if not at next dS yet

//will now perform everything that must be handled each dS
sCountdown_dS = 100; //reload the dS countdown

FlashI (); //handle the Error-LED flashing

//will now handle the program-initialization delay
if (sInitDelay_dS) //if the initialization-delay timer is still running
{
sInitDelay_dS--; //count this additional dS
if (!sInitDelay_dS) //if the timer has just now timed out
{
sInitDoneFlag = 1; //flag this for MainLoop
}
}

//will now handle the "Ack" pushbutton
if ((ACK_PB_PORT & ACK_PB_BITP) == 0) //if the "Ack" pushbutton is pressed
{
sAckNowFlag = 1; //flag this condition
FlashNum (0); //stop Error-Flashing upon "Ack"
sAckhold_dS++; //count this dS
if (sAckhold_dS >= ACK_HOLD_DS) //if "Ack" PB held down long enough
{
sAckHoldFlag = 1; //set the "Ack-held-down" flag
sAckhold_dS = 0; //clear the "Ack Holddown" timer
}
}
else //but if "Ack" is not pressed
{
sAckNowFlag = 1; //flag this condition
sAckhold_dS = 0; //clear the "Ack Holddown" timer
}
}

  • I suppose I should add that, yes, I have checked VERY carefully to make sure that no other

    part of the program is messing with the variable in question!

    -eNick

  • Have you tried making it volatile?

  • >Have you tried making it volatile?

    Yes, and it makes no difference. Thank goodness for that, because I have quite
    a few other globals and I SHOULDN'T HAVE TO DO THAT ANYWAY. :-)

    HOWEVER, I did try moving the variable to the top of my program's main code module
    and declaring it "extern" in the ISR, and everything suddenly started working fine!
    My conclusion is that there is definitely a bug in the new v9 of CCS.

    Thanks much for your interest, Keith.

    -eNick

  • Actually, you should do that. Any global used in an ISR needs to be marked volatile so the compiler knows to load it every time it is used.

    otherwise you can have problems with things like this:

    main()

    {

    while(global_flag_set_in_ISR)

    {

    // Do stuff

    }

    }

    If global_flag_set_in_isr is not volatile, the compiler will not bother to keep reading it every time the while loop comes around, it will treat it as a constant.

  • Keith is correct to say that volatile should be used in this case.  For further detail, please see this article about volatile.

    Thanks and regards,

    -George

  • >Actually, you should do that. Any global used in an ISR needs to be marked volatile
    >so the compiler knows to load it every time it is used.

    True in general; not true for globals declared and written in the ISR and
    USED ONLY in that ISR.

    Shown below is the disassembly. The code is reading sCountdown_dS just fine.
    However, the code is not reading the correct value. There appears to be a bug
    somewhere in the CCS Linker or the C runtime initialization code (or maybe some
    function prolog code that I don't get to look at?).

    Here is a real eye-opener: I decided to verify my prior claim by moving sCountdown_dS
    back into the ISR itself. I did just that, and this time IT WORKED FINE! Hmmm. Okay,
    there is a slight difference: this time I made sCountdown_dS the 6th (and last) global
    variable declared in the ISR, while the previous (non-working) time it happened to be
    only the 3rd (of 6) global variables in the ISR. And THAT IS THE ONLY DIFFERENCE!
    Note that the disassembly (shown below) of this ISR code is identical for both the
    working and the non-working placement of the global variable.

    TA0_ISR():
    85aa: 120F PUSH R15
    85ac: 120E PUSH R14
    85ae: 120D PUSH R13
    85b0: 120C PUSH R12
    85b2: 120B PUSH R11
    33 sCountdown_dS--; //countdown towards the next dS
    85b4: 8392 022E DEC.W &sCountdown_dS
    85b8: 2024 JNE ($C$L3)
    37 sCountdown_dS = 100; //reload the dS countdown
    85ba: 40B2 0064 022E MOV.W #0x0064,&sCountdown_dS
    39 FlashI (); //handle the Error-LED flashing
    85c0: 12B0 8436 CALL #FlashI
    42 if (sInitDelay_dS) //if the initialization-delay timer is still running
    85c4: 9382 022A TST.W &sInitDelay_dS
    85c8: 2405 JEQ ($C$L1)
    44 sInitDelay_dS--; //count this additional dS
    85ca: 8392 022A DEC.W &sInitDelay_dS
    85ce: 2002 JNE ($C$L1)
    47 sInitDoneFlag = 1; //flag this for MainLoop

    Yes, I did go back and forth twice more, to be sure that my observations are
    reproducible.
    I should tell you, Keith (and George), that I find this whole CCS product flakier
    than a Betty Crocker corn muffin. For instance, try scrolling the disassembly code
    to the very top, and you will see the scrollbar thumb jump back an inch or so when
    you release it. This Eclipse stuff is strictly amateur hour compared to my beloved
    Visual Studio. :-)

    -eNick

  • Throw a few million at Eclipse and it will probably improve a bit!

  • When the code fails, how do you know?  Exactly what do you look at?

    Regarding ...

    user6131995 said:
    Note that the disassembly (shown below) of this ISR code is identical for both the
    working and the non-working placement of the global variable.

    I'd like to see that in more detail.  For the source file which contains this ISR, please follow the directions in the article How to Submit a Compiler Test Case.

    Thanks and regards,

    -George

  • >When the code fails, how do you know? Exactly what do you look at?

    I look at my blue LED which fails to blink. :-) Seriously, when this code works,
    it just blinks an LED (either a steady ON/OFF heartbeat if there has been no error,
    or a numeric blink-code if there has been a specific error).
    When the LED is not blinking (code not working), I can go into the ISR with the
    CCS debugger and clearly see that the global variable "sCountdown_dS" has the WRONG
    value (of zero) as soon as the ISR is entered (ie, the interrupt occurs), yet it
    has the correct value (100 decimal) just before the ISR is entered.
    Note again that this code can be transmogrified from working to non-working (and
    back) by simply rearranging the order of the global veriables at the top of the
    ISR code module, and this is reproducible.
    I am using register optimization (the lowest optimization that ya can get except
    "off"), so if that were the cause I would expect the problem to occur when the
    compiler runs out of registers, but the actual behavior here is the opposite of
    that -- that is, the problem goes away if the variable is placed late in the list.
    (I cannot try zero optimization, because that causes my program to trip all over
    itself on this very slow MCU.) Besides, optimization is a compiler thing, and
    the disassembly of the compiler output looks just fine. Again, the disassembly
    output is THE SAME whether the code is working or non-working. Thus, I conclude
    that this is a Linker issue, not a compiler issue. It's also not a debugger issue
    because the problem occurs whether or not I am debugging.


    >I'd like to see that in more detail. For the source file which contains this ISR,
    >please follow the directions in the article How to Submit a Compiler Test Case.

    I read that article, but I don't have the time for all that today. Besides, the
    article is CCS v7.1 specific and I am using v9.2.0.00013 and no longer have access
    to my previous version (which was newer than 7.1 anyway). Finally, that article
    clearly states that it does not cover linker errors, and this seems to me to be
    a linker error. How can it be a compiler error if the disassembled code looks
    fine?
    Best I can do right now is provide the ISR code module in its entirety below.
    You can change this from working to non-working, at will, merely by moving
    sCountdown_dS up to being the 3rd global variable declared. (I hope you guys DO
    find some stupid error in this code and have a good laugh on me.)

    -----------------------------
    // TimerGen.c

    //General program timer for program CCSi2041

    #include <msp430.h> //include TI definitions
    #include "CCSi2041.h" //include my own program definitions


    //Begin definition of global variables
    //
    U16 sInitDelay_dS = INIT_DELAY_DS; //program-initialization delay in dS
    U16 sInitDoneFlag = 0; //will be non-zero JUST ONCE at end of program-initialization
    U16 sAckhold_dS = 0; //"Ack Holddown" time in dS
    U16 sAckHoldFlag = 0; //if non-zero, "Ack" held down long enough to clear counters
    U16 sAckNowFlag = 0; //non-zero when "Ack" pushbutton is pressed
    U16 sCountdown_dS = 100; //countdown to next dS
    //
    //End definition of global variables


    //Begin references to external global variables
    //
    //
    //End references to external global variables


    #pragma vector=TIMER0_A0_VECTOR
    __interrupt void TA0_ISR(void)
    {
    //get here 1,000 times per second

    //will now countdown towards the next dS
    sCountdown_dS--; //countdown towards the next dS
    if (sCountdown_dS != 0) return; //all done if not at next dS yet

    //will now perform everything that must be handled each dS
    sCountdown_dS = 100; //reload the dS countdown

    FlashI (); //handle the Error-LED flashing

    //will now handle the program-initialization delay
    if (sInitDelay_dS) //if the initialization-delay timer is still running
    {
    sInitDelay_dS--; //count this additional dS
    if (!sInitDelay_dS) //if the timer has just now timed out
    {
    sInitDoneFlag = 1; //flag this for MainLoop
    }
    }

    //will now handle the "Ack" pushbutton
    if ((ACK_PB_PORT & ACK_PB_BITP) == 0) //if the "Ack" pushbutton is pressed
    {
    sAckNowFlag = 1; //flag this condition
    FlashNum (0); //stop Error-Flashing upon "Ack"
    sAckhold_dS++; //count this dS
    if (sAckhold_dS >= ACK_HOLD_DS) //if "Ack" PB held down long enough
    {
    sAckHoldFlag = 1; //set the "Ack-held-down" flag
    sAckhold_dS = 0; //clear the "Ack Holddown" timer
    }
    }
    else //but if "Ack" is not pressed
    {
    sAckNowFlag = 1; //flag this condition
    sAckhold_dS = 0; //clear the "Ack Holddown" timer
    }
    }

  • BTW folks, that code module I posted a minute ago was properly formatted (indented) by me; it was the forum

    software that smashed everything against the left-hand side.

    -eNick

  • You need to use the code insert option the little box with the </>

  • user6131995 said:
    the disassembly output is THE SAME whether the code is working or non-working.

    That's confusing.  If the global variables are at different addresses, then the disassembly will have minor differences in the instruction encoding of those addresses.

    user6131995 said:
    I read that article, but I don't have the time for all that today. Besides, the article is CCS v7.1 specific and I am using v9.2.0.00013 and no longer have access to my previous version (which was newer than 7.1 anyway).

    The directions in the article were developed with CCS 7.1.  But they can still be used with all versions of CCS since then.  The build options interface has changed very little in that time.

    user6131995 said:
    Best I can do right now is provide the ISR code module in its entirety below.

    Thank you, but I cannot build it.  I need everything requested in the article. It only a takes a few minutes.  I'd appreciate the effort.

    What about the watchdog timer?  Is it going off?

    Thanks and regards,

    -George

  • >That's confusing.  If the global variables are at different addresses, then the 
    >disassembly will have minor differences in the instruction encoding of those addresses.
    
      Well, yeah, okay you win that one.  But that is the ONLY difference, as you can see
    below.
    
    
    >Thank you, but I cannot build it.  I need everything requested in the article. 
    
      Geez, George, I thought you guys had all gone away and just written me off as a crazy.
    I did not realize that you were going to actually try to BUILD it.  (I was mostly
    hoping you would say "yeah, 146 other guys have reported that problem and it will get
    fixed soon".)
      The problem that I have now is that I cannot find that article again.  You'd think
    it a simple matter of looking at my saved emails, but that does not apply to this
    demented GMail account.  If you absolutely must have me conform to that article's
    requirements, please send me that link again.
      In an effort to keep this moving, I have massaged my code to eliminate a bunch
    of extraneous stuff from the ISR, and it no longer uses my own program header file.
    You should be able to build this one easily, without requiring me to actually
    read that article. :-)
    
      I have carefully tested this abbreviated ISR, and it has the SAME (lousy)
    behavior as the original ISR code.  Specifically, with the global variable
    "sCountdown_dS" as the 3rd listed global variable, this ISR does NOT WORK,
    but with the variable moved to the 6th (last) position in the list then the
    ISR WORKS FINE.  Again, the symptom of "not working" is that my LED does
    not blink at all, and this can be easily confirmed with the debugger.  The
    debugger will show that sCountdown_dS has the initial value 100 in both the
    working and non-working versions.  In the working version, sCountdown_dS still
    has the value 100 upon initial entry to the ISR.  However, in the non-working
    version, sCountdown_dS has the value ZERO upon initial entry to the ISR.
    
    
    >What about the watchdog timer?  Is it going off?
    
      No WDT.  I turn it OFF at the very beginning of my main program and I leave
    it OFF.
    
    
      Shown below is the complete source code for the abbreviated ISR (the non-working 
    version), and the disassembly of BOTH the working and non-working versions.  I will
    try to retain the proper formatting (indentation) by clicking the magic button that
    Keith told me about (thanks, Keith).
    
    -eNick
    
                            ----------------------------------
    
    //begin NON-WORKING abbreviated ISR source code
    //      TimerGen.c
    
    //General program timer for program CCSi2041
    
    #include <msp430.h>             //include TI definitions
    
    #define U16  unsigned int                   //Unsigned 16-bit value
    
    
    //Begin definition of global variables
    //
    U16     sInitDelay_dS   = 3;                                    //program-initialization delay in dS
    U16     sInitDoneFlag   = 0;                                    //will be non-zero JUST ONCE at end of program-initialization
    U16     sCountdown_dS   = 100;                                  //countdown to next dS
    U16     sAckhold_dS     = 0;                                    //"Ack Holddown" time in dS
    U16     sAckHoldFlag    = 0;                                    //if non-zero, "Ack" held down long enough to clear counters
    U16     sAckNowFlag     = 0;                                    //non-zero when "Ack" pushbutton is pressed
    //
    //End definition of global variables
    
    
    //Begin references to external global variables
    //
    //
    //End references to external global variables
    
    
    //Begin definition of function-prototypes
    //
    void    FlashI                  (void);                         //Error-Code Flash function called from Timer every 1/10 second
    //
    //Begin definition of function-prototypes
    
    
    
    #pragma vector=TIMER0_A0_VECTOR
    __interrupt void TA0_ISR(void)
    {
    //get here 1,000 times per second
    
    //will now countdown towards the next dS
    sCountdown_dS--;                                                //countdown towards the next dS
    if (sCountdown_dS != 0)  return;                                //all done if not at next dS yet
    
    //will now perform everything that must be handled each dS
    sCountdown_dS = 100;                                             //reload the dS countdown
    
    FlashI ();                                                      //handle the Error-LED flashing
    
    //will now handle the program-initialization delay
    if (sInitDelay_dS)                                              //if the initialization-delay timer is still running
      {
       sInitDelay_dS--;                                               //count this additional dS
       if (!sInitDelay_dS)                                            //if the timer has just now timed out
         {
          sInitDoneFlag = 1;                                            //flag this for MainLoop
         }
      }
    
    }
    //end NON-WORKING abbreviated ISR source code
    
    
    //begin disassembly of NON-WORKING abbreviated ISR
    TA0_ISR():
    86bc:   120F                PUSH    R15
    86be:   120E                PUSH    R14
    86c0:   120D                PUSH    R13
    86c2:   120C                PUSH    R12
    86c4:   120B                PUSH    R11
    42    sCountdown_dS--;                                        //countdown towards the next dS
    86c6:   8392 022E           DEC.W   &sCountdown_dS
    86ca:   200D                JNE     ($C$L1)
    46    sCountdown_dS = 100;                                    //reload the dS countdown
    86cc:   40B2 0064 022E      MOV.W   #0x0064,&sCountdown_dS
    48    FlashI ();                                              //handle the Error-LED flashing
    86d2:   12B0 8436           CALL    #FlashI
    51    if (sInitDelay_dS)                                      //if the initialization-delay timer is still running
    86d6:   9382 022A           TST.W   &sInitDelay_dS
    86da:   2405                JEQ     ($C$L1)
    53       sInitDelay_dS--;                                     //count this additional dS
    86dc:   8392 022A           DEC.W   &sInitDelay_dS
    86e0:   2002                JNE     ($C$L1)
    56          sInitDoneFlag = 1;                                //flag this for MainLoop
    86e2:   4392 022C           MOV.W   #1,&sInitDoneFlag
    60    }
          $C$L1:
    86e6:   413B                POP.W   R11
    86e8:   413C                POP.W   R12
    86ea:   413D                POP.W   R13
    86ec:   413E                POP.W   R14
    86ee:   413F                POP.W   R15
    86f0:   1300                RETI    
    //end disassembly of NON-WORKING abbreviated ISR
    
    
    //begin disassembly of WORKING-FINE abbreviated ISR
    TA0_ISR():
    86bc:   120F                PUSH    R15
    86be:   120E                PUSH    R14
    86c0:   120D                PUSH    R13
    86c2:   120C                PUSH    R12
    86c4:   120B                PUSH    R11
    42    sCountdown_dS--;                                                //countdown towards the next dS
    86c6:   8392 0234           DEC.W   &sCountdown_dS
    86ca:   200D                JNE     ($C$L1)
    46    sCountdown_dS = 100;                                             //reload the dS countdown
    86cc:   40B2 0064 0234      MOV.W   #0x0064,&sCountdown_dS
    48    FlashI ();                                                      //handle the Error-LED flashing
    86d2:   12B0 8436           CALL    #FlashI
    51    if (sInitDelay_dS)                                              //if the initialization-delay timer is still running
    86d6:   9382 022A           TST.W   &sInitDelay_dS
    86da:   2405                JEQ     ($C$L1)
    53       sInitDelay_dS--;                                               //count this additional dS
    86dc:   8392 022A           DEC.W   &sInitDelay_dS
    86e0:   2002                JNE     ($C$L1)
    56          sInitDoneFlag = 1;                                            //flag this for MainLoop
    86e2:   4392 022C           MOV.W   #1,&sInitDoneFlag
    60    }
          $C$L1:
    86e6:   413B                POP.W   R11
    86e8:   413C                POP.W   R12
    86ea:   413D                POP.W   R13
    86ec:   413E                POP.W   R14
    86ee:   413F                POP.W   R15
    86f0:   1300                RETI    
    //end disassembly of WORKING-FINE abbreviated ISR
    
    

  • I was able to build the test case and match the assembly output you show.  It was good that I didn't need any user-written header files.  And I had to guess at a few things, like the compiler version and the build options.  But I finally generated matching code.  Now I can say few things for certain.

    In this specific situation, adding volatile does not help.  You should still add volatile to all the global variables modified in the interrupt.  If the code changes, or future version of the compiler is used which does things different, then volatile may make a difference.

    Small changes in the order of the global variables make no difference in the instruction stream, and only small changes in the instruction encoding.  Thus, it is most likely some hardware issue is the cause.  Perhaps the system is not configured correctly.  

    To pursue this issue, I recommend you start a new thread in the MSP forum.  Or, if you prefer, I can move this thread into that forum.

    Thanks and regards,

    -George

  • George, my apologies! I've not been ignoring your last response to me; I just
    didn't see it! I never got an email notification for it, and I got very busy
    with other projects. (Also, I sent you a followup message back in October that
    did not get tacked onto the end of the thread either! Note that that followup
    message is no longer important, as I will incorporate its contents into a new
    post in this thread very soon.


    >I was able to build the test case and match the assembly output you show. It was
    >good that I didn't need any user-written header files. And I had to guess at a
    >few things, like the compiler version and the build options.

    I'm glad you could build it without me having to actually find and read that
    article. :-) The compiler version (v9.2.0.00013) is in one of my posts, but not
    the build options. I will try to list the build options in a new post soon,
    although I'm not certain what all I should list. I am brand new to CCS and I am
    really struggling with it (and I hate it).


    >In this specific situation, adding volatile does not help. You should still
    >add volatile to all the global variables modified in the interrupt.

    Sold. Total agreement. I gnu that and was just lazy. My bad.


    >Small changes in the order of the global variables make no difference in the
    >instruction stream, and only small changes in the instruction encoding.

    That's the song I was singing!


    >Thus, it is most likely some hardware issue is the cause. Perhaps the system
    >is not configured correctly.

    I was thinking linker error, hopefully recently introduced in the compiler
    update to v9.2.0.00013 and therefore TI's fault. I like that better than my
    fault. :-) Anyway, when you say "hardware issue" are you talking about my
    desktop development system, or the MSP430i2041 target board, or the MSP-FET?
    Similarly, when you say "system" are you talking about my Windows 7 or CCS?


    >To pursue this issue, I recommend you start a new thread in the MSP forum. Or, if
    >you prefer, I can move this thread into that forum.

    Can we hold off just a bit? I have done a fresh install of CCS on one of my
    laptop computers and I need a bit of time to test there. Perhaps this is all
    caused by some mysterious corruption of CCS on my desktop system that was caused
    by the CCS update and the problem does not exist on fresh installs. Please stay
    tuned while I work on that.


    Again, I apologize for the delay in getting back to you.

    -eNick

  • user6131995 said:
    Anyway, when you say "hardware issue" are you talking about my
    desktop development system, or the MSP430i2041 target board, or the MSP-FET?
    Similarly, when you say "system" are you talking about my Windows 7 or CCS?

    My guess is there is something is wrong with the the MSP430 target board, or the MSP-FET you use to connect to it.

    user6131995 said:
    Can we hold off just a bit?

    Yes.  

    Thanks and regards,

    -George

  • >My guess is there is something is wrong with the the MSP430 target board, or
    >the MSP-FET you use to connect to it.

    I don't see how there could possibly be something wrong with the target board that
    would cause this problem. There are only 4 wires from the target board to the
    MSP-FET, and they go there and go nowhere else. If they weren't correct, the target
    would never program at all.

    The MSP-FET itself, OTOH, has always caused some suspicion because I have never
    been able to check its firmware version. It is fresh out of the box for this
    first TI project, and I cannot find any way to determine its firmware version or to
    find out what the latest firmware version should be. I really don't think that
    the MSP-FET is causing THIS problem, but there are some other strange behaviors
    that could well be MSP-FET related.

    I should mention that this is apparently not an optimization-related problem.
    This problem of a global variable being position-dependent exists whether I have
    optimization set to "Register" or set to "off". Note that I normally keep it
    set at "Register" because without optimization this program will not actually
    run correctly because then it becomes too slow to do what I need.

    My effort to try a fresh install of CCS on one of my laptop computers ended in
    total disaster. I ended up with a thoroughly corrupted CCS that would not even
    display "Run" in the main menu bar. I could build the project but I could not
    load it into the target board. There were several other problems with the laptop
    installation, and I have abandoned that effort. Thus, I may be working with a
    slightly corrupted CCS on my main desktop computer, with no way to compare the
    behavior with another machine.

    Yeah, I know this is not the MSP-FET forum, but I would be happy to have you
    tell me how to check/update the MSP-FET firmware version anyway. :-)

    -eNick

  • user6131995 said:
    Yeah, I know this is not the MSP-FET forum, but I would be happy to have you
    tell me how to check/update the MSP-FET firmware version anyway. :-)

    Every time you start a debug session, CCS checks if the firmware version in the MSP-FET matches the version contained within the "MSP Debug Probe drivers" component installed in CCS.

    If the firmware version in the MSP-FET doesn't match that in CCS then you get the following dialogue when starting a debug session:

    This dialogue doesn't report which firmware version it will program, but if you use the CCS menu Help -> About Code Composer Studio -> Installation Details -> Installed Software and look at the entry for "MSP Debug Probe drivers" you will see the revision in the "General Information" properties.

  • Hello Chester, and thank you for the info.


    >Every time you start a debug session, CCS checks if the firmware version in the
    >MSP-FET matches the version contained within the "MSP Debug Probe drivers"
    >component installed in CCS.

    I'll take it that you mean that literally and that it does NOT do that if I
    only "Run/Load" instead of "Run/Debug". I'll remember that!


    >if you use the CCS menu Help -> About Code Composer Studio -> Installation
    >Details -> Installed Software and look at the entry for "MSP Debug Probe drivers"
    >you will see the revision in the "General Information" properties.

    Yup, it's there alright, buried so deep I would probably have never found it
    without your help. Thanx.


    Unfortunately, it appears that I do have the very latest MSP-FET firmware, so I'm
    back to ground zero. (I was hoping the firmware was the reason I cannot load/debug
    this project with VisualGDB.)

    -eNick

  • user6131995 said:
    When I run this program under the debugger, and examine the value of
    sCountdown_dS as soon as the debugger stops at the entry-point of the
    program, the variable does indeed contain the value 100. However, when
    I let the debugger run to the first instruction in the ISR, the variable
    sCountdown_dS contains the value ZERO. Oddly, the ISR has another
    global variable (named sInitDelay_dS) that DOES have the correct value
    upon entry to the ISR. It's apparently just sCountdown_dS that has the
    problem.

    When the debugger stops at the entry-point, try setting a watchpoint on the sCountdown_dS variable.

    To do this right-click in the Breakpoints view and select Breakpoint (Code Composer Studio) -> Watchpoint. In the Location: field specify the sCountdown_dS global variable:

    After setting the Watchpoint resume the program. The program will halt on the next access to the sCountdown_dS variable. If something other that the ISR is accessing the variable the watchpoint should find it.

  • >try setting a watchpoint on the sCountdown_dS variable.

    >After setting the Watchpoint resume the program. The program will
    >halt on the next access to the sCountdown_dS variable. If something other
    >that the ISR is accessing the variable the watchpoint should find it.


    Man, would that ever be nice! However, like the rest of CCS, it doesn't
    work worth a #%^&. Trying to set any Watchpoint results in totally bizarre
    behavior of the debugger. Sometimes (but only sometimes) I get this MessageBox
    (which I am retyping by hand):

    MSP430: Trouble Setting Breakpoint with the Action "Finish Auto Run"
    at 0x8466: Software breakpoint conflicts with one or more enabled
    hardware triggers.

    At other times, I cannot even set the Watchpoint because it complains that
    I am already using too many hardware resources, even though there are NO
    other Breakpoints or Watchpoints set.

    At other times, I can successfully set the Watchpoint but Resume will
    stop the program at a seemingly arbitrary line that does not have a
    breakpoint on it (when, in fact, there are no breakpoints at all).
    Subsequent Resumes will then stop the program at other seemingly arbitrary
    lines.

    At NO time does the debugger ever stop due to the sCountdown_dS Watchpoint.


    Chester, I really appreciate you (and the others) trying to help me
    out with this nasty problem. I still can't shake the feeling that this
    is all caused by some kinda corruption of my CCS installation. Else, why
    wouldn't others be complaining here about the same problems? Please note
    that my experience with CCS was FAR WORSE when I tried to install it on a
    spare laptop (in an effort to test my desktop corruption theory).

    There is one specific thing that I would like you guys to tell me: Is it
    a KNOWN FACT that this CCS/MSP-FET thing works fine on Windows 7 Pro?
    That would be very conforting to know, given that the TI developers have
    probably been ordered to switch to Windows 10 by now. (If I had to buy
    another laptop with Win10 on it to develop this project, I would do it but
    that would not make me happy.)

    -eNick

  • user6131995 said:
    Unfortunately, it appears that I do have the very latest MSP-FET firmware, so I'm
    back to ground zero. (I was hoping the firmware was the reason I cannot load/debug
    this project with VisualGDB.)

    What error are you getting from VisualGDB?

    I just installed a trial of VisualGDB, and was able to load and debug a program in a MSP430F6659 connected to a MSP-FET, using the msp430-gdbproxy++ v1.8 installed by VisualGDB.

  • user6131995 said:
    Sometimes (but only sometimes) I get this MessageBox

    (which I am retyping by hand):

    MSP430: Trouble Setting Breakpoint with the Action "Finish Auto Run"
    at 0x8466: Software breakpoint conflicts with one or more enabled
    hardware triggers.

    A MSP430I2041 contains a "LOW_EEM" which only support two breakpoints. I can get the similar error "MSP430: Trouble Setting Breakpoint with the Action "Finish Auto Run" at 0x8000: Software breakpoint conflicts with one or more enabled hardware triggers" if have a watchpoint already set for a MSP430F2274, which also has a LOW_EEM, when starting a debug session. If the watchpoint is enabled after the program has reached main then don't get the error. However, once the watchpoint has been set attempting to set a breakpoint by double-clicking on a source line while the program is halted results in an error of the form "MSP430: Trouble Setting Breakpoint with the Action "Remain Halted" at 0x8030: Software breakpoint conflicts with one or more enabled hardware triggers" and the new breakpoint is shown as disabled.

    user6131995 said:
    At other times, I cannot even set the Watchpoint because it complains that
    I am already using too many hardware resources, even though there are NO
    other Breakpoints or Watchpoints set.

    If you open the Scripting Console in CCS (via the View menu) and enter the following in the Scripting Console:

    eval("DEBUG_DumpBreakpoints()")

    Then the Console will display a dump of the breakpoints. E.g.:

    MSP430: Breakpoint Manager Dump: Total Allocated Logical Breakpoints: 6
    MSP430: Breakpoint Manager Dump: Total Allocated Software Physical Breakpoints: 5
    MSP430: Breakpoint Manager Dump: Total Allocated Legacy Hardware Physical Breakpoints: 0
    MSP430: Breakpoint Manager Dump: Total Allocated 55 Hardware Physical Breakpoints: 0
    MSP430: Breakpoint Manager Dump: Total Allocated Thread Physical Breakpoints: 0
    MSP430: Breakpoint Manager Dump: 
    MSP430: Breakpoint Manager Dump: Enabled: 1
    MSP430: Breakpoint Manager Dump: 
    MSP430: Breakpoint Manager Dump: 	Hardware Configuration
    MSP430: Breakpoint Manager Dump: 		Type: Simple
    MSP430: Breakpoint Manager Dump: 			Action: Halt Target
    MSP430: Breakpoint Manager Dump: 			Trigger 0: Memory Address Bus
    MSP430: Breakpoint Manager Dump: 				Location: "&IntDegF" (0x204)
    MSP430: Breakpoint Manager Dump: 				Mask: 65535
    MSP430: Breakpoint Manager Dump: 				Access: No instruction fetch
    MSP430: Breakpoint Manager Dump: 			Trigger 1: None
    MSP430: Breakpoint Manager Dump: 	Miscellaneous
    MSP430: Breakpoint Manager Dump: 		Group: Default Group
    MSP430: Breakpoint Manager Dump: 		Name: Watchpoint
    MSP430: Breakpoint Manager Dump: 	Breakpoint set by the user
    MSP430: Breakpoint Manager Dump: 
    MSP430: Breakpoint Manager Dump: Disabled: 5
    MSP430: Breakpoint Manager Dump: 
    MSP430: Breakpoint Manager Dump: 	Hardware Configuration
    MSP430: Breakpoint Manager Dump: 		Location: "C$$IOE$$"
    MSP430: Breakpoint Manager Dump: 	Debugger Response
    MSP430: Breakpoint Manager Dump: 		Condition: 
    MSP430: Breakpoint Manager Dump: 		Skip Count: 0
    MSP430: Breakpoint Manager Dump: 			Current Count: 0
    MSP430: Breakpoint Manager Dump: 		Action: Process CIO
    MSP430: Breakpoint Manager Dump: 	Miscellaneous
    MSP430: Breakpoint Manager Dump: 		Group: Default Group
    MSP430: Breakpoint Manager Dump: 		Name: 
    MSP430: Breakpoint Manager Dump: 	Breakpoint set by the system
    MSP430: Breakpoint Manager Dump: 
    MSP430: Breakpoint Manager Dump: 	Hardware Configuration
    MSP430: Breakpoint Manager Dump: 		Type: Simple
    MSP430: Breakpoint Manager Dump: 			Action: Halt Target
    MSP430: Breakpoint Manager Dump: 			Trigger 0: Memory Address Bus
    MSP430: Breakpoint Manager Dump: 				Location: "C$$EXIT" (0x8206)
    MSP430: Breakpoint Manager Dump: 				Mask: 65535
    MSP430: Breakpoint Manager Dump: 				Access: Instruction fetch
    MSP430: Breakpoint Manager Dump: 			Trigger 1: None
    MSP430: Breakpoint Manager Dump: 	Debugger Response
    MSP430: Breakpoint Manager Dump: 		Condition: 
    MSP430: Breakpoint Manager Dump: 		Skip Count: 0
    MSP430: Breakpoint Manager Dump: 			Current Count: 0
    MSP430: Breakpoint Manager Dump: 		Action: Terminate Program Execution
    MSP430: Breakpoint Manager Dump: 	Miscellaneous
    MSP430: Breakpoint Manager Dump: 		Group: Default Group
    MSP430: Breakpoint Manager Dump: 		Name: 
    MSP430: Breakpoint Manager Dump: 	Breakpoint set by the system
    MSP430: Breakpoint Manager Dump: 
    MSP430: Breakpoint Manager Dump: 	Hardware Configuration
    MSP430: Breakpoint Manager Dump: 		Location: "C$$EXITE"
    MSP430: Breakpoint Manager Dump: 	Debugger Response
    MSP430: Breakpoint Manager Dump: 		Condition: 
    MSP430: Breakpoint Manager Dump: 		Skip Count: 0
    MSP430: Breakpoint Manager Dump: 			Current Count: 0
    MSP430: Breakpoint Manager Dump: 		Action: Terminate Program Execution
    MSP430: Breakpoint Manager Dump: 	Miscellaneous
    MSP430: Breakpoint Manager Dump: 		Group: Default Group
    MSP430: Breakpoint Manager Dump: 		Name: 
    MSP430: Breakpoint Manager Dump: 	Breakpoint set by the system
    MSP430: Breakpoint Manager Dump: 
    MSP430: Breakpoint Manager Dump: 	Hardware Configuration
    MSP430: Breakpoint Manager Dump: 		Location: C:\Users\mr_halfword\workspace_v9_2\msp430x22x4_adc10_temp.c\Debug/../msp430x22x4_adc10_temp.c, line 101 ("C:/Users\mr_halfword\workspace_v9_2\msp430x22x4_adc10_temp.c\Debug\msp430x22x4_adc10_temp.c.out") (0x80a6)
    MSP430: Breakpoint Manager Dump: 	Debugger Response
    MSP430: Breakpoint Manager Dump: 		Condition: 
    MSP430: Breakpoint Manager Dump: 		Skip Count: 0
    MSP430: Breakpoint Manager Dump: 			Current Count: 0
    MSP430: Breakpoint Manager Dump: 		Action: Remain Halted
    MSP430: Breakpoint Manager Dump: 	Miscellaneous
    MSP430: Breakpoint Manager Dump: 		Group: Default Group
    MSP430: Breakpoint Manager Dump: 		Name: Breakpoint
    MSP430: Breakpoint Manager Dump: 	Breakpoint set by the user
    MSP430: Breakpoint Manager Dump: 
    MSP430: Breakpoint Manager Dump: 	Hardware Configuration
    MSP430: Breakpoint Manager Dump: 		Location: "C$$IO$$"
    MSP430: Breakpoint Manager Dump: 	Debugger Response
    MSP430: Breakpoint Manager Dump: 		Condition: 
    MSP430: Breakpoint Manager Dump: 		Skip Count: 0
    MSP430: Breakpoint Manager Dump: 			Current Count: 0
    MSP430: Breakpoint Manager Dump: 		Action: Process CIO
    MSP430: Breakpoint Manager Dump: 	Miscellaneous
    MSP430: Breakpoint Manager Dump: 		Group: Default Group
    MSP430: Breakpoint Manager Dump: 		Name: 
    MSP430: Breakpoint Manager Dump: 	Breakpoint set by the system

    In the above example there is only one enabled breakpoint, which is a watchpoint which has been set.

    CCS can automatically set some breakpoint, e.g. for CIO support or to detect when a program has exited. If you dump the breakpoints, what is the list of enabled breakpoints?

  • user6131995 said:
    At other times, I can successfully set the Watchpoint but Resume will
    stop the program at a seemingly arbitrary line that does not have a
    breakpoint on it (when, in fact, there are no breakpoints at all).
    Subsequent Resumes will then stop the program at other seemingly arbitrary
    lines.

    I can't repeat that using:

    - CCS 9.2.0.00013

    - Windows 10 Pro version 1903 (have used CCS v8 successfully with a Windows 7 Pro and a MSP-FET previously)

    - MSP-FET

    - MSP430F2274 (as mentioned previously has the same LOW_EEM as your MSP430I2041)

    - The simple msp430x22x4_adc10_temp.c "ADC10, Sample A10 Temp and Convert to oC and oF" example from MSP430Ware

    Setting a watchpoint on a global variable, and when resume the program the program only hits on a "HW Breakpoint" on a statement which accesses the global variable on which a watchpoint has been set:

    I also tried the same example with VisualGDB. While VisualGDB will let me set a data breakpoint (a.k.a watchpoint) on a global variable in a MSP430F2274, I get a "Failed to resume debugging. You may have requested too many hardware breakpoints. Please try disabling some of them and try resuming your session again." when attempt to resume the program, even though a GDB "i b" to list the breakpoints doesn't show any unexpected breakpoints:

  • Chester Gillon said:
    I also tried the same example with VisualGDB. While VisualGDB will let me set a data breakpoint (a.k.a watchpoint) on a global variable in a MSP430F2274, I get a "Failed to resume debugging. You may have requested too many hardware breakpoints. Please try disabling some of them and try resuming your session again."

    Tried an example for a MSP430F6659 which has a LARGE_EEM with 8 breakpoints, and then both CCS 9.2 and VisualGDB were able to set a watchpoint on a global variable correctly. When the program was resumed it only halted on a statement which accessed the global variable on which the watchpoint was set.

  • user6131995 said:
    I still can't shake the feeling that this is all caused by some kinda corruption of my CCS installation.

    Maybe enabling Debug Server Logs would get some more information on what is going wrong in the your CCS installation.

    Also, is the MSP430i2041 chip in a TI EVM or a custom board?

    Given the various intermittent failures you have observed not sure if a hardware problem.

  • >is the MSP430i2041 chip in a TI EVM or a custom board?

    Custom but very simple. There are only 4 wires (including power and ground), and they
    are connected to the MSP-FET and nothing else. Yeah, there's a resistor and capacitor
    on the Reset line, but they are correct. Okay, I'll double-check them again! :-)

    -eNick

  • >I just installed a trial of VisualGDB, and was able to load and debug a program
    >in a MSP430F6659 connected to a MSP-FET,

    WOW! That's the best news I've heard in a long time. I would dearly LOVE to
    be able to use VisualGDB on this TI project.
    If you play with VGDB a bit, you should be very happy too. It makes all my
    project types (Win32, WinCE, ARM, etc.) look THE SAME. (Android also, but I
    haven't messed with that yet.) No more trying to remember which F-Key goes with
    which IDE for "Single Step", etc. Plus, of course, you get the full power of
    Visual Studio, including IntelliSense. (Even the hardcore Microsoft bashers I know
    don't have anything bad to say about Microsoft's excellent VS.) All this is in
    addition to the fact that VS/VGDB works perfectly! I should also mention that the
    VGDB tech support is excellent (although email-only), but I'd better stop here before
    TI kicks me out for touting non-TI development products. :-)


    >using the msp430-gdbproxy++ v1.8 installed by VisualGDB.

    How do you know that? When I look at VisualGDB Project Properties/Debug Settings/
    Debug Using: it says "JTAG (gdbproxy++)" (no version number). When I look at
    VisualGDB Project Properties/Embedded Debug Tweaking/GDB Debugger: it says
    "Supplied with toolchain".
    I am using VisualGDB version 5.4R12 (build 3309) which far as I can tell is the
    latest and greatest.


    >What error are you getting from VisualGDB?

    Well, my MSP430i2041 project compiles and links without error (or any warnings).
    If I "Start without Debugging", the program gets loaded into the target but it takes
    much longer than when loaded by CCS -- about 10 or 12 seconds, and I get the message:

    "The device has been programmed successfully, however it requires manual reset.
    Please reset the device manually to start your new firmware. Press any key..."

    If I "Start Debugging", the program gets loaded into the target but it takes a VERY
    long time (maybe 25 seconds), during which VGDB complains that the load is taking
    too long. Eventually the load is complete (without the above manual reset message),
    but the program is apparently not actually running. When I do a "Break All" to see
    where the program is, I find that it has jumped to (or been loaded at?) a high
    address in memory that contains all FFFFs.


    Chester, I would REALLY like to get this working with VisualGDB. Maybe I just need
    a newer version of something (such as msp430-gdbproxy++ v1.8, which I don't know how
    to find.
    As I've mentioned before a while ago, I actually had this TI project WORKING under
    VS/VGDB but with some non-idealities (such as the very slow load time and the manual
    reset message). I then tried for perfection, by downloading a bunch of different
    debuggers and MSP library versions, and ended up with a THOROUGHLY HOSED Visual Studio
    that would no longer work on ANY platform, including Win32. I was tremendously
    relieved when dropping back to a recent Restore Point of my Win7 saved my bacon, and
    I am a bit more careful now about download experiments. :-)

    At this point I am wondering about interrupt vector tables and linker scripts
    (particularly the latter). My STM32 ARM Cortex VisualGDB projects all have an
    interrupt vector table that was supplied by me and a linker script that was
    supplied by STM. This TI VisualGDB project does not have any visible interrupt
    vector table or any visible linker script. Both are obviously embedded in the
    TI library or BSP (else it wouldn't link), but I'd much have them VISIBLE to me.
    Do you have any ideas on that?

    -eNick

  • Chester, I see that you have taken the time to send me several very comprehensive
    and detailed responses to my questions, for which I am VERY grateful. I'm thinking
    that in addition to being a nice guy, you must also be RETIRED, else how could you
    afford to take this much time to help me? Myself, I'm old enough to be retired but
    I'll probably never actually do that. Instead, I'm up to my ears in various computer
    projects, and I find myself falling behind in many of them because of all the time
    I've lost trying to get this TI chip to work. Thus, you can expect some delay in
    responses from me to your suggestions, but please be assured that your advice will
    not be overlooked or ignored!

    -eNick

  • user6131995 said:
    Custom but very simple. There are only 4 wires (including power and ground), and they
    are connected to the MSP-FET and nothing else. Yeah, there's a resistor and capacitor
    on the Reset line, but they are correct. Okay, I'll double-check them again! :-)

    Do you have the datasheet recommended 470 nF capacitor between the VCORE pin and ground?

    I have seen in the past that omitting to connect the recommended capacitor to VCORE (internal core voltage) can cause intermittent operation of MSP430 devices (strange crashes).

  • >Do you have the datasheet recommended 470 nF capacitor between the VCORE pin and ground?

    Yes.


    >I have seen in the past that omitting to connect the recommended capacitor to VCORE
    >(internal core voltage) can cause intermittent operation of MSP430 devices (strange crashes).

    I can see that I am now talking to a very experienced TI guy! Anyway, no crashes here.


    I have some new information that is very enlightening. Further testing shows that
    this project DOES run under VisualGDB, but only in Debug mode and then ONLY IF there
    are no breakpoints set when the debug session is started. Here are the facts:

    1) This project can be loaded by VGDB in non-debug mode, but it does not run (does not
    blink the timer's LED), and does have the "manual reset required" message (and Reset
    does not make it run).

    2) This project can be loaded by VGDB in Debug mode, WITHOUT the "manual reset required"
    message, but it does not run if a breakpoint has already been set. Debug/Break All will
    show that the program is stopped in a huge area of FFFFs at the top of memory.

    3) This project can be loaded by VGDB in Debug mode, WITHOUT the "manual reset required"
    message, and it DOES RUN if a breakpoint has NOT already been set. Debug/Break All will
    correctly show where the program has stopped, and that will be on a legitimate source
    code instruction. At this point Single-Step, etc. all WORK FINE! At this point, you can
    add a breakpoint and it will WORK FINE. And Resume will work fine too -- you can Resume
    and stop at the breakpoint repeatedly. Note that this scenario involves sCountdown_dS
    being last in the global variables list in the timer interrupt routine (where it makes
    CCS happy).

    4) EXACT SAME as #3 above, except sCountdown_dS has been moved to the 3rd place in the
    global variables list in the timer interrupt routine (where it makes CCS UNhappy), and
    quess what? Moving the variable makes VGDB unhappy too! The behavior of this variable
    under VGDB is the EXACT SAME as it is under CCS -- specifically, sCountdown_dS will
    always have the value of zero if the variable is 3rd in the list instead of 6th (last)
    in the list. That's interesting enough to make me dizzy. All other behavior of the
    program is CORRECT as in #3 above.

    It seems to me that #4 above proves that I should stop raving about compiler bugs
    in CCS. :-) But there is obviously something wrong, both in CCS and VisualGDB, and
    I'm still nervous about the fact that I don't see any explicit setting of the stack
    pointer, or even any linker script, in either environment.

    I'll probably switch my efforts to fix this project to VisualGDB, now that I have
    a toehold where it can actually be debugged there, simply because I am much more
    familiar with VGDB than CCS (and, of course, because of IntelliSense). I will still
    need to get it running under CCS, though, before all is said and done.

    Right now, I have other stuff I must do so there will be some delay before I can
    get back to this.

    Thanks again for your interest in my problems, Chester.

    -eNick

  • Hi Nick,

    I am quite lost in your long discussion. Your topic turns from sCountdown_dS to VisualGDB.

    Can you make a short explain what the issue is and is there any progress to make this problem clear? 

    I hope I can help you from MSP430 side.

    Eason

  • >I am quite lost in your long discussion. Your topic turns from sCountdown_dS to VisualGDB.

    Heh. I'm quite lost in it myself. :-) The main topic is the strange behavior of the
    sCountdown_dS global variable, but the strange behavior exists whether I make this a
    CCS project or a VisualGDB project (which I learned just yesterday). I agree that this
    thread has dragged on too long.


    >Can you make a short explain what the issue is and is there any progress to make this
    >problem clear?

    There are 3 issues I am fighting:

    1) strange order-dependency of a global variable, in BOTH CCS and VisualGDB

    2) barely minimal (as opposed to the usual perfect) performance of VisualGDB

    3) inability to install a fresh CCS on a laptop for a "second opinion"

    Please give me a couple of days to digest all that I have learned here and to
    run some more tests (and attend meetings unrelated to this, of course).


    >I hope I can help you from MSP430 side.

    I sure appreciate that, Eason. Thanks.

    -eNick

  • Hi Nick,

    About your 3 issues:

    1) strange order-dependency of a global variable, in BOTH CCS and VisualGDB

    Can you post a smallest example which can be run from my side. It will be much helpful and easily understand, and I can use it to talk with other colleagues.

    2) barely minimal (as opposed to the usual perfect) performance of VisualGDB

    I am sorry, from msp430 part, we only support CCS and IAR. We have no experience to use VisualGDB

    3) inability to install a fresh CCS on a laptop for a "second opinion"

    I haven't meet your problems that CCS can't display "Run". Maybe you can check the address saved in 0xfffe, to see if it is the right entrance of your code. Besides, I advice you to open a new thread to talk about this issue and put some pictures. It will be much clear and helpful to other E2E  community member.

    Eason

  • Hello user,

    static U16 sCountdown_dS = 100; //countdown to next dS

    Volatile puts the value in SRAM and can be overwritten each interrupt cycle, it is not the same as NON volatile. Where interrupt are involved you want to use Static variables to Push the contents on stack if the interrupt handler vectors due to priority level changes at the NVIC level. Hence you must also add priority levels for each your peripheral interrupt handlers. 

    Regards,

  • Hi Nick,

    Is there any progress?

    Eason

  • Hi Nick,

    IS there any progress? Fixed?

    Eason

  • Okay, I realize I've been off the air for a while now because I have been
    traveling. There is NO PROGRESS. I still experience the same strange
    behavior on my desktop machine, and all efforts to install CCS on a laptop
    for a "second opinion" have failed. Actually, I have installed CCS okay,
    but it refuses to recognize my MSP-FET devices (I purchased a second one
    just in case of hardware failure, and updated its firmware as required by
    CCS, and both devices are still unrecognized.)

    I have told the people for whom I am evaluating this chip that the chip
    itself is stupid compared to other modern MCUs (only one UART, no
    programmable UART signals polarity, no DMA for the UART output, no
    pullup or pulldown resistors, and the list goes on) and that the
    development environment (CCS) is extremely slow (especially to load)
    and has very minimal functionality compared to the world-standard
    Visual Studio, and doesn't work right anyway. I have advised them to
    instead select a chip from STM and program it with Visual Studio.
    Thus, you guys may be lucky enough to never hear from me again. :-)
    However, the people who selected this TI chip are still in love with
    the 24-bit (supposedly) Delta-Sigma A/D converter, so I may be forced
    to continue this fruitless struggle.

    My problem is NOT solved, so I'm not gonna click the solved button,
    but I would be perfectly happy if the sysop were to simply perform
    a mercy killing on this whole forum thread.

    One thing is for sure, and that is the fact that you guys have tried
    very hard to be helpful and I greatly appreciate it!

    -eNick

  • Hi,

    1. So there is a new problem? About your nonrecognition of MSP-FET, can you post a screen shot of your device manager? I want to help you check if your PC can recognize MSP-FET.

    2. You have so many questions. Can you describe it one by one clearly? It will be much helpful to solve them.

    Eason