msp430f5438 watchdog timer too short

Right, seriously I don't mean to be abusive and please don't take it personal BUT:

1. 8mHz ??? Is that 8 milli Herz??? So 8 oscillations in thousand seconds??? Really??? I don't think that you can divide 32kHz that far with an MSP430 clock system;
2. Ok, I bet you meant 8MHz -- that's 8 MEGA herz or 8 million oscillations in a second. Still, you can't get that from a 32kHz crystal so you're probably using DCO clock;
• ephraim oved

  Is there a way to get wdt time greater then 10 seconds.
Yes, trigger every so often and count the trigger times and when you've counted far enough (well more than 10 seconds in your case) then do whatever you need to do.

Unfortunately the quality of information you've given doesn't lend itself to any better advise.

Arturs Elksnis

8mHz ??? Is that 8 milli Herz??? So 8 oscillations in thousand seconds??? Really??? I don't think that you can divide 32kHz that far with an MSP430 clock system;

It's one timer interrupt every 125 seconds. The watchdog timer can be programmed to produce one interrupt every 32kHz/2G = 29536 seconds = 18:12:16.

Other possible intervals with 32kHz source are 1:08:16, 4:16, 16 or 1s. Or 250, 15,6 or 1,95ms.
About three times as much when using the VLO clock. (but then the outcome is somewhat uncertain as VLOclock has a large drift and tolerance.

Arturs Elksnis

I've got lots to learn myself.

Well, these large spans are new on the 5x family. On the other families, the WDT was way more limited. Especially on teh 1x family, wher eon the devices with more ram the WDT could expire before the variables were initialized and our code started executing at all.
That's IMHO why CCS does not clear uninitialized variables/arrays on startup, which is not necessary by the C standard but done by almost all other C compilers.

Jens-Michael Gross

That's IMHO why CCS does not clear uninitialized variables/arrays on startup, which is not necessary by the C standard but done by almost all other C compilers.

All documented arguments I've seen note that, since C90, this is required by the C standard.  See http://lwip.wikia.com/wiki/Why_are_global_variables_not_initialized_to_zero%3F and http://stackoverflow.com/questions/2617196/c-static-variables-and-intialization

Section 4.9 "Initialization" in the 1978 edition of "The C Programming Language" by Kernighan and Ritchie also states that initialization to zero is done at compile time.  So CCS may have had a reason for failing to do so, but it's never been consistent with the contemporaneous C standard (unless that was broken somewhere between K&R and the first ANSI  standard, which I'm willing to assume didn't happen).

I don't think the reason is good either; CCS could very well have reset the watchdog as necessary while initializing memory.

Peter Bigot

All documented arguments I've seen note that, since C90, this is required by the C standard.

But CCS never states compliance with C90 standard. 'C' doesn't necessarily mean 'newer standard than the original'. The compiler manual explicitly lists where the compiler follows K&R, but this doesn't mean it does so for the other topics too.

Peter Bigot

I don't think the reason is good either; CCS could very well have reset the watchdog as necessary while initializing memory.

The described reason was only a guess. MSPGCC originally simply turned the watchdog off without notice (a really big issue).
If someone wants a variable to be initialized as zero, he shall do so. Uninitialized variables are uninitialized. That's at least understandable. But a watchdog that's off while all datasheets tell it is on after power-up is much less understandable.
I once, I wrote my own start-up code for MSPGCC that indeed triggers the WDT during initialization. However, when start-up time is an issue, the added execution time (about twice the original time for the zeroing loop) is definitely something to consider.

Also, this 'feature' is well documented in the CCS compiler manual. It's only that nobody reads manuals these days - It is assume that things are as one expects them, and if not, a forum post is thrown out.

Peter Bigot

Kernighan and Ritchie also states that initialization to zero is done at compile time

This means that variables explicitely initialized to zero (by adding "=0" to the definition) are put into initialized data segment and have their zero value stored in flash like any other initialization value.
However, carrying a copy of an uninitialized 2k array as 2k of zeroes in flash memory is definitely a waste of space. PC programs tend to not care for their own executable size, carrying MB-sized empty segments around. But on systems with limited resources this is simply a no-go. Standard or not. Standards have ben 'improved' all the tiem for various reasons, including pure convenience or even less understandable reasons. Not following such an 'improvement' for hard resource constraints is IMHO more than valid.

Jens-Michael Gross

The described reason was only a guess.

Jens-Michael Gross

That's IMHO why CCS does not clear uninitialized variables/arrays on startup, which is not necessary by the C standard but done by almost all other C compilers.

The proposed explanation of CCS behavior was stated as an opinion; the statement that its failure to present global variables as though they had been initialized to zero was not required by the C standard was presented as fact.  It is false.

Jens-Michael Gross

Peter Bigot

Kernighan and Ritchie also states that initialization to zero is done at compile time

This means that variables explicitely initialized to zero (by adding "=0" to the definition) are put into initialized data segment and have their zero value stored in flash like any other initialization value.

I apologize; I mis-summarized.  The actual source document states:

K&R1e sect 4.9

In the absence of explicit initialization, external and static variables are guaranteed to be initialized to zero; automatic and register variables have undefined (i.e., garbage) values. ... For external and static variables, the initialization is done once, conceptually at compile time.

Thus a run-time initialization prior to transferring control to main() is perfectly acceptable.

There is no "improvement" here; CCS' behavior is strictly contrary to the language as it has existed since 1978.  It's good that the improper behavior is documented in the manual, but there's no reason to suggest that developers should be blamed for assuming that the default behavior of a language implementation conforms to the language specification, especially in something so fundamental.

AFAIK if you compile to EABI using CCS5 the toolchain does clear BSS segment by default; I recall that it caused quite a bit of grief for ppl upgrading from previous versions relying on the non-standard behaviour, since it caused the watchdog to reset indefinitely during initialization. Not sure if this was solved or not, but yeah I could understand why they made the non-standard behaviour the default.

Tony

Peter Bigot

the statement that its failure to present global variables as though they had been initialized to zero was not required by the C standard was presented as fact.  It is false.

I know that you're usually quite firm regarding the standards (I'm not - I'm an engineer and I take things as they come and not as they should be). But your citation made me fetch my own copy of K&R (yes, I have one) from the shelf. it is in German, but I don't think this makes much of a difference.

Your citation is correct, yet I doubt it applies at all to this case.

According to K&R, "int data;" is an incomplete definition. As such, if done on global scope, it has to be initialized to default value, which is 0 for this data type.
However, since it is a definition, it may only appear once in a project. You cannot e.g. include it by a header file into several compilation units. Doing so would lead to a linker error since the same variable is defined multiple times in the project.
So if 'data' has been defined in one compilation unit, it may only be declared in others by using 'extern' declaration.
Now current compilers are smart neough to allow multiple incomplete definitions wihtout throwing an error, creating the storage location only once. This behavior effectively turns the incomplete global definition into an auto storage type. Whose initial value is undefined.
This is logical too. Since the global variable defined with an incomplete definition is not associated wiht a specific compilation unit, it's initial value is equally undefined for any compilation unit that uses it.

Peter Bigot

the language as it has existed since 1978

Well, K&R is dated '78. C itself is older. It was developed between '69 and '73 at Bell labs. The book form '78 was just the first major publication 'for the masses'.

However, the non-initialization of variables with incomplete definition is surprising for those who are accustomed to have them initialized. But if someones code relies on a variable being zero at the beginning, he should invest those additional two bytes in the source code and explicitely initialize them.
BTW: some compilers produce debug compilations without, and only release compilations with auto-zeroing of incompletely defined variables.

"Faced with the choice between changing one's mind and proving there is no need to do so, almost everyone gets busy on the proof."

  --  John Kenneth Galbraith

Peter Bigot

"Faced with the choice between changing one's mind and proving there is no need to do so, almost everyone gets busy on the proof."
  --  John Kenneth Galbraith

Well, he was a politician and advisor to several presidents. For a president, changing his mind means he agrees that he was wrong before. Which is unthinkable for a president.

But for normal people, this citation is wrong. Most people will change their mind easily if someone just offers a different opinion with at least a minimum of persuasion. In the face of a different opinion, checking the own one (or its source) against independent sources, rather than to obliterate without questioning, is the only reason why whe don't still think the earth is flat.

However, I did the checking and came up with the conclusion that here is no right or wrong but that this case is simply not covered in the original K&R due to other differences. And CSS never stated to be fully compliant to K&R or any other standard.

I totally agree to your opinion that clearing uninitialized variables at startup should be done (as long as there isa way to intentionally leave some dataspace uninitialized, which is vital for some microcontroller applications). I just disagreed that it is a neccessity by a standard the compiler never claims to comply to. (And I figured out that it is not truly the case anyway)

If following a standard for its own sake is such a high goal, why are there ever multiple, not even always backwards compatible standards for a single topic? Or with Microsofts words: why should we follow our own yesterday standard if a different way seems more profitable today?

At the end, this whole discussion is pointless. CCS works as it works, it is documented how it works and if you don't like it you can use a different compiler. (Well, I guess you're using MSPGCC anyway :) )
The most important information form this thread is that seemingly CCS has changed its former behavior with the switch to ELF (EABI) output format. I wonder whether this is documented. It already caused havoc for many people whose old projects suddenly stop working. Operation successful, patient dead.