EmbeddedRelated.com
Forums
   Forums    More Forums    msp430  

WDT Problem

Started by aekalman ●July 31, 2002
Hi All.

I'm having a problem with the WDT (think) on an 'F149. If I run the 
code (it's Salvo tutorial application tu5) on a 'F123 FET, it works 
fine. If I run the same code, recompiled for the 'F149 FET, it fails, 
and it looks to me like the WDT times out.

I say that because immediately after a full reset, IFG1 is 0x82. I 
start the program and it remains that way through fifteen trips to 
TaskCount() until I find that it has reset itself, and now IFG1 is 
0x83 and I'm back at the start of main(). So, WDTIFG started out at 0 
(good), and after reset it is now 1 (WDT reset). But all the while, 
WDTCTL is 0x6980, i.e. the WDT is disabled.

My initialization code is:

WDTCTL = WDTPW + WDTHOLD;
TACTL  = TASSEL1 + TACLR;
CCTL0  = CCIE;
CCR0   = 10000;
TACTL |= MC1;
_EINT();

and I don't manipulate any other SFRs in the application.

Any ideas? Something having to do with the 'F149's many timers?

Thanks,

Andrew Kalman    aek ... @ ... pumpkininc.com

Beginning Microcontrollers with the MSP430

Reply by Martijn Broens ●July 31, 20022002-07-31

Hi,

 

I've strugled with that isue myself and came up with the following (parts are from the TI's TCP/IP stack)

I first setup the xtal(XT2)  then call lowlevel init and then approx every sec the led blinks. Should work.

 

Succes.

 

static long SystemTimer= 0;               // global timer

// enables the 8MHz crystal on XT2 and use

// it as MCLK

void InitOsc(void)

{

   unsigned int i;

   WDTCTL = WDTPW + WDTHOLD;                      // Stop WDT

   BCSCTL1 &~XT2OFF;                            // XT2on

   do

   {

      IFG1 &~OFIFG;                             // Clear OSCFault flag

      for (i = 0xFF; i > 0; i--);                 // Time for flag to set

   }

   while ((IFG1 & OFIFG) != 0);                   // OSCFault flag still set?               

  

   BCSCTL1 |DIVA0;                              // ACLK = XT2 / 2 = 4MHz

   BCSCTL1 &~DIVA1;

   BCSCTL2 |SELM1+SELS;             // MCLK XT2 8MHz

                                                  // SMCLK = XT2/8 = 1MHz

  

   IE1 &~WDTIE;                                 // disable WDT int.

   IFG1 &~WDTIFG;                               // clear WDT int. flag

 

   WDTCTL =  WDT_MDLY_0_5 ;                       // 0.5ms  

                                                  // WDT-interval times [1ms] coded with Bits 0-2

                                                  // WDT is clocked by fMCLK (assumed 1MHz)

   while (!(IFG1 & WDTIFG));                      // count 1024 pulses from XT1 (until XT1's

                                                  // amplitude is OK)

 

   IFG1 &~OFIFG;                                // clear osc. fault int. flag

 

}

 

void LowLevelInit(void)

{

  SystemTimer=1L;

  TACTL = ID1 | TASSEL1;              // stop timer, use SMCLK / 4 250 kHz = 4us, gen. int.

  TACTL |= MC1;                                 // start timer in continuous up-mode 

  IE1 |= WDTIE;                                 // Enable WDT interrupt

  _EINT();                                      // enable interrupts 

}

 

// Watchdog Timer interrupt service routine

interrupt[WDT_VECTOR] void watchdog_timer(void)

{

  static int i=0;

  if (i++ >= 16000) // 1 sec.

  {

     SystemTimer++;                        // timer for retransmissions

     P1OUT ^0x01;                        // Toggle P1.0 using exclusive-OR

     i=0;

   }

}

 

-----Oorspronkelijk bericht-----
Van: aekalman [mailto:aek@netcom.com]
Verzonden: woensdag 31 juli 2002 21:06
Aan: msp430@yahoogroups.com
Onderwerp: [msp430] WDT Problem

 

Hi All.

