Stopped working after switching configuration from Debug to Release.

Jonathan,

You are going to need to give us some more details. What version of CCS and TI-RTOS (sys/bios) are you using? What device? Does it make it to main()? What happens when you run it. I expect there is a bad pointer or data corruption going on in your application and the code placement is different between the profiles.

Todd

Hi Todd,

I am using CCS V6.1.2 and TI-RTOS for TivaC version 2.14.0.10 according to RTSC. I am using the TM4C123 on a custom board with the LaunchPad as my JTAG debugger interface.

I set a breakpoint at the beginning of main() and the code does stop there. There aren't any crash messages. But the code does not perform what it should be doing, judging from the LEDs (GPIOs). 

Upon further investigation, it appears that the code is stuck in this while loop waiting for the tick to go up. the clock_tick_ISR is a RTOS Clock instance.

void clock_tick_ISR (void)

{

//GPIO_write(Board_TP3, Board_LED_ON);
tick_count++;
//GPIO_write(Board_TP3, Board_LED_OFF);

}

// delay in 100mS

void rtos_delay (int delay_time)
{

tick_count = 0;

while ( tick_count < delay_time )    <<---- Code is stuck here.
{

}

}

Regards,

Jonathan

Can you show how you created the Clock instance? Also, can you attach a snapshot of Tools->ROV->Clock->Module. I want to make sure the Clock module is set up correctly. You should be seeing the "ticks" value in this window increase as you let it run.

It's also handy to do a ROV->BIOS->Scan for Errors to make sure you don't have a blown a stack or had some other issue.

Note: the rtos_delay is pretty brutal. Do you really want to spin for that long? This could starve out lower priority things. Who (and why) is calling this function?

Todd

Is tick_count declared as volatile?

Hi Todd,

I created the clock instance using the GUI. Can you tell me how to send a screen shot to this response? I tried pasting the screen shot here, but it won't take.

The clock instance is just ANY timer, 1000uS base tick, in the instance, 100 ticks period and stat at boot time, 10 ticks initial timeout.

I checked Tools->ROV->Clock->Module, it says "target running." I had to stop the target to see the tick numbers. then run it again and stop it again. The tick number appears to be increasing.

I also tried ROV->BIOS->Scan. No error was found.

I had the Idle thread call the rtos_delay(). I was told that this method is non-blocking and higher priority tasks can run. True?

Thanks.

Jonathan

tick_count is a global variable in my program.

But is the variable declared with the volatile storage specifier? eg.
volatile int tick_count;
Release settings may increase the optimization that might remove the variable. The compiler assumes it never changes within the function scope. It will assume that tick_count is set to 0 and never changes.

Wow, right, on Norman. First, I used the volatile specifier on the tick_count variable and it solved the tick problem. Good catch. However, my code still did not do its real work (process external interrupt, exchange data over the SPI interface, etc.)

So, next, I turned off the compiler optimization (was level 2 before). Now my code works normally.

So the compiler optimization was doing something my code does not like. I wish I could understand what the optimization did so I can change my code to work with optimization.

Is it common for real time firmware to run in release mode without optimization?

Johatham

It's well known irony that we debug a version we do not release and release a version that we cannot debug. No idea if there any reason to use release mode without optimization. With PC programs, release would mean there is no symbol info, reducing the file size. Not sure if that applies with embedded images.

No expert on compiler optimization. See the techinical documents to see what each of optimization features. A couple of things to look for. Optimization will do a whole bunch of stuff like remove supposely unused (volatile) variables. It will also rearrange code such that stepping though code will not work. The rearranged code will be faster. If your code is heavily dependent on timing, things will happen in a different order...breaking things. Suggest you crank up the diagnostic warning to maximum. Might give you some hints.

I think there is probably a bug in your code that the optimizer is exposing. It would be good to track it down because it will eventually come back to haunt you. I agree with Norman to crank up the compiler warnings to the max and make sure you have them all resolved.

Todd

How do I crank up the compiler warnings?