This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Please help with Error message

Other Parts Discussed in Thread: MSP430F427

The following is a part of simple code that I input to the CCS.

21    #include "msp430f427.h"

22

23    int main(void)

24    {

25      WDTCTL = WDTPW + WDTHOLD;             // Stop watchdog timer

26      int k;

27      char *pLCD = (char *) &LCDM1;

28      FLL_CTL0 |= XCAP18PF;

29      *pLCD++ = 1;

30      for (k=1; k < 20; k++)

31          *pLCD++ = 0;

 

When I try to "debug", CCS sent the following two error messages:

Severity and Description                                                                       Path     Resource          Location           Creation Time     Id

declaration may not appear after executable statement in block  Lab2    blink_led2.c      line 26  1311571682507          14

declaration may not appear after executable statement in block  Lab2    blink_led2.c      line 27  1311571682507          15

 

Can someone tell me what's wrong with Line 26 and LIne 27 and how to correct it.

By the way, I am using MSP430F427 with the TS430PM64 hardware board.  I did not solder the 32K crystal yet to the hardware target board - and I plan to use the pin 12 to light up the target board LED by toggle the LCDON on and off as experiment.  Is this a problem?  Thanks for any help.

  • TDM-engineer said:
    Can someone tell me what's wrong with Line 26 and LIne 27 and how to correct it.

    The problem is what the error message said: declarations are not allowed to be placed after an executable statement - that's a rule of C language (which later has become watered down by C++).

    You'll either have to move line 25 after line 27, or you switch to C++ (if that fits the needs of your programming environment) **).

    Regards,
    Joern.

     

    P.S.:

    **) Or, if possible, you might switch to C99 by a compiler switch, as in C99 dclarations may be set as used from C++.

  • Thanks.  I cannot believe I made such a stupid mistake.  Once I moved Line 25 after Line 27 everything is fine.

  • That's life! And it's typical behaviour of lots of mistakes, thatswhy always I try to be awake of:

    • My mistakes are never where I'm looking for.
    • My mistakes are always much more simple than I thought.

    ;-)

    Regards,
    Joern.

  • Joern said:
    always I try to be awake of:

    There's a third one: Error messages always have a reason but sometimes also a meaning. So read them carefully and they will probably tell you what's wrong.

    In this specific case. the keywords are 'after' (so there must be something before that error line related to the error) and 'executable statement' (was there an executable statement before? oh yes, there is one.)
    However, if you don't know the differences between C and C++, it won't help you at all, as you might think that everything is as it is intended to. :)

  • Jens-Michael Gross said:
    There's a third one: Error messages always have a reason but sometimes also a meaning.

    :) Thanks, that's actually a valuable third rule, as error messages so terrible often only have a reason, but no meaning (which is lost anywhere by the programmers unfamiliarity yet to use spoken langue), that people get used not to care anymore for the meaning...

  • Joern said:
    but no meaning (which is lost anywhere by the programmers unfamiliarity yet to use spoken langue), that people get used not to care anymore for the meaning...

    I once worked with a guy who thought that warnings can be ignored as they ar eno errors. He got so many warnings in his code that he didn't look a tthem anymore. However, it was his sloppy code and the lack of explicit casts where casting was ambiguous, that caused teh warnings. And of course some of them were indicating real bugs.

    However, the problem is that the tool programmer knows which tools is issuing the message and how this tool works. The typical user today expects a one-click-tool and doesn't care for things like compiler/assembler/linker and what they do. So the messages are meaningless to him. Not because the tool programmer did something wrong, but rather because the user didn't care about what the tools do he's using.

    If you want to drive a car, you'll have to learn how to operate it. Most don't know how a car works, but they at least know the controls and such. But todays computer users are rathe rlike taxi passengers. The sit down and just tell the destination address. And wonder if there are some strange signs are flashing if something goes wrong (as the 'taxi driver ' in this case is no human but an auto pilot)

    There's an universal rule: 'know your tools'. If you don't, things may or may not work, and if they don't, you're lost.

  • Jens-Michael Gross said:
    The typical user today expects a one-click-tool and doesn't care for things like compiler/assembler/linker and what they do.

    I agree with you, completely. And I feel that this distance between typical user and basic knowledge grows and grows, and badly designed but complex frameworks cover previous badly designed but complex frameworks, so-called automatic assistants produce additional fog of information... and I saw people welcoming warnings as a sign that the build process is still alive.

    But nevertheless I think, that in common there is a lack in speech quality of error messages. It might be driven by the fact that much programmers are no native speakers (me first)...

  • Joern said:
    I saw people welcoming warnings as a sign that the build process is still alive.

    Yikes! But you're right :(
    Joern said:
    this distance between typical user and basic knowledge grows and grows
    Yep. If you scan the forum here, you'll find a lot posts indicating that the poster is trying to do 'click together' a complex application from teh examples, not really knowing what these examples do. And this is for a topic where all required information (users guides, datasheets) are available.

    Joern said:
    so-called automatic assistants produce additional fog of information

    Yep. Wizards are nice, but haveing only wizards is bad. I suffer a crashing network connection due to my NAT router sometimes being overloaded by too many outgoing connections. In WinXP, I just deactivated and reactivated the network conneciton and all was well. A matter of seconds. Under Win7, I only have the 'network connection problems wizard' which humms for minutes until it finally - resets the connection. And then still reports a problem. because I of course didn't allow this wizard (I don't even know which exe file is this wizard)  to access the internet by the firewall rules.
    Same applies to many, many, many other things which allow a completely ignorant user to to complex tasks, but at the same time forbits the more experienced user to do these tasks way more effectively.

    Well, a time will come wher every DAU can fly to the moon with a weekend ticket. Wondering why he feels sick halfway up. And why the phone connection to his home has such a long delay. There are already many people wondering why we need power plants - the power is already coming from the wall socket.

**Attention** This is a public forum