Hi All,

I have described my problem in detail below. Any clues to resolve 
this issue will be appreciated.

Iam working on an application that uses timer B interrupts which is 
set up to happen at 64hz. This interrupt resets the watchdog timer to 
go off in 1 sec. Since the timer B interrupt resets the watch dog 
timer every 64th of a second the watch dog never re-starts the 
program and this is the desired behavior. Now, I have some routines 
that require interrupts to be disabled. So, I have the interrupts 
disabled and the watchdog timer turned off to avoid re-start and then 
enable interrupts after the routine. Upon excuting the program this 
non-interrupt routine is executed completely no matter how long, but 
the processor re-starts 1 sec after the routine is finished and the 
interrupts were enabled. I replaced the routine with a simple wait 
loop and the problem still exists if the wait is in ms. If the wait 
is in micro seconds, everything seems to work fine. 

Any clues on what I can check? Any ideas on how I can check if the 
timer B interruts are still occuring at 64hz? 

Thanks all.

The simplest way is to use an I/O pin to toggle a signal every time the 
64hz event occurs. You don't state your clock frequency. How long does 
the uninterruptible routine take to execute? By restarts do you mean 
that the program resets itself? This could be due to other issues, you 
can trap this by using the emulator. Run your program to a point where 
the clcoks are stable and initialisation has occured, then set a 
breakpoint at the RESET address, ie start of program. then run your 
program. if it resets then I would use the NMI vector to discover what 
is causing the reset event. If it isn't an NMI, keep the WDT disabled 
and see what happens. Finally when you re-enable interrupts are you 
allowing for the fact that while disabled the interrupt flags are still 
set, so you may have a queue of interrupts that prevent your 64hz 
routine from being accessed.

Cheers

Al

amber_ansari94 wrote:

>Hi All,
>
>I have described my problem in detail below. Any clues to resolve 
>this issue will be appreciated.
>
>Iam working on an application that uses timer B interrupts which is 
>set up to happen at 64hz. This interrupt resets the watchdog timer to 
>go off in 1 sec. Since the timer B interrupt resets the watch dog 
>timer every 64th of a second the watch dog never re-starts the 
>program and this is the desired behavior. Now, I have some routines 
>that require interrupts to be disabled. So, I have the interrupts 
>disabled and the watchdog timer turned off to avoid re-start and then 
>enable interrupts after the routine. Upon excuting the program this 
>non-interrupt routine is executed completely no matter how long, but 
>the processor re-starts 1 sec after the routine is finished and the 
>interrupts were enabled. I replaced the routine with a simple wait 
>loop and the problem still exists if the wait is in ms. If the wait 
>is in micro seconds, everything seems to work fine. 
>
>Any clues on what I can check? Any ideas on how I can check if the 
>timer B interruts are still occuring at 64hz? 
>
>Thanks all.
>
>
>
>
>
>.
>
> 
>Yahoo! Groups Links
>
>
>
> 
>
>
>
>
>
>  
>

Thanks Al! It was pending interrupts. Once I cleared the interrupts 
flags before enabling all interrupts, the program re-start problem 
disappeared! 

Thanks a bunch!

Amber


--- In msp430@msp4..., Onestone <onestone@b...> wrote:
> The simplest way is to use an I/O pin to toggle a
signal every time 
the 
> 64hz event occurs. You don't state your clock
frequency. How long 
does 
> the uninterruptible routine take to execute? By
restarts do you 
mean 
> that the program resets itself? This could be due
to other issues, 
you 
> can trap this by using the emulator. Run your
program to a point 
where 
> the clcoks are stable and initialisation has
occured, then set a 
> breakpoint at the RESET address, ie start of program. then run your 
> program. if it resets then I would use the NMI vector to discover 
what 
> is causing the reset event. If it isn't an
NMI, keep the WDT 
disabled 
> and see what happens. Finally when you re-enable
interrupts are you 
> allowing for the fact that while disabled the interrupt flags are 
still 
> set, so you may have a queue of interrupts that
prevent your 64hz 
> routine from being accessed.
> 
> Cheers
> 
> Al
> 
> amber_ansari94 wrote:
> 
> >Hi All,
> >
> >I have described my problem in detail below. Any clues to resolve 
> >this issue will be appreciated.
> >
> >Iam working on an application that uses timer B interrupts which 
is 
> >set up to happen at 64hz. This interrupt
resets the watchdog timer 
to 
> >go off in 1 sec. Since the timer B interrupt
resets the watch dog 
> >timer every 64th of a second the watch dog never re-starts the 
> >program and this is the desired behavior. Now, I have some 
routines 
> >that require interrupts to be disabled. So, I
have the interrupts 
> >disabled and the watchdog timer turned off to avoid re-start and 
then 
> >enable interrupts after the routine. Upon
excuting the program 
this 
> >non-interrupt routine is executed completely
no matter how long, 
but 
> >the processor re-starts 1 sec after the
routine is finished and 
the 
> >interrupts were enabled. I replaced the
routine with a simple wait 
> >loop and the problem still exists if the wait is in ms. If the 
wait 
> >is in micro seconds, everything seems to work
fine. 
> >
> >Any clues on what I can check? Any ideas on how I can check if the 
> >timer B interruts are still occuring at 64hz? 
> >
> >Thanks all.
> >
> >
> >
> >
> >
> >.
> >
> > 
> >Yahoo! Groups Links
> >
> >
> >
> > 
> >
> >
> >
> >
> >
> >  
> >