I'm having a problem with the WDT (think) on an 'F149. If I run the
code (it's Salvo tutorial application tu5) on a 'F123 FET, it works
fine. If I run the same code, recompiled for the 'F149 FET, it fails,
and it looks to me like the WDT times out.

I say that because immediately after a full reset, IFG1 is 0x82. I
start the program and it remains that way through fifteen trips to
TaskCount() until I find that it has reset itself, and now IFG1 is
0x83 and I'm back at the start of main(). So, WDTIFG started out at 0
(good), and after reset it is now 1 (WDT reset). But all the while,
WDTCTL is 0x6980, i.e. the WDT is disabled.

My initialization code is:

WDTCTL = WDTPW + WDTHOLD;
TACTL  = TASSEL1 + TACLR;
CCTL0  = CCIE;
CCR0   = 10000;
TACTL |= MC1;
_EINT();

and I don't manipulate any other SFRs in the application.

Any ideas? Something having to do with the 'F149's many timers?

Thanks,

Andrew Kalman    aek ... @ ... pumpkininc.com










">Yahoo! Terms of Service.


Reply by aekalman ●July 31, 20022002-07-31
More info ...

In my main loop I added

WDTCTL = 0x5A88;

to reset the WDT on a regular basis, and it made no difference. So my 
reset problem looks like a WDT problem, but the WDT appears to be 
configured properly, and resetting it often via WDTCNTCL make no 
difference. So I don't understand why WDTIFG ends up set after the 
unintended reset ...

Also, I tried

WDTCTL = 0x5588;

and it immediately reset the system, as I expected.

Regards,

Andrew Kalman   aek ... at ... pumpkininc.com
Reply by Bruce Cannon ●July 31, 20022002-07-31
I think you are saying that you set WDTCTL to WDT mode, 32ms interval, and
off (HOLD), and in
addition your main loop both clears and disables the WDT, yet you still get
resets, and on reset
find the WDTIFG set?  For the former, it seems like an errant instruction might
be changing the WDT
configuration.  For the latter, is the period of the WDT clear instruction in
the main loop short
enough to help?

I haven't done this, but I think you can set up a breakpoint in C-Spy when
the WDTCTL register
changes, that could lead you to the errant instruction if that is the source of
the reenablement.
Or, as a reset is caused and the WDTIFG set, if a write to the WDTCTL reg is
done with an incorrect
PW, could that be happening somewhere?  Have you done text searches for WDTCTL
and the register
address?

Bruce

> -----Original Message-----
> From: aekalman [mailto:aek@aek@...]
> Sent: Wednesday, July 31, 2002 12:17 PM
> To: msp430@msp4...
> Subject: [msp430] Re: WDT Problem
>
>
> More info ...
>
> In my main loop I added
>
> WDTCTL = 0x5A88;
>
> to reset the WDT on a regular basis, and it made no difference. So my
> reset problem looks like a WDT problem, but the WDT appears to be
> configured properly, and resetting it often via WDTCNTCL make no
> difference. So I don't understand why WDTIFG ends up set after the
> unintended reset ...
>
> Also, I tried
>
> WDTCTL = 0x5588;
>
> and it immediately reset the system, as I expected.
>
> Regards,
>
> Andrew Kalman   aek ... at ... pumpkininc.com
>
>
>
> .
>
>
>
> ">http://docs.yahoo.com/info/terms/
>
>
>
Reply by Mark Skeels ●July 31, 20022002-07-31
Hi, Andrew,

I'm just a newbie with this '149 and with C, but I had a similar
problem,
and it had nothing to do with the watchdog. I finally realized that my stack
was overflowing. I had to increase the stack size in the IAR compiler link
file, as follows...

/*
Program notes.

1.
Be sure to set the stack size to 120 in the linker command file

"C:\PROGRAM FILES\IAR SYSTEMS\EW23\430\icc430\lnk430m.xcl"

as follows...

-Z(DATA)IDATA0,UDATA0,ECSTR,CSTACK+10000-6FFF

Otherwise, the stack overflows.

see p. 67 of the MSP430 IAR C Compiler manual.

2. end.

*/

This fixed my _reset_ problem......


mes



----- Original Message -----
From: "aekalman" <aek@aek@...>
To: <msp430@msp4...>
Sent: Wednesday, July 31, 2002 2:06 PM
Subject: [msp430] WDT Problem


> Hi All.
>
> I'm having a problem with the WDT (think) on an 'F149. If I run
the
> code (it's Salvo tutorial application tu5) on a 'F123 FET, it
works
> fine. If I run the same code, recompiled for the 'F149 FET, it fails,
> and it looks to me like the WDT times out.
>
> I say that because immediately after a full reset, IFG1 is 0x82. I
> start the program and it remains that way through fifteen trips to
> TaskCount() until I find that it has reset itself, and now IFG1 is
> 0x83 and I'm back at the start of main(). So, WDTIFG started out at 0
> (good), and after reset it is now 1 (WDT reset). But all the while,
> WDTCTL is 0x6980, i.e. the WDT is disabled.
>
> My initialization code is:
>
> WDTCTL = WDTPW + WDTHOLD;
> TACTL  = TASSEL1 + TACLR;
> CCTL0  = CCIE;
> CCR0   = 10000;
> TACTL |= MC1;
> _EINT();
>
> and I don't manipulate any other SFRs in the application.
>
> Any ideas? Something having to do with the 'F149's many timers?
>
> Thanks,
>
> Andrew Kalman    aek ... @ ... pumpkininc.com
>
>
>
>
>
>
> .
>
>
>
> ">http://docs.yahoo.com/info/terms/
>
>
Reply by aekalman ●July 31, 20022002-07-31
--- In msp430@y..., "Mark Skeels" <meskeels@e...> wrote:
> I'm just a newbie with this '149 and
with C, but I had a similar 
problem,
> and it had nothing to do with the watchdog. I
finally realized that 
my stack
> was overflowing. 
[SNIP]

Bad stack would certtainly cause this sort of thing, but I'm only at 
a depth of around 8 ... so I don't think that's it.

Thanks for the suggestion, though :-)

Regards,

Andrew Kalman  aek ... at ... pumpkininc.com
Reply by aekalman ●July 31, 20022002-07-31
Hi Bruce.

--- In msp430@y..., "Bruce Cannon" <brucecannon@a...> wrote:
> I think you are saying that you set WDTCTL to WDT
mode, 32ms 
interval, and off (HOLD), and in
> addition your main loop both clears and disables
the WDT, yet you 
still get resets, and on reset
> find the WDTIFG set?  For the former, it seems
like an errant 
instruction might be changing the WDT
> configuration.  For the latter, is the period of
the WDT clear 
instruction in the main loop short
> enough to help?
It is the former (exactly). And I agree that an errant instruction 
might cause this ... but what has me stumped is why it works on 
the 'F123 and not on the 'F149. Odd.


> I haven't done this, but I think you can set
up a breakpoint in C-
Spy when the WDTCTL register
> changes, that could lead you to the errant
instruction if that is 
the source of the reenablement.
> Or, as a reset is caused and the WDTIFG set, if a
write to the 
WDTCTL reg is done with an incorrect
> PW, could that be happening somewhere?  Have you
done text searches 
for WDTCTL and the register
> address?

I was using the AQ430 tools. I can try it in C-SPY, too ... will 
report back.

Regards,

Andrew Kalman    aek ... at ... pumpkininc.com
Reply by aekalman ●August 1, 20022002-08-01
I found it ...

I had failed to change 

#include <msp430x12x.h> 

to 

#include <msp430x14x.h>

when I moved from the 'F123 to the 'F149. It's pretty bad when
you 
don't follow your own instructions ... :-) 

Anyway, the reason why the right header is required is that, unlike 
the SFR locations, some (but not all) interrupt vectors vary from one 
MSP430 variant to the next. In this application, I was using 
TIMERA0_VECTOR for my ISR:

interrupt[TIMERA0_VECTOR] void Timer_A (void)

and in the 'F123 it's at 

#define TIMERA0_VECTOR      (9 * 2)  /* 0xFFF2 Timer A CC0 */

whereas in the 'F149 it's at

#define TIMERA0_VECTOR      (6 * 2)  /* 0xFFEC Timer A CC0 */

Pretty obvious once it's staring you in the face ...

Thanks for all of your inputs, Martijn & Bruce!

Regards,

Andrew Kalman    aek ... at ... pumpkininc.com
Reply by Bruce Cannon ●August 1, 20022002-08-01
Andrew:

Interesting!  The first thing I thought of was that you had forgotten to change
a part-specific
reference but I looked up the address for WDTCTL in both parts and it was the
same.  I didn't even
think of the vectors, and it wouldn't have occurred to me that they were
different (but now that you
point it out, I get it).

Thanks,

Bruce

> -----Original Message-----
> From: aekalman [mailto:aek@aek@...]
> Sent: Thursday, August 01, 2002 1:26 AM
> To: msp430@msp4...
> Subject: [msp430] Re: WDT Problem -- SOLVED!
>
>
> I found it ...
>
> I had failed to change
>
> #include <msp430x12x.h>
>
> to
>
> #include <msp430x14x.h>
>
> when I moved from the 'F123 to the 'F149. It's pretty bad
when you
> don't follow your own instructions ... :-)
>
> Anyway, the reason why the right header is required is that, unlike
> the SFR locations, some (but not all) interrupt vectors vary from one
> MSP430 variant to the next. In this application, I was using
> TIMERA0_VECTOR for my ISR:
>
> interrupt[TIMERA0_VECTOR] void Timer_A (void)
>
> and in the 'F123 it's at
>
> #define TIMERA0_VECTOR      (9 * 2)  /* 0xFFF2 Timer A CC0 */
>
> whereas in the 'F149 it's at
>
> #define TIMERA0_VECTOR      (6 * 2)  /* 0xFFEC Timer A CC0 */
>
> Pretty obvious once it's staring you in the face ...
>
> Thanks for all of your inputs, Martijn & Bruce!
>
> Regards,
>
> Andrew Kalman    aek ... at ... pumpkininc.com
>
>
>
> .
>
>
>
> ">http://docs.yahoo.com/info/terms/
>
>
>
You might also like... (promoted content)
Check out Memfault's New Sandbox!
Check out Memfault's New Sandbox!
Check out Memfault's New Sandbox!