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/MSP430FR5889: Program flow break

Part Number: MSP430FR5889

Tool/software: Code Composer Studio

I am using MSP430FR5889 and writing in C on CCS environment.

During program run, sometimes the program flow breaks, and the execution "jumps" to wrong address.
Sometimes inside the code, and sometimes to address outside the program code.

I am using timer_A interrpts, both on capture and compere mode, but as far as I could check, all interrupts ended correctly (Debug counters I introduced in the entrance and in exiting the ISR matched).

I tried changing CCS versions, Compiler version, optimization levels, and no change.

Does any of this rings a bell to anybody?

  • Do you have any interrupts enabled without having a handler?
  • No.
    To verify it I tried to put a breakpoint in the default interrupt handler but did not get there before the problem ocured.
  • A stack overflow could produce this sort of symptom.
  • I suspected that as well.
    I checked that by setting all the stack area to zero before the start of the run (Debug mode) and then when the problem happened I saw that only about 1/4 of the area was changed (used).
    I don't have any large array on the stack that might have been allocated but not used.
  • I found out that the jump from the normal program flow happened in one of the cases at a call command.

    The disassembly of that point was :

    012980:   13B1 2EDA           CALLA   #SetRF_Mode

    The program passed successfully in this command for hundreds of times without a problem, but then one other time it jumped to a command holding the address 0x0113B1.

    This address is offcourse the opcode of the CALLA command, which brings me to suspect that the processor took the 1st word of the CALLA command to be not only the oparation but also to serve as the destination (instead of taking the 2nd word).

    Any idea anyone ?

  • Is there anybody that can help?

    It looks as a bug in the processor, but I didn't find anything about it in the errata sheet.

  • Hi Ofec,

    I apologize for the trouble this may have caused. I'm going to look into this with our quality team and see if there is any known issue that could be causing this, or if this could be something new entirely.

    Can you provide the following:

    1. Code sample that can be used to replicate the issue
    2. Device Revision Number
    3. How many devices are experiencing this issue?

    Best regards, 

    Caleb Overbay

  • Dear Caleb,
    Thank you for the reply.

    The device packaging:

    MSP430 FR5889 TI 541 C C8JN G4

    I tried 3 CCS versions (no change) : 6.1.0 ; 6.2.0 ; 7.0.0
    I tried it on 2 devices without a change.

    The code where the problem happened is:

    dbg_RxStatus |= 0x0001;

    TA0CCTL1 = 0;  // Disable interrupt

    SetRF_Sleep(); // Stop RF Rx (Sleep) // Parsed to SetRF_Mode(0x00,1);

    dbg_RxStatus |= 0x0004;


    Disassembly is:

    1142     dbg_RxStatus |= 0x0001;

    012970:   D392 2152           BIS.W   #1,&dbg_RxStatus

    1145     TA0CCTL1 = 0; // Disable interrupt

    012974:   4382 0344           CLR.W   &Timer0_A3_TA0CCTL1

    1150     SetRF_Sleep();       // Stop RF Rx (Sleep)

    012978:   434C                CLR.B   R12

    01297a:   435D                MOV.B   #1,R13

    01297c:   13B1 2ED6           CALLA   #SetRF_Mode

    1152     dbg_RxStatus |= 0x0004;

    012980:   D2A2 2152           BIS.W   #4,&dbg_RxStatus


    The problem is with the CALLA command that normally branch to the SetRF_Mode() routine, but then one other time branches to the command in address 0x0113b0 - 0x0113b1.



  • Hi Ofec,

    Thanks for providing the code snippet. I'll work on trying to recreate this with my own hardware. After speaking with our quality team we have a few more questions for you as well:

    1. Are you using DMA?
    2. What frequency are you using for the Timer and CPU?
    3. Are you experiencing this issue without the debugger as well, or only with the debugger?
    4. Is this problem 100% reproducible?
      1. Does it happen every time a CALLA command is executed?
      2. Or is it only occasionally?

    Best regards, 
    Caleb Overbay

  • Hi Ofec,

    One more comment. If you're running the CPU at a frequency greater than 8MHz, you need to ensure you are using the FRAM wait states. Otherwise, you could have sporadic code execution like what you're experiencing here.

    Best regards,
    Caleb Overbay
  • Dear Caleb,

    Thank you for the efforts.

    My processor is running on 16MHz so the NWAITS is set to 1.

    I am not using DMA.

    HW setup of my system is:

    void HW_Init(void)


    // WatchDog off



    // LEDs Setup

    LED_Init();        // GPIOs



    // Debug Setup

    DEBUG0_INIT();     // GPIOs





    // Disable the GPIO power-on default high-impedance mode to activate

    // previously configured port settings

    PM5CTL0 &= ~LOCKLPM5;


    // Set system Clocks

    PJSEL1 = 0;                              // Set Xtal pins active

    PJSEL0 = 0x50;


    CSCTL0_H = CSKEY_H;                       // Unlock CS registers

    CSCTL1 = DCORSEL|DCOFSEL_3;               // Set DCO setting for 16MHz

    CSCTL2 = SELA__VLOCLK|SELS__VLOCLK|SELM__VLOCLK; // Select all Clock sources to VLO

    CSCTL3 = DIVA__1|DIVS__1|DIVM__1;         // Set no devidor for Clock sources

    CSCTL4 = HFXTDRIVE_3|HFFREQ_1|LFXTDRIVE_3;// Set drivers current and freq. range



    { // Loop until all fault flag is cleared

       CSCTL5 &= ~(HFXTOFFG|LFXTOFFG);         // Clear fault flags

       SFRIFG1 &= ~OFIFG;                     // Clear fault flags

    }while (SFRIFG1&OFIFG);                   // Test oscillator fault flag


    CSCTL0_H = 0;                             // Lock CS registers


    FRCTL0 = FRCTLPW|NWAITS_1;               // Set 1 wait state

    FRCTL0_H = 0;


    CSCTL0_H = CSKEY_H;                       // Unlock CS registers

    CSCTL2 = SELA__LFXTCLK|SELS__HFXTCLK|SELM__DCOCLK; // Select actual Clock sources

    CSCTL4 |= VLOOFF;                         // Close VLO

    CSCTL0_H = 0;                             // Lock CS registers


    // Init Timing process

    Timer_Init();      // See below


    // Enable Interrupts



    //Set Watch dog timer



    // Set LED off

    LED_OFF();         // GPIO



    void Timer_Init(void)


    // Set Timer_A0, Timer_A1 and Timer_A3 for SMCLK/8, countup, no interrupt on overflow.





    // Set Timer_A2 for ACLK input, countup, no interrupt on overflow.



    // Init the time counting process

    TA3CCTL0 = 0;


    TA3CCTL0 = 0;

    TA3CCTL0 = CCIE;



    I didn't try working without debugger.
    I seldom do that before my program works OK.

    As to the reproducibility of the problem, I will emphasis again:

    • The program runs OK for few seconds or even a minute or two.

    • During this time tens and hundreds of times it passes through this point without a problem.

    • For no external reason that I can see, one time, this phenomena happens.

    • when I am not stopping the program with a breakpoint at this point, the program keeps running, but since the 0x0113b1 code is in the main loop, stuck did not fold back correctly, and after few times the problem happens, the stack overflows, and WDT resets the processor.

    • I want to emphasis that when I do some changes in the code (like adding debug flag setting) the problem might change the frequency of its happenings.
      for instance, in the example code I sent you, adding dbg_RxStatus |= 0x0002; in the line after TA0CCTL1 = 0; and before the call to the routine, would change the frequency of the problem instead of after seconds to after a lot of minutes, sometimes more than an hour.


  • Hi Ofec,

    Thank you for providing a detailed description. I see that you're setting the wait states after initializing your clock to 16MHz . I highly recommend setting the wait states before this initialization is performed. While this might not be the root cause of the issue, it will help rule this out as a part of the problem.

    I haven't been able to reproduce the issue on my end. Since this problem seems to be very timing specific, it could probably be best replicated with a copy of the code you're running. If comfortable, you can send me a private message containing your code so we can better evaluate this issue. I've sent you a friend request and once accepted, you should be able to send me a message. 

    Best regards,
    Caleb Overbay

  • Hi Caleb,

    I have moved the wait state setting to be done before the clock speed setting, with no change regarding the problem.

  • Hi Ofec,

    Let me take over here.

    Can you please post your interrupt handler?

    Many Thanks


  • Hi Ofec,

    Do you still need assistance with this issue or could you provide any updates?

    Best regards,
    Caleb Overbay
  • Dear Caleb,

    Thank you for your interest.
    I am still waiting for a solution to the problem.

    Lukas Badura has taken over, and is looking into the details, but no success so far.

    Since the problem is with the CALLA command, I am currently using the small model, so that I can continue with the developement of my project.
    This is a limited in time solution, because I will need the upper memory eventually.

    Yours, Ofec.