My pleasure, glad I was of some use to somebody ;?}

Al

amber_ansari94 wrote:

>Thanks Al! It was pending interrupts. Once I
cleared the interrupts 
>flags before enabling all interrupts, the program re-start problem 
>disappeared! 
>
>Thanks a bunch!
>
>Amber
>
>
>--- In msp430@msp4..., Onestone <onestone@b...> wrote:
>  
>
>>The simplest way is to use an I/O pin to toggle a signal every time 
>>    
>>
>the 
>  
>
>>64hz event occurs. You don't state your clock frequency. How long 
>>    
>>
>does 
>  
>
>>the uninterruptible routine take to execute? By restarts do you 
>>    
>>
>mean 
>  
>
>>that the program resets itself? This could be due to other issues, 
>>    
>>
>you 
>  
>
>>can trap this by using the emulator. Run your program to a point 
>>    
>>
>where 
>  
>
>>the clcoks are stable and initialisation has occured, then set a 
>>breakpoint at the RESET address, ie start of program. then run your 
>>program. if it resets then I would use the NMI vector to discover 
>>    
>>
>what 
>  
>
>>is causing the reset event. If it isn't an NMI, keep the WDT 
>>    
>>
>disabled 
>  
>
>>and see what happens. Finally when you re-enable interrupts are you 
>>allowing for the fact that while disabled the interrupt flags are 
>>    
>>
>still 
>  
>
>>set, so you may have a queue of interrupts that prevent your 64hz 
>>routine from being accessed.
>>
>>Cheers
>>
>>Al
>>
>>amber_ansari94 wrote:
>>
>>    
>>
>>>Hi All,
>>>
>>>I have described my problem in detail below. Any clues to resolve 
>>>this issue will be appreciated.
>>>
>>>Iam working on an application that uses timer B interrupts which 
>>>      
>>>
>is 
>  
>
>>>set up to happen at 64hz. This interrupt resets the watchdog timer 
>>>      
>>>
>to 
>  
>
>>>go off in 1 sec. Since the timer B interrupt resets the watch dog 
>>>timer every 64th of a second the watch dog never re-starts the 
>>>program and this is the desired behavior. Now, I have some 
>>>      
>>>
>routines 
>  
>
>>>that require interrupts to be disabled. So, I have the interrupts 
>>>disabled and the watchdog timer turned off to avoid re-start and 
>>>      
>>>
>then 
>  
>
>>>enable interrupts after the routine. Upon excuting the program 
>>>      
>>>
>this 
>  
>
>>>non-interrupt routine is executed completely no matter how long, 
>>>      
>>>
>but 
>  
>
>>>the processor re-starts 1 sec after the routine is finished and 
>>>      
>>>
>the 
>  
>
>>>interrupts were enabled. I replaced the routine with a simple wait 
>>>loop and the problem still exists if the wait is in ms. If the 
>>>      
>>>
>wait 
>  
>
>>>is in micro seconds, everything seems to work fine. 
>>>
>>>Any clues on what I can check? Any ideas on how I can check if the 
>>>timer B interruts are still occuring at 64hz? 
>>>
>>>Thanks all.
>>>
>>>
>>>
>>>
>>>
>>>.
>>>
>>>
>>>Yahoo! Groups Links
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> 
>>>
>>>      
>>>
>
>
>
>
>
>.
>
> 
>Yahoo! Groups Links
>
>
>
> 
>
>
>
>
>
>  
>