CCS/MSP430FR5889: Program flow break

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.

Ofec.

 

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

WDT_HOLD();        // WDTCTL=WDTPW|WDTHOLD

 

// LEDs Setup

LED_Init();        // GPIOs

LED_ON();

 

// Debug Setup

DEBUG0_INIT();     // GPIOs

DEBUG1_INIT();

DEBUG2_INIT();

DEBUG3_INIT();

 

// 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

//

do

{ // 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

__enable_interrupt();

 

//Set Watch dog timer

WDT_SET();         // WDTCTL=WDTPW|WDTCNTCL|WDTSSEL0|WDTIS__32K

 

// 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.

TA0CTL = TASSEL1|ID1|ID0|MC1|TACLR;

TA1CTL = TASSEL1|ID1|ID0|MC1|TACLR;

TA3CTL = TASSEL1|ID1|ID0|MC1|TACLR;

 

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

TA2CTL = TASSEL0|MC1|TACLR;

 

// Init the time counting process

TA3CCTL0 = 0;

TA3CCR0 = MILISECOND;

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.

Ofec.

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.

Yours,
Ofec.

Hi Ofec,

Let me take over here.

Can you please post your interrupt handler?

Many Thanks

Lukas

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.