Stack Corruption - FreeRTOS

girish · ‎2012-01-01

Posted on January 02, 2012 at 05:47

Hello,

We are working on the STM3220-G Evaluation Board.

We are using IAR compiler [V6.2] and running a test application with FreeRTOS [7.0.2] and following is the issue:

1. Used sample application code from ST library - \STM32F2x7_ETH_LwIP_V1.1.0\Project\FreeRTOS

2. Our test application is having just 2 tasks and they are scheduled and execute very well.

There is only FreeRTOS and no LWIP component running

3. However, in one of the tasks, we have some local variables and they are not updated. the same function works quite well if taken outside the RTOS.

4. We have not modified any options/settings and are using the IAR

1. We feel it is stack corruption issue ?

2. Any settings to be done to get the right SP ?. The SP is within range of 0x20000000 to 0x20020000 for both with FreeRTOS and without.

============================================================

Settings from portasm.s

vPortStartFirstTask

/* Use the NVIC offset register to locate the stack. */

ldr r0, =0xE000ED08

ldr r0, [r0]

/* Set the msp back to the start of the stack. */

msr msp, r0

/* Call SVC to start the first task. */

cpsie i

svc 0

=======================================================

/*♯♯&sharpICF♯♯♯ Section handled by ICF editor, don't touch! ****/

/*-Editor annotation file-*/

/* IcfEditorFile=''$TOOLKIT_DIR$\config\ide\IcfEditor\a_v1_0.xml'' */

/*-Specials-*/

define symbol __ICFEDIT_intvec_start__ = 0x08000000;

/*-Memory Regions-*/

define symbol __ICFEDIT_region_ROM_start__ = 0x08000000;

define symbol __ICFEDIT_region_ROM_end__ = 0x080FFFFF;

define symbol __ICFEDIT_region_RAM_start__ = 0x20000000;

define symbol __ICFEDIT_region_RAM_end__ = 0x20020000;

/*-Sizes-*/

define symbol __ICFEDIT_size_cstack__ = 0x400;

define symbol __ICFEDIT_size_heap__ = 0x200;

/**** End of ICF editor section. ♯♯&sharpICF♯♯♯*/

define memory mem with size = 4G;

define region ROM_region = mem:[from __ICFEDIT_region_ROM_start__ to __ICFEDIT_region_ROM_end__];

define region RAM_region = mem:[from __ICFEDIT_region_RAM_start__ to __ICFEDIT_region_RAM_end__];

define block CSTACK with alignment = 8, size = __ICFEDIT_size_cstack__ { };

define block HEAP with alignment = 8, size = __ICFEDIT_size_heap__ { };

initialize by copy { readwrite };

do not initialize { section .noinit };

place at address mem:__ICFEDIT_intvec_start__ { readonly section .intvec };

place in ROM_region { readonly };

place in RAM_region { readwrite,

block CSTACK, block HEAP };

#freertos

amin23 · ‎2012-01-01

Posted on January 02, 2012 at 08:34

Hi,

Try to increase the stack size for this task

girish · ‎2012-01-02

Posted on January 02, 2012 at 10:26

Created sufficient memory for both tasks.

The issue is in TaskB. The structures are created and when we look at their contents, they have some junk values and writing to those values have no effect.

xTaskCreate(TaskA, ''Task1'', 2048, NULL, UART_TASK_PRIO, NULL);

xTaskCreate(TaskB, ''Task2'', 2048, NULL, UART_TASK_PRIO, NULL);

void TaskA(void * pvParameters)

{

/* Simple Task - Toggle LED */

}

void TaskB(void * pvParameters)

{

struct mysockaddr_in localaddr, remoteaddr;

localaddr.length = 20;

localaddr.port = 1235;

/* The problem lies here */

}

nospam · ‎2012-01-02

Posted on January 02, 2012 at 11:35

>1. Used sample application code from ST library -

>\STM32F2x7_ETH_LwIP_V1.1.0\Project\FreeRTOS

I am not familiar with this demo, so cannot comment on the demo, only with FreeRTOS.

>3. However, in one of the tasks, we have some local variables and they are not updated. the

> same function works quite well if taken outside the RTOS.

I presume these are variables local to the function. How do you know they are not being updated? Are they being corrupted, or not written to at all? You can view the assembly lines and the registers in the debugger and single step the assembly lines, to see exactly what is happening. Unless the lines have been optimised away, something must be being updated somewhere.

1. We feel it is stack corruption issue ?

http://www.freertos.org/Stacks-and-stack-overflow-checking.html

http://www.freertos.org/uxTaskGetStackHighWaterMark.html

>2. Any settings to be done to get the right SP ?. The SP is within range of 0x20000000 to

> 0x20020000 for both with FreeRTOS and without.

Why do you think the SP is not right? When you are running a task, the stack pointer should point into the FreeRTOS heap, which will be outside the stack area set up by the linker script. This can result in IAR issuing warnings about the stack pointer being outside of the stack segment when you use the debugger - but it should be - so you can just turn that warning off in the IDE settings.

Nearly all problems on Cortex-M3 devices are due to interrupt priority settings. Make sure to read and understand the RTOS Configuration and Usage details of one of the many STM32 documentation pages on the FreeRTOS site, for example:

http://www.freertos.org/FreeRTOS-for-STM32F4xx-Cortex-M4F-IAR.html

and in particular point 3 on

http://www.freertos.org/FAQHelp.html

On STM32 Cortex-M3 devices in particular it is important to call:

NVIC_PriorityGroupConfig( NVIC_PriorityGroup_4 );

so all the priority bits are preemption priority bits. That makes you life a lot easier, and the ST libraries have this setting different by default.

Regards,

Richard.

(

http://www.FreeRTOS.org

)

amin23 · ‎2012-01-02

Posted on January 02, 2012 at 12:17

Try to use this structure as global variable, the check their contents

girish · ‎2012-01-02

Posted on January 03, 2012 at 05:21

Thanks for the inputs.

We did try this and it works fine.

Also, by defining the variables as static also works fine.

The main reason to worry is we are using ppp stack from LWIP and we do not want to try making changes to that code (workarounds), we are only looking at how things will work the normal way.

At the register level, the code updates the variables fine, but not at variable level.

girish · ‎2012-01-18

Posted on January 18, 2012 at 09:58

Finally the issue got solved !

We used a J-Link Lite and the variables were clearly updated in the IAR debugger window.

I am not sure there is a fix in the ST-Link Driver for this issue.