I am trying to run and debug the FreeRTOS (v8.2.2) “main_blinky.c” demo for Atmel Studio on my SAM V71 Xplained Ultra Kit. I am using Atmel Studio (6.2.1563 - SP2) to build, download and debug over EDBG port on the board. I followed the instructions at http://www.freertos.org/Atmel_SAMV7_Cortex-M7_RTOS_Demo.html.
When I inspect Local Variables in the debugger the values are always 0xa5a5a5a5. I understand this is the value that the stack/heap is initialized to at startup. The program runs correctly but the current value of local variables do not seem to be displayed correctly in the debugger.
It sounds like the optimisation plays a part in this.
In non-optimised code, every local variable is located on the stack. Its value can be seen during its entire lifetime.
When optimised, most variables will live as shortly as possible, mostly in registers. And as compilers are very clever, it is often hard to follow which register represents which variable.
My projects often need the optimisations, without the -Os option the code wouldn’t even fit into the part.
What you can do is making variables volatile:
void vAssertCalled( const char *pcFileName, uint32_t ulLine )
{
/* Make these variables 'volatile' to ensure
their visibility in the debugger. */
volatile const char *pcAssertedFileName;
volatile int iAssertedErrno;
volatile uint32_t ulAssertedLine;
ulAssertedLine = ulLine;
iAssertedErrno = stdioGET_ERRNO();
pcAssertedFileName = pcFileName;
taskDISABLE_INTERRUPTS();
{
while( ulBlockVariable == 0UL )
{
/* Insert a NOP instruction to be able
to set a breakpoint here. */
__asm volatile( "NOP" );
}
}
taskENABLE_INTERRUPTS();
In the above function vAssertCalled(), the parameters will be invisible to the debugger: as soon as they are not used any more, they stop to exist.
As long as you’re playing with the demo project you might want to disable all compiler optimisations, use -O0 (minus O zero)
Note that bigger variables like structs and arrays are often very well visible in the debugger. The reason is that they’re too big to fit into single registers.
I’ve never seen this behaviour before. If it were an optimisation issue would expect the IDE to simply say it does not recognise the variable, it can’t find it, or that it is out of scope. It could possibly be a corruption of the stack pointer, but then I don’t think the code would run, and I’m not even sure if the debugger uses the stack pointer value itself anyway.
Have you changed the compiler options at all? For example, have you added an option that tells the compiler not to use a frame pointer? Perhaps it is the frame pointer that is not how the debugger expects it to be, rather than the stack pointer.
I double checked my settings and do have the compiler optimisation set to None (-O0). I also tried declaring the variables as volatile but get the same results, See screen shot below:
I checked all the compiler setting. I don’t see anything that would tell the compiler to use or not use a frame/stack pointer. Regardless, I installed a fresh copy of the RTOSDemo, rebuilt, downloaded and still get the same results
It seems to me as if the debugger is not properly accessing the proper memory region when displaying the Locals for the program. If I edit variables in the debugger the new values are displayed but the behavior of the prgram is not modified. For instance, if I change ‘ulValueToSend’ or ‘ulExpectedValue’ so that they are not equal the program still toggles the LED.
