Wrong values in debugger

[michaelmichael9137]

Posted on July 21, 2014 at 13:34

Hi everyone,

I'm using CooCox with a STM32F4. I have a big issue with the Coocox debugger:

static STEP_MODE val_step_mode = FALSE;

1  if ((Get_Core_Current_Track()->step_mode)  !=  val_step_mode)

2  {

3         val_step_mode = Get_Core_Current_Track()->step_mode;

4         return BS_SUB_MODE;

5  }

The first line compares a value in the core of my program with a static value 'val_step_mode'. if the two values are different, I then put the core value in the static one, waiting for the next test. 

When I press a button on my board, the first condition is valid and the execution enters the 'if' condition. I know then for sure that 'val_step_mode' is different of the core value. At this point, the 'expression' log indicates 0 for val_step_mode. Now when I execute one step further, the core value is transfered to val_step_mode, but the value is still 0. That case is of course impossible.

The thing is the code seems to work fine, as the other functions are behaving like they could see the right values.

I have many similar cases in my code and the values displayed by the 'expression' tab are always wrong. I know it's the debugger problem because the other functions in the code seems to receive the right values and are responding correctly. I'm really stuck here, any ideas? Did you ever experienced this kind of problem?

Thanks in advance.

#!bug #freertos-variables-statics-debug #debug

[Tesla DeLorean]

Posted on July 21, 2014 at 15:02

Try turning off optimization. It tends to re-order code, and promote memory variables to registers.

If a variable is changed outside of normal code flow you should mark them as volatile.

[michaelmichael9137]

Posted on July 21, 2014 at 15:18

Thanks Clive,

My optimization settings were already set to None (-O0). I will consider the volatile prefix though. I tried to extend the memory allowed to the task running this function, but it changed nothing. When I try to set a non-static local variable with my core value, I can read it's true value without any problem. The problem seems to occur only with my statics.

[michaelmichael9137]

Posted on July 22, 2014 at 12:36My debugger stills behave strangely. It sometimes breaks at random location in the code. Don't know if these problems are related to previous issues but these 'ghost breakpoints' are really annoying. What could I check?

[michaelmichael9137]

Posted on July 25, 2014 at 18:34

Hi everyone,

I got further in my investigations. The problem seems to occur when I set 'configTOTAL_HEAP_SIZE' of FreeRTOS at it's max value (180*1024 in my case). When I set this value to 115*1024, everything's working fine, and I'm able to monitor my statics variables correctly. Does the source of my issue could be that the debugger is needing a certain amount of space in RAM to run correctly? Is it possible that the compiler does not consider this space when it determines the free remaining space available for FreeRTOS? In this case, I think it could lead to the corruption of my monitored datas.Thanks again,

[jpeacock2399]

Posted on July 25, 2014 at 20:10

Check the memory map produced by the linker.  Sounds like you are exceeding an SRAM memory boundary with a 180KB heap size.  Which F4 are you using?  An F40x has 64K CCM and 112KB SRAM in two sections.  The 'F42x adds another 64KB SRAM, so the 180KB would work if you base the heap at 0x20000000 AND you have all three SRAM banks.  If will fail if you only have two banks of SRAM.

The other possibility is the SRAM has other memory sections mapped to it, and your heap is overlapping another area.  The problems would fit your description.   Jack Peacock

[michaelmichael9137]

Posted on July 28, 2014 at 11:10

Hi Jack,

We are using a 427VG, so we do have 3 SRAM blocks. I set the start at : 0x20000000 and the size to : 0x0002FFFF. With these settings I should use the total SRAM size. I assumed that the blocks were contiguous and that I could declare them like they were one big block of data. The total size of RAM is 16+64+112KB, 192KB. How could I overflow with 180KB of declared Heap size? Is there a simple method to obtain a complete mapping of the RAM, including the space that FreeRTOS is using?Thank you very much.

[Tesla DeLorean]

Posted on July 28, 2014 at 13:24

The .MAP should show what the linker is doing.

Pay particular attention to where you're placing the stack.

[michaelmichael9137]

Posted on July 28, 2014 at 14:03

I don't think I can define the stack space myself. I think FreeRTOS does that. This is what I can read in the .MAP about stack and heap : 

.heap        0x2001f2f0        0x0                0x2001f2f0                  __end__ = .                0x2001f2f0                  _end = __end__                0x2001f2f0                  end = __end__ *(.heap*)                0x2001f2f0                  __HeapLimit = ..co_stack       0x2001f2f0      0x800    load address 0x0805a998                      0x2001f2f0                    . = ALIGN (0x8) *(.co_stack .co_stack.*) .co_stack      0x2001f2f0      0x800    ..\obj\startup_stm32f4xx.o                      0x2001f2f0                    pulStack                      0x2002ffff                     __StackTop = (ORIGIN (ram) + 0x2ffff)                      0x2002f7ff                     __StackLimit = (__StackTop - SIZEOF (.co_stack))                      0x2002ffff                    PROVIDE (__stack, __StackTop)                      0x00000001                 ASSERT ((__StackLimit >= __HeapLimit), region ram  overflowed with stack)

[Tesla DeLorean]

Posted on July 28, 2014 at 15:50

So there is 124 KB of RAM consumed, with 0 associated with the compiler/library based heap.

You'll have to review prior entries in the .MAP file to see where that other 124 KB is getting eaten.