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

[stm322399]

Posted on July 28, 2014 at 16:07

Heap is somewhat misleading when using FreeRTOS. The OS declares a global char table of MAX_HEAP_SIZE and uses this space for dynamic allocation.

The MCU has 192KB of SRAM at 0x20000000, but the application needs some of them for other global variables. The MAP file says that 124KB is allocated, it means 9KB (variables) + 115KB (heap), everything is fine. Normally 180KB as 'FreeRTOS heap' must be OK (180+9=189), but it leaves only 3KB for the initial stack (before the OS starts), which can be less than required (a simple printf call may use more than 4KB of stack), then corruption occurs ....

[Tesla DeLorean]

Posted on July 28, 2014 at 16:55

Heap is somewhat misleading when using FreeRTOS.

Which is why I mentioned the compiler/library implementation, given a rather narrow/selective view of the .MAP file. Would FreeRTOS be able to easily handle TWO memory regions for the HEAP, or would  it make sense to push the STACKs into the CCM?

[stm322399]

Posted on July 28, 2014 at 17:14

AFAIK, there is no configuration for managing two heaps. FreeRTOS provides replacement for malloc/free (choose one of 4 flavors for pvPortMalloc and vPortFree). I suspect that one can still uses malloc/free in addition to integrated heap manager, given that _sbrk uses the space between bss end and stack top.

Allocating thread stack in CCM requires to create thread using a non-official API (xTaskCreate is a macro), otherwise the thread stack is internally allocated using pvPortMalloc. That's what I did in one project: I manually partitioned CCM and forced the stack pointer at a predefined address for every thread creation.

[michaelmichael9137]

Posted on July 29, 2014 at 11:29

Ok thanks for your answers. 

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

Clive, how did you figure that out with the small snippet I gave? I don't see it. Pushing the stack into the CCM seems a bit out of reach for my skills, I will investigate though.It seems that my only solution is to figure out how much space the initial stack is needing. I don't think it can be done without a trial and error method. Would you like to see the complete .MAP?Thanks

[Tesla DeLorean]

Posted on July 29, 2014 at 19:04

Clive, how did you figure that out with the small snippet I gave? I don't see it. 

.heap        0x2001f2f0        0x0 Section, Basis, Length RAM usage up to this point as allocated by the linker equates to 124KB. 0x20020000 would be 128KB