__delay_cycles(); fully mess up variables in MSP430 memory

[János "Dobfék" Istvánfy]

Hi list!

I've got problem with the __delay_cycles(); in CSS.
I've made a demo code to show the exact problem:


int main()
{
WDTCTL = WDTPW + WDTHOLD;
P1DIR |= 0x1;
P1OUT &= ~0x1;

char str[]="ABCD";
char a[]="0";
char b[]="0";
char c[]="0";
char d[]="0";

for(;;)
{
// __delay_cycles(500000);
a[0]=str[0];
b[0]=str[1];
c[0]=str[2];
d[0]=str[3];
P1OUT |= 0x1;
// __delay_cycles(500000);
P1OUT &= ~0x1;
}
}

If you run it and debug, in CSS 4.2.3.00004 in the Local window, the
str[] contains "ABCD", the a is "A", the b is "B", the c is "C", and
the d is "D", as it should be. But when I remove the comment slashes,
all the variables are messed up! The str[] contains
null,null,null,"A". a is "C","D". b is null,"0". c is "A",null. And d
is "B",null.

Please try it in newer versions of CSS to see if that bug still in it,
or repaired.

Thanks!
Dobfek

[Nemo oZ]

I'm really a total newbie at this, but maybe it should be "_delay_cycles(500000);"? you use two of _, and make it __delay_cycles(500000);

[János "Dobfék" Istvánfy]

Thanks for your answer Nemo oZ!

CSS accepts the command with one, or two underlines too, but in TI
codes, and 3rd party refs uses the version with two underlines.
So the problem is the same with one or two underlines too.

[Joe Moore]

500,000 is larger than a 16-bit integer can hold.

So when you compile your code, the 500,000 is converted (silently) to
whatever it is mod 65536.

--Joe

--
Sent from my mobile device

[János "Dobfék" Istvánfy]

Thanks Joe! :)

You are right, you "can only" put ulong numbers(written in the
reference) into __delay_cycles(), but if you write in huge numbers,
like 2 million cycles, it still works(and messes up the debugger).
I've tried with some smaller numbers, from ulong numbers, and the
biggest number which let the debugger work right is around 30.... Yes,
30 cycles... it's a shame... it can be a compiler optimisation-CCS
related bug. I've updated to CCS 4.2.4, the problem still there.

I've made a code to test the uC's memory to see if it's corrupting the
variables, or not.

int main()
{
WDTCTL = WDTPW + WDTHOLD;
P1DIR |= 0x1;
P1OUT &= ~0x1;

char str[]="1010";

char a[]="0";
char b[]="0";
char c[]="0";
char d[]="0";

for(;;)
{

__delay_cycles(500000);
a[0]=str[0];
b[0]=str[1];
c[0]=str[2];
d[0]=str[3];

if(a[0]=='1'&&b[0]=='0'&&c[0]=='1'&&d[0]=='0')
{
P1OUT |= 0x1;
}
__delay_cycles(500000);
P1OUT &= ~0x1;

}
return 0;
}

Yes, I know it's still not rocket science... :D But the red LED
happily blinks, shows my variables are correct! :)
CCS debug still bad...

[Paolo Di Prodi]

Using delay_cycle is not a good practice because we are wasting power cycles,
you should always use timers and you will not have that problem.
The dirty option is to do a for loop with a nested __delay_cycles() but is horrible!

--
Dr. Paolo Di Prodi

[Adrián Horváth]

If you dont want to do anything else for example just toggle a LED
every XY seconds its the easiest way as I think... On a given
processor frrequency you can count exactly how many delay cycles
needed for a very precise timing.




2012/6/21 Paolo Di Prodi <robo...@gmail.com>:

[Paolo Di Prodi]

Not if you are in battery mode where the frequency depends on the VCC
thus the led will blink slowly when the battery is getting drained.
:-)