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.

MSP430F2254: Part compatibility between MSP430F2254TDA and MSP430F2254TDAR. SW isn't working.

Part Number: MSP430F2254

Hello,

I take over the existing product from other site and verify flashing and debugging.

The product has MSP430F2254TDA with efuse blown which I couldn't flash. I couldn't find the part from distributor and TI, so got MSP430F2254TDAR and replaced it.

I  programmed the existing SW after then, but it didn't work correctly. Now I am compiling and flashing SW into the board(MSP430F2254IDAR), but the program doesn't rum correctly nor can't be debugged because it stuck on __data16_memzero. I can't see this program jump to main(). The SW was compiled by IAR.   

I'm not sure this problem with TI part difference or  not. Can you please take a look at the issue and give me any comments.

I attached the screenshot for debugging .

Thank you, HJ

  • added additional information.

    1. TI says MSP430F2254TDA and MSP430F2254TDAR are the same part, it’s just the package qty and carrier are different.  The first is delivered in 40pc TUBE and the other is a 2000pc tape & reel.  

    2. I wrote a simple program like blinking LED and found it works successfully on both CCS and IAR IDE with the board.

  • Hi Hyungjai,

    You are correct. These two parts are identical.

    Have you verified that the project was working before with the original device?

    -Chris

  • Hi Chris,

    Thank you for your confirmation.

    I bought two commercial products and tried to flash a SW on website and binaries I compiled, but failed to do because they are blown by efuse.

    HW guy helped me replace the blank part with the MCU. And then I can flash them, but can't run correctly. I'm trying to debug but can't make it.

    The units were working correctly before I flashed the SW. I guess the SW should be right to run.

    Regards, HJ

  • I have some progress on debugging. I can go to main() function by doing the following steps.

    1. disable:

      a. "Project>Options>Debugger>Setup>Run to main",
      b. "Project>Options>FET Debugger>Breakpoints>Use software breakpoints"
      c. "Tools>Options>Stack" all,

    2. exit the workbench and delete/rename the Settings sub-folder from the project
       directory before restarting the workbench/debugger,

    3. enter "main" in the Disassembly window to display the main() corresponding instructions,

    4. right click at the first instruction of the main() to "run to cursor",

    I found program lost control after write the following line.

    main() {

    WDTCTL = WDTPW + WDTHOLD; // stop watch dog timer
    Init_Port();   // gpio setup 
    Init_DCO(DCO_1MHZ); // --> move to Init_DCO

    void Init_DCO(UINT08 nMHz)
    {
      switch(nMHz)
      {
        case DCO_1MHZ:
            DCOCTL = CALDCO_1MHZ;
            BCSCTL1 = CALBC1_1MHZ;
            BCSCTL2 = 0x00;    <--- here
            break;

    Can you please give me your comments if you have any information?

    Thanks, HJ

  • HJ,

    Are you able to test some example code your board to define if this is a hardware/software related issue? Please choose a simple example here.

    Are you receiving any error code?

    -Chris

  • Thank you for your comments, Chris.

    I wrote and ran a simple program like blinking LEDs on CCS and IAR. Both programs work fine. I guess something's wrong when HW engineer changed chipset from the existing production version to blank MCU. Now I have to move on another task and left it as is.

  • >        DCOCTL = CALDCO_1MHZ;
    >        BCSCTL1 = CALBC1_1MHZ;
    >        BCSCTL2 = 0x00;    <--- here

    My first guess is that your clock calibration constants have been erased (0xFF is far out of range for either register). A simple LED-blinker that doesn't use those constants wouldn't know the difference.

    It would be interesting to know what the memory contents of addresses 0x10F8-10FF are. Erasing InfoA accidentally is easier than one might think. The constants can be re-generated fairly easily if you have an external 32kHz clock source.

**Attention** This is a public forum