OFIFG flag set and system resets in MSP430F1611

If the OFIE bit of IE1 is set in your code then the fault is pretty likely to be related to the OFIFG.  If you do not enable the OFIE bit then the problem is likely to be elsewhere.  Does the problem seem to occur at the same place every time or is it random?  Without seeing your code I can only speculate...

 

Do you disable the XT2 before entering the LPM?  The 1xx user guide says that:

"When XT2 or LFXT1 in HF mode is stopped with software the XT_OscFault signal becomes active immediately, remains active until the oscillator is re-started, and becomes inactive approximately 50 µs after the oscillator re-starts". 

If you do disable XT2 it looks like you have to be very careful about when the OFIE is set in order to avoid an NMI.

Yes I shutoff XT2 when I go to LPM. I am not enabling the OFIE bit at all. (I just did it to debug my code). Without OFIE enabled, my system resets itself.

My 'call stack' feature in IAR is empty. Instead of giving me the function which caused this error, the call stack just says PC = 0x0000, as if it is beginning from the first.

 

I went through the reset check list in these forums.

1. I am running of the Benchtop power supply. So I dont think power fluctuations is causing my PC to reset.

2. I have put a breakpoint at '0x0000' and when it hits it, my stack is still intact, so it cannot be a stack overflow.

3. I have the watchdog disabled, so it cannot be the watch dog.

4. Only my OFIFG flag is set...

 

What else can I check to find out the root cause of my reset?  Actually I am assuming it is a reset, maybe some null pointer gets dereferenced and PC goes to 0x0000 without ever going to reset vector. How do I verify if my reset vector is getting called or not?

 

 

 

 

To look for a reset just stick a breakpoint at the start of main (or wave a GPIO at the start of main or something similar).  The reset vector is at 0xFFFE but breakpoints at this address might not catch it.

Address 0x0000 should be the IE1 register - the PC should never be set to this value so it looks like you might have some sort of runaway problem - have a lookout for looping or array access errors.  Are you using any assembler or intrinsic commands that set the PC value?

I am using IAR Embedded workbench IDE. So I put a breakpoint at 0x0000. I hit that breakpoint when this error occurs. So the question is, Is something calling the reset_vector or is the PC getting set to 0x0000 while executing something (say some of my code like a loop). Now if the PC gets set to 0x0000 for some code violation, I was still expecting my 'callstack' feature to tell me where this jump occured. But my 'callstack' is completely cleared. Does that mean the reset_vector was called?

Also, this problem seems to go away when I handled the OFIFG flag in a NMI. I am going to run a simplified version of my code and see if this problem occurs. If it does, then I can post that code here.

btw, I am not using any assembly. I am using the '__bis_SR_register'  and '__low_power_mode_4', __low_power_mode_3  intrinsic commands.

-santhosh

 

 

 

The PC should never be set to 0x0000, not even after a reset.

If it is, you have a serious bug in your code. There are several things which can set the PC to 0x0000:

1. a stack overflow (which you deny)
2. an interrupt vector pointing to 0x0000 (or 0xffff, which lets the PC address overflow to 0x0000 as well)
3. a call to 0x0000 (maybe an indirect or register-based call, which is normally not generated by the compiler but may be the result ow the processor running through data instead of code). This should be visible on the call stack, but with wild code, the debugger can't really interpret the stack
4. a br instruction with 0 as direct or indirect argument or any other instruction that uses R0 as destination register. e.g. a CLR R0.

The fact that you see OFIFG being set too seems to indicate that either the hardware is failing or the code is doing something unwanted prior to jumping into the void. Maybe wildly reprogramming the clock module registers or whatever.

If you implement the NMI ISR and set a breakpoint to there, the stack should contain the address at which the OFIFG happened. You should check whether this is still some valid piece of code or already something in the wild.

Santhosh said:

But my 'callstack' is completely cleared. Does that mean the reset_vector was called?

