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.

TM4C123GH6PM: while condition does not work

Part Number: TM4C123GH6PM

Hi

I am debugging this code, and when I get to the yellow line at first the counter is less than end, but even after counter > end it still stays in the while. I tried to add the if statement in the while, but it seems the compiler ignores it ane way, I cant add a breakpoint on this line.

it is very strange. what can be the problem?

I run it on the launchpad with the same results

void
o_timersQ_delay2(DWORD delay)  //in mSec
{
	DWORD end, start = systick_counter;
	
	end = systick_counter + (delay /SYSTICK_PER); //find what the counter should be at the end of the delay
	
	if (end > start)
	{
		while (systick_counter < end)  //in regular case	// from some reason it doesnt work
		{
			if (systick_counter > end) break;
		} 
	}
	else	//when the end is after overflow
	{
		if (systick_counter >= start) //until the overflow
			while (systick_counter > end); 
		else //after the ofer flow
			while (systick_counter < end); 	
	}
}

  • Sorry, I do not recognize that code. Where is "systick_counter" defined and where is it incremented? "systick_counter" must be declared volatile if it is updated in an interrupt routine.
  • As Bob mentioned, make sure your variable is volatile if its value is changed in a different part of your code.

    And, for a more realistic debug experience, turn off ALL optimizations - then you will be able to add the breakpoint where you want.

    Bruno
  • Bruno Saraiva said:
    And, for a more realistic debug experience, turn off ALL optimizations

    Sorry Bruno, that's a less realistic debug experience, not more. You should debug with the same optimizations you release at.

    If you have trouble setting a breakpoint on a specific line of C drop to assembly and break there.

    Side note: This is one case in which it is reasonably likely that optimization would result in different code. Although that is compiler dependent.

    Robert

  • Hello Robert,

    That's true, correction accepted! Instead of "more realistic", perhaps I should have said "more linear"...

    To avoid confusion for further readers: debugging with all optimizations OFF will be more convenient when evaluating the programming logic.

    One other thing you commented elsewhere and I totally agree, is to avoid using two different project settings (which unfortunately is the case for many TI examples): one for DEBUG and one for RELEASE.

    As for "optimization resulting in different code", I see that happening A LOT. One recent function I created was used to transpose bytes, which basically had two nested for loops. The program cycle count with and without optimization changed 4 times to what was "visually a very linear and small piece of code"!

    Regards

    Bruno
  • Bruno Saraiva said:
    To avoid confusion for further readers: debugging with all optimizations OFF will be more convenient when evaluating the programming logic.

    Except for the cases where it simply confuses the matter. The original code in this thread has a reasonably high probably of behaving differently at different optimization levels. And all behaviours would be correct. I don't believe it makes sense to turn off optimization for convenience during debugging. That leads to thinking that the code fails because of optimization bugs when it's just your understanding of the code that's at fault. The trouble is that this kind of condition is reasonably common and not always recognized particularly by beginners.

    So beginners should never do it and by the time they become expert enough to recognize the conditions they won't need to do it and also realize they will not always recognize the conditions.

    Bruno Saraiva said:
    One recent function I created was used to transpose bytes, which basically had two nested for loops. The program cycle count with and without optimization changed 4 times to what was "visually a very linear and small piece of code"!

    Dramatic changes are more likely in small pieces of code. But if you think about it "optimization results in different code" is a tautology. Of course it does, that's what it's supposed to do.

    Robert