FreeRTOS Support Archive
The FreeRTOS support forum is used to obtain active support directly from Real
Time Engineers Ltd. In return for using our top quality software and services for
free, we request you play fair and do your bit to help others too! Sign up
to receive notifications of new support topics then help where you can.
This is a read only archive of threads posted to the FreeRTOS support forum.
The archive is updated every week, so will not always contain the very latest posts.
Use these archive pages to search previous posts. Use the Live FreeRTOS Forum
link to reply to a post, or start a new support thread.
[FreeRTOS Home] [Live FreeRTOS Forum] [FAQ] [Archive Top] [September 2015 Threads]
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.
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.
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
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.