Not necessarily. I tmeans that no information can be extracted. Either because the stack is empty (you're still in main or at least it seems so) or the stack is messed-up so no valid stack frame can be found. Remember, the stack contains not only return addresses, but also local variables (which can easily overwrite a return address when there is a local array written to with an index out-of-bounds), the status register during an ISR execution, temporarily saved register contents during a function call etc. There is no way to 100% identify the meaning of the stack content. Only if the debugger knows where the processor is and what should be on the stack at this point, some usable information can be constructed. But only if the assumptions are right. If the code runs wild, the stack at a given point may contain something completely different from what should be there if this point was reached in the expected manner (through funciton calls etc.) and the callstack cannot generate any usable information. (e.g. if what is assumed to be a return address is an odd value, this cannot be. Return addresses are always even values)

If I could observe the system at runtime, with access to the debugging session, I could perhaps say more.

Or if I had the complete source code, maybe I could see something, but without a hint where to start the search this would surely exceed my spare time.

Jens-Michael,

Thanks for the suggestion. I liked your NMI idea, so I went ahead and did that. The NMI gets called from legal code. I tried to be very fancy with the clocks. I turn off the XT2 and turn it back on only inside my ISR. But I didn't want to put a while loop inside the ISR, so I did this inside my ISR

static void TurnOnXT2Osc (void)
{

//Max DCO
   DCOCTL = DCO0 +  DCO2;
  
   // XT2ON + LF mode + No divider + XT5V Reset + RSEL value for max DCO
   BCSCTL1 = RSEL0 + RSEL1 + RSEL2;
   BCSCTL1 |= ~XT2OFF & ~XTS & ~DIVA1 & ~DIVA0 & ~XT5V;
  
   // Clear OSCFault flag
   IFG1 &= ~OFIFG;

}

I wait for 5ms and then check to see if the XT2 is settled. (I measure that 5ms from my 32khz). Now the problem goes away when I clear the OFIFG flag inside the NMI ISR.

So there seems to be some problem with me taking off the 'do while' loop which usually follows the turning ON the XT2. Can that create this problem?

Also, my CPU is sourced with the DCO at the beginning of this function and I am messing with the DCO register Can this create a problem?

 

-santhosh

 

 

Depending on the MSP series, OFIFG can be always cleared, but get set again after soem time if the crystal does not oscillate properly. Newer MSPs (5x series and maybe others), OFIFG is the ORed result of different OF bits, which are set on a fault and reset after the fault condition was removed and stays so for some (long) time. OFIFG cannot be cleaed as long as one of these bits is set and mus tbe cleared manually once they are all clear.
On the 1x series, howecer, OFIFG stays clear for some time after you cleared it and you need to wait some time to ensure it stays clear. It is a good idea to use a timer for the delay (it has be long enough, up to 100ms on some devices). Anyway, in teh ISR, you have to check whetehr OFIFG is still clear (then all is well and you can continue) or it ahs to be cleared. If it has, you'll have to wait again. A single wait won't help.

Santhosh said:

Also, my CPU is sourced with the DCO at the beginning of this function and I am messing with the DCO register Can this create a problem?

Not with the crystal, but there are several possible pitfalls. If you change the DCO taps, it is possible that you accidentally select a setting that exceeds maximum frequency. Also, during the switch, the current clock cycle may be unintentionally shortened (see the errata lists of the device). It is advisable to activate the MCLK prescaler (/2) so a spike will just add to the next valid clock cycle and the CPU will not try to execute an instruction in the time of the spike (which may cause irregular behaviour).

Anyway, workign on the DCO shouldn't affect the crystal operation. On the nw MSPs, hopwever, one of the mentioned OF bits refers to the DCO. Thi sisn't because the DCO can fail (it will always work), but it rather indicates that the DCO setting is at the lowest or highest tap. This is a fault in conjunction with the FLL function which tries to adjust the DCO to a reference clock. Reachign the highest or lowest tap means that the adjusting has hit the borders and indicates a fault condition. On these devices, you cannot clear OFIFG if the DCO is on the lowest or highest tap.

BTW: I hope your 32kHz crystal is running (OFIFG does only check XT1 in HF mode, not in LF mode), else your intended 5ms delay can take eternally.