Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Real time embedded FreeRTOS mailing list 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem TCP & FAT Training




Loading

vTaskDelay() -> Hard fault. Because struct initialized with {0}

Posted by qyw on September 6, 2015

I've met the problem with my task which does nothing but blink led. Program falls into HardFault while executing vTaskDelay. I found out fault spawned when struct FIL (from FatFS by Chan) initialized with {0}. Seems here is memory corruption.
Can you explain why? And why FreeRTOS doesn't call any configAssert? But Tracealizer says: Warning: Recoder reported error: "TRACE_ASSERT: vTraceStoreTaskswitch: invalid value for task handle"

static void empty_task( void* pvParams )
{
    FRESULT ferr = FR_OK;
    DIR dir;
    FILINFO fno = {0};   // No problem with it, but I am not sure it will not apper in feature or on other system/compilier
    //FIL fil = {0};    // Uncomment to achive my problem

    while(true){
        bsp_LedToggle(LED_White);  // will pass once. Next time met PC at HardFault_IRQHandler()
        vTaskDelay(333);
    }
}

Compilier MDK-ARM v5.05 u2 b169. uC STM32F407.


vTaskDelay() -> Hard fault. Because struct initialized with {0}

Posted by rtel on September 6, 2015

I will try and explain, but first need to understand your post better.

Are you saying something in Chan's FatFS is corrupting something in FreeRTOS? If so it must be corrupting something used in vTaskDelay(), but you don't say what. Where inside vTaskDelay() does the hard fault occur?

Regards.


vTaskDelay() -> Hard fault. Because struct initialized with {0}

Posted by qyw on September 6, 2015

Looking at FIL struct code

/* File object structure (FIL) */
typedef struct {
    FATFS*	fs;				/* Pointer to the related file system object (**do not change order**) */
    WORD	id;				/* Owner file system mount ID (**do not change order**) */
    BYTE	flag;			/* Status flags */
    BYTE	err;			/* Abort flag (error code) */
    DWORD	fptr;			/* File read/write pointer (Zeroed on file open) */
    DWORD	fsize;			/* File size */
    DWORD	sclust;			/* File start cluster (0:no cluster chain, always 0 when fsize is 0) */
    DWORD	clust;			/* Current cluster of fpter (not valid when fprt is 0) */
    DWORD	dsect;			/* Sector number appearing in buf[] (0:invalid) */
#if !_FS_READONLY
    DWORD	dir_sect;		/* Sector number containing the directory entry */
    BYTE*	dir_ptr;		/* Pointer to the directory entry in the win[] */
#endif
#if _USE_FASTSEEK
    DWORD*	cltbl;			/* Pointer to the cluster link map table (Nulled on file open) */
#endif
#if _FS_LOCK
    UINT	lockid;			/* File lock ID origin from 1 (index of file semaphore table Files[]) */
#endif
#if !_FS_TINY
    BYTE	buf[_MAX_SS];	/* File private data read/write window */
#endif
} FIL;

I understood what is my problem. STACK OVERFLOW. FIL.buf is very big. The size of stack was 2KB and it worked fine with or without any initialization. Then I changed _MAX_SS to 4KB. And app still worked fine without initialization to {0}, because FATFS did not use full 4KB of buff, but only 512b (it depends on drive type). Finally I added initialization of FIL and "hit my had agains a wall" again, and again, and again... This story lasts about two weeks, I did not associate changes together. It was complicated story.

Assuming

1 Don't declare large variables on the stack. Use malloc, static, or declare as public (out of function). 2 A long time ago my FreeRTOS became FreeRTOS+Trace. And hook function looked like

// === FreeRTOS_hooks.c ===
void vApplicationStackOverflowHook( TaskHandle_t *pxTask, signed char *pcTaskName )
{
    (void)pxTask; (void)pcTaskName;
    vTraceConsoleMessage("\n\rStack overflow!\n\r");
}

// === trcHardwarePort.h ===
#define vTraceConsoleMessage  // do nothing, do not compile

That was my mistake. Hook was rewritten

#if configCHECK_FOR_STACK_OVERFLOW  
void vApplicationStackOverflowHook( TaskHandle_t *pxTask, signed char *pcTaskName )  
{  
    debugf("!!! STACK OVERFLOW in task %s, handler 0x%08x\n", pcTaskName, (unsigned)pxTask);
    configASSERT( 0 );
}
#endif
#define vTraceConsoleMessage(x)  debugf(x)

And now we will receive the message, and never fall to HW fault. Note configASSERT must be defined properly, debugf is synonim to printf.

Links

Stacks and stack overflow checking


[ Back to the top ]    [ About FreeRTOS ]    [ Sitemap ]    [ ]




Copyright (C) 2004-2010 Richard Barry. Copyright (C) 2010-2016 Real Time Engineers Ltd.
Any and all data, files, source code, html content and documentation included in the FreeRTOSTM distribution or available on this site are the exclusive property of Real Time Engineers Ltd.. See the files license.txt (included in the distribution) and this copyright notice for more information. FreeRTOSTM and FreeRTOS.orgTM are trade marks of Real Time Engineers Ltd.

Latest News:

FreeRTOS V9.0.0 is now available for download.


Free TCP/IP and file system demos for the RTOS


Sponsored Links

⇓ Now With No Code Size Limit! ⇓
⇑ Free Download Without Registering ⇑


FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Renesas Electronics Gold Alliance RTOS Partner.jpg

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

Atmel RTOS partner supporting ARM Cortex-M3 and AVR32 microcontrollers

STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Xilinx Microblaze and Zynq partner

Silicon Labs low power RTOS partner

Altera RTOS partner for Nios II and Cortex-A9 SoC

Freescale Alliance RTOS Member supporting ARM and ColdFire microcontrollers

Infineon ARM Cortex-M microcontrollers

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

Cypress RTOS partner supporting ARM Cortex-M3

Fujitsu RTOS partner supporting ARM Cortex-M3 and FM3

Microsemi (previously Actel) RTOS partner supporting ARM Cortex-M3

Atollic Partner

IAR Partner

Keil ARM Partner

Embedded Artists