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.

CCS/MSP430FG4618: An incorrect compiling of C code.

Part Number: MSP430FG4618
Other Parts Discussed in Thread: MSP-EXP430FG4618,

Tool/software: Code Composer Studio

I got an incorrect compiling of C code in very simple code sample.

As we can see in the picture. The C language code in line 25 is not compiled. In disassembly there appears just line 27.

This is the CCS project (Managed CCS before) for MSP430FG4618. All settings are default. It is lunched on standard MSP-EXP430FG4618 board. A CCS version is 9.2 with all updates.

After some unsuccessful investigationusing volatile on variables, playing with settings for optimization. It was obtained - when a comment on line 24 is removed. We will get a correct result:

I attached both C files for testing.

Test_1.c
#include <msp430xG46x.h> 
#define BUTT1 0X01  // p1.0
#define BUTT2 0X02 // p1.1
#define LED1 0X04   // P2.2
#define LED2 0x02   // P2.1
#define BMASK	BUTT1 + BUTT2		// Button mask
#define B_DEL_VAL	10		// Adjust it during work
void main(void)
{
volatile unsigned char	Butt_S1=BUTT1 + BUTT2;
volatile unsigned char	B_Del_Cnt=B_DEL_VAL;
volatile unsigned char	X;				// temporary result
WDTCTL = WDTPW+WDTHOLD;	// stops the WDT
P2DIR = LED1 + LED2;	// switch to output
P2OUT |= LED1 + LED2;	// switch on
while(1)
	{
	X=P1IN & BMASK;
	if(X == Butt_S1)
		{	// The buttons aren�t changed
		B_Del_Cnt--;
		if(B_Del_Cnt==0)
			{	// Debouncing delay is finished
				// Button processing
		    if((Butt_S1 & BUTT1) == 0)
		    {
		        P2OUT |= LED2;
		    }
            if((Butt_S1 & BUTT2) == 0)
            {
                P2OUT &= ~LED2;
            }

			B_Del_Cnt=B_DEL_VAL;		// Prepare the next cycle

			}
		}
	else
		{	// NEWSTAT
		Butt_S1=X;				// Restart debouncing

		B_Del_Cnt=B_DEL_VAL;
		}

	// NEXT
	//  There will be other tasks in main cycle

	};

}

 

Test_2.c
#include <msp430xG46x.h> 
#define BUTT1 0X01  // p1.0
#define BUTT2 0X02 // p1.1
#define LED1 0X04   // P2.2
#define LED2 0x02   // P2.1
#define BMASK	BUTT1 + BUTT2		// Button mask
#define B_DEL_VAL	10		// Adjust it during work
void main(void)
{
volatile unsigned char	Butt_S1=BUTT1 + BUTT2;
volatile unsigned char	B_Del_Cnt=B_DEL_VAL;
volatile unsigned char	X;				// temporary result
WDTCTL = WDTPW+WDTHOLD;	// stops the WDT
P2DIR = LED1 + LED2;	// switch to output
P2OUT |= LED1 + LED2;	// switch on
while(1)
	{
	X=P1IN & BMASK;
	if(X == Butt_S1)
		{	// The buttons aren�t changed
		B_Del_Cnt--;
		if(B_Del_Cnt==0)
			{	// Debouncing delay is finished

		    if((Butt_S1 & BUTT1) == 0)
		    {
		        P2OUT |= LED2;
		    }
            if((Butt_S1 & BUTT2) == 0)
            {
                P2OUT &= ~LED2;
            }

			B_Del_Cnt=B_DEL_VAL;		// Prepare the next cycle

			}
		}
	else
		{	// NEWSTAT
		Butt_S1=X;				// Restart debouncing

		B_Del_Cnt=B_DEL_VAL;
		}

	// NEXT
	//  There will be other tasks in main cycle

	};

}

 

Regards,

Juris

  • The problem is the line endings in Test_1.c are incorrect.  To be specific, the line ending of line 24 is wrong.  Thus, the comment that begins on line 24 is still in effect on the apparent line 25.  This causes all of the apparent line 25 to be ignored.  

    The text editor built in to CCS does not show this problem.  Neither does several other text editors, including notepad and wordpad.  However, gvim does show the problem.  In this screen shot, gvim is configured to show line numbers on the left, and uses syntax highlighting.  

    A more precise way to see the problem is with the command cat.  This command comes from Unix.  It dumps a text file at the command line.  I use the cat command line arguments -vT.  This means every tab character is represented by ^I, every carriage return character is represented by ^M, and every line feed character is represented by ending the current line and starting a new one.  Here is a screen shot of the key lines for the command cat -vT Test_1.c ...

    Notice how the comment // Button processing is followed by a carriage return, no line feed, then two tabs, some space, and then if((Butt_S1 & BUTT1) etc.  The compiler views all of this as one long comment.  For comparison, here is the screen shot of those same lines for Test_2.c ...

    Thanks and regards,

    -George

  • Hi George,

    So your saying we should avoid adding comment marks // on the same line as { } directives? I have never seen earlier version compilers do what you are stating above. Of late I mix comments between // and /*/ but do try to keep each type on a single comment line. Next I would say the edit window is very narrow and pushes us to avoid white space as to view logic syntax together without zoom function.

    Also being avid 3D CAD designer for 3 decades, drag window would be nice addition to edit feature, scroll bar has rapid flight speed. That is a major beef I have with web browsers, PDF viewers as if programmers have ignored rapid vertical scroll movement. Simply nuts for most standard infrared reflective mouse to produce a smooth scroll via human hand. 

  • BP101 said:
    So your saying we should avoid adding comment marks // on the same line as { } directives?

    No.  In this particular case, the line endings on one line were wrong.

    Thanks and regards,

    -George

  • Hi George,

    Sorry I don't see the problem you are describing exists in posters code line

    Oddly I had the same issue yesterday but the line was not wrong only { // MyRemarks was in several line places. After removing comments to a dedicated line, cleaned project several times, another modules functions with (>> or <<) operations did not correctly compile, yet no errors posted.

    I was pulling my hair out for several hours trying to figure out what had gone wrong CCS9.1 (v18.12.3.LTS). Only after changing all 16 lines with directive int0=(int0 << 4) + (int1 >> 4); to (int1 >> 8) and CTRL-Z back to (int1 >> 4) re-compile did the code actually start to work again. 

    The compiler is misbehaving in Intel quad core and the poster is correct to report a line missing. Far as I can tell from screen shots poster was right and you are wrong!

  • I know the compiler or IDE was dropping code lines as 8 variables sent serial via UART to external world were shifted into non associated symbol addresses. This may be a IDE history issue since CTRL-Z appears to have magically returned the ghosted code lines and fixed the 16 integer array pops inside the CCS editor. Even closed CCS several times yesterday and today the ghosted editior code lines was fixed by CTRL-Z.

    Yet they were all there in the edit window but missing in the compiled code hexTobin! 

  • Hi George,

    Yes I can see the problem you pointed out in hex editor as well. Actually the file is preparation for student's laboratory work for years. It was used just on windows systems and mainly edited on CCS. This year we got an algoritm crash on several computers. I do not have any ideas when we lost this LF, but it is not done intentionally.

    For everybody: Is it possible to do something to eliminate this problem?   

    Thank you a lot for support,

    Best regards,

    Juris