[SOLVED] FreeRTOS stack corruption on STM32F4 with gcc

FreeRTOS stack corruption on STM32F4 with gcc

I'm trying to get FreeRTOS running on my stm32f4discovery board. I have installed summon-arm-toolchain and created a Makefile to compile my code. Here is the Makefile:

TOOLCHAIN_PATH:=/usr/local/sat/bin
TOOLCHAIN_PREFIX:=arm-none-eabi
OPTLVL:=0
FREERTOS:=..
STARTUP:=$(CURDIR)/startup
LINKER_SCRIPT:=$(FREERTOS)/Utilities/stm32_flash.ld
INCLUDE=-I$(CURDIR)
# Setting other include path...
BUILD_DIR = $(CURDIR)/build
BIN_DIR = $(CURDIR)/binary
vpath %.c  $(CURDIR)
# Setting other vpath...
vpath %.s $(STARTUP)
ASRC=startup_stm32f4xx.s
# Project Source Files
SRC+=stm32f4xx_it.c
SRC+=system_stm32f4xx.c
SRC+=main.c
# FreeRTOS Source Files
SRC+=port.c
SRC+=list.c
SRC+=queue.c
SRC+=tasks.c
SRC+=timers.c
SRC+=heap_2.c
SRC+=syscalls.c
SRC+=stm32f4xx_usart.c
# Other peripheral source files...
CDEFS=-DUSE_STDPERIPH_DRIVER
CDEFS+=-DSTM32F4XX
CDEFS+=-DHSE_VALUE=8000000
MCUFLAGS=-mcpu=cortex-m4 -mthumb -mfpu=fpv4-sp-d16 -mfloat-abi=softfp
COMMONFLAGS=-O$(OPTLVL) -g -Wall
CFLAGS=$(COMMONFLAGS) $(MCUFLAGS) $(INCLUDE) $(CDEFS)
LDLIBS=
LDFLAGS=$(COMMONFLAGS) -fno-exceptions -ffunction-sections -fdata-sections -nostartfiles -Wl,--gc-sections,-T$(LINKER_SCRIPT)
OBJ = $(SRC:%.c=$(BUILD_DIR)/%.o)
CC=$(TOOLCHAIN_PATH)/$(TOOLCHAIN_PREFIX)-gcc
LD=$(TOOLCHAIN_PATH)/$(TOOLCHAIN_PREFIX)-gcc
OBJCOPY=$(TOOLCHAIN_PATH)/$(TOOLCHAIN_PREFIX)-objcopy
AS=$(TOOLCHAIN_PATH)/$(TOOLCHAIN_PREFIX)-as
AR=$(TOOLCHAIN_PATH)/$(TOOLCHAIN_PREFIX)-ar
GDB=$(TOOLCHAIN_PATH)/$(TOOLCHAIN_PREFIX)-gdb

$(BUILD_DIR)/%.o: %.c
    $(CC) $(CFLAGS) $< -c -o $@

all: $(OBJ)
    $(AS) -o $(ASRC:%.s=$(BUILD_DIR)/%.o) $(STARTUP)/$(ASRC)
    $(CC) -o $(BIN_DIR)/$(TARGET).elf $(LDFLAGS) $(OBJ) $(ASRC:%.s=$(BUILD_DIR)/%.o) $(LDLIBS)
    $(OBJCOPY) -O ihex $(BIN_DIR)/$(TARGET).elf $(BIN_DIR)/$(TARGET).hex
    $(OBJCOPY) -O binary $(BIN_DIR)/$(TARGET).elf $(BIN_DIR)/$(TARGET).bin

I modified project in folder CORTEX_M4F_STM32F407ZG-SK of FreeRTOS Demo projects(removing the existing tasks and creating my own). Here is the main function:

int main(void) {
    int ret;
    prvSetupHardware();
    DebugPrintf("FreeRTOS v7.3.0 starting\n");
    ret = xTaskCreate(SampleTask0, (signed char *) "T0", configMINIMAL_STACK_SIZE, NULL, 2, NULL);
    if (ret == pdTRUE) {
        DebugPrintf("Task %x creared successfully:%d.\n", SampleTask0, ret);
    } else {
        DebugPrintf("Task 0 created failed.\n");
    }
    ret = xTaskCreate(SampleTask1, (signed char *) "T1", configMINIMAL_STACK_SIZE, NULL, 1, NULL);
    if (ret == pdTRUE) {
        DebugPrintf("Task %x creared successfully:%d.\n", SampleTask1, ret);
    } else {
        DebugPrintf("Task 1 created failed.\n");
    }
    DebugPrintf("Starting scheduler...\n");
    vTaskStartScheduler();
    for (;;);
}

I have configured configMINIMAL_STACK_SIZE as 4096 in FreeRTOSConfig.h and the code goes well as Task Scheduler started and invoked my SampleTask0 function. Here is the task code:

void SampleTask0(void *pvParameters) {
    (void) pvParameters;
    uint16_t delay;
    for (;;) {
        delay = 10000;
        DebugPrintf("Task 0 running\n");
        while(delay) {delay--;}
    }
    vTaskDelete(NULL);
}

The Task 1 function is almost the same as Task 0 except it prints different information. These code compile and after I write the binary to my board, the SampleTask0 does not work as expected. The DebugPrintf function which sends character through USART3 only prints "Tas" and then everything halts. I traced the code with gdb and execute the code by step, "Task 0 running" got printed but when it returned to task function(before "while(delay) {delay--;}") an error occurred:

Cannot access memory at address 0xa5a5a5a5

SampleTask0 (pvParameters=0x0) at main.c...

According to FreeRTOS documents, the stack of each task is filled with 0xa5 bytes upon creation. I think there may be something wrong with stack. I have set configCHECK_FOR_STACK_OVERFLOW to 2 to enable stack overflow detection, but my hook function had not been invoked when this happened.

The startup_stm32f4xx.s in CORTEX_M4F_STM32F407ZG-SK was created for EWARM toolchain and I replaced it with the startup file in STM32F4-Discovery_FW_V1.1.0 which I downloaded from ST website. So it could potentially corrupt the stack, but I'm not sure about this. Anyone have ideas about this?

Solution