Erasing FreeRTOS stack on STM32F4 with gcc

I am trying to run FreeRTOS on my stm32f4discovery board. I 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 the project in the CORTEX_M4F_STM32F407ZG-SK folder of the FreeRTOS demo projects (deleting existing tasks and creating my own). Here's 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 configured configMINIMAL_STACK_SIZE to be 4096 in FreeRTOSConfig.h and this code works well when Task Scheduler starts and SampleTask0 function is called. 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);
}

      

        
        
        
      

    

Task 1 is almost the same as Task 0, except that it prints different information. This code compiles and after I write the binary to my board, SampleTask0 doesn't work as expected. The DebugPrintf function, which sends a character through USART3, prints only "Tas" and then everything stops. I traced the code with gdb and stepped through, "Task 0 running" was printed, but when it returned to the task function (before "while (delay) {delay-- ;;") an error occurred:

Unable to access memory at address 0xa5a5a5a5

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

According to the FreeRTOS docs , each task's stack is filled with 0xa5 bytes upon creation. I think there might be something wrong with the glass. I set configCHECK_FOR_STACK_OVERFLOW to 2 to enable detection, but my hook function was not called when it did.

In CORTEX_M4F_STM32F407ZG-SK, a startup_stm32f4xx.s file was created for the EWARM toolchain and I replaced it with the boot file in STM32F4-Discovery_FW_V1.1.0 that I downloaded from the ST website. So it can damage the stack, but I'm not sure about that. Anyone have any ideas about this?