f_open call corrupts memory

[v8dave]

There is a call to f_open within ReadFile (FileSystemUtils.cpp) that is corrupting some memory locations in my code.

The main module calls f_open to load configuration data and this is OK.

I have another task that opens a file (it has f_enterFS(); at the start) and when I step through the code to the f_open call within FileSystemUtils, it corrupts memory after the f_open call. I am using the file FileSystemUtils.cpp from the examples directory with no modifications.

Do I need to do anything to allow file access across tasks? I think I have covered everything. None of the tasks accesses the same datafiles.

Dave...

[rnixon]

Maybe you are overflowing the task stack that is calling f_open?
Exactly what memory is getting corrupted?

[v8dave]

Got it!! tod will love this one!!

I had a char variable declared as 100 bytes but somehow there was an alignment of 16 applied to it. Not sure where it came from but with that removed, it now works. It was causing a stack overflow! Code is rock solid now!!

I think I need to seriously consider C++ more!!

Ah well, is good learning experience finding these things!

Dave...

[rnixon]

I would still make the task stack a lot bigger if you are within a few hundred bytes of an overflow. There could still be overwrites occurring that are not noticed yet. If the task is at the default size (4k I think), I would at least double it. Unless you have a lot of tasks, there's nothing wrong with a larger one.

[v8dave]

USER_TASK_STK_SIZE is declared as 2048 bytes.

I was actually only using 512 bytes for the stack in the task that was causing the issue.! At least I know what to look for next time if the same happens again but know what I know now, this should prevent it happening again.

Dave...

[Ridgeglider]

Dave: When I see weird stuff l like you saw, it's often due to a stack overflow. Take a look at the following functions described in C:\nburn\docs\NetBurnerRuntimeLibrary/uCOSLibrary.pdf

To make them work, uncomment the line

#define UCOS_STACKCHECK (1)
in predef.h and recompile the system files, then enable in main.cpp by:

#include <taskmon.h>
void EnableTaskMonitor();
then use the taskscan app: C:\nburn\pcbin\taskscan.exe
This tool's use is described in C:\nburn\docs\NetBurnerPcTools\NetBurnerTools.pdf.

OR: Within an app use these functions dump task info to stdio:

void OSDumpTCBStacks( void );
void OSDumpTasks( void );

They allow you to watch how much of the alloted task space has been used ever, or at the instant when when called. If you define the tasks by name, the task names will also show up.

[rnixon]

Dave, we're both wrong about the stack size. I looked at it again. I had thought it was 2048 WORDS, which is why I said 4k bytes. But its actually 2048 DWORDs, so its 8k bytes by default. Here is a typical definition:

static DWORD MyTaskStack[USER_TASK_STK_SIZE] __attribute__( ( aligned( 4 ) ) );

[v8dave]

Ah well spotted. I had actually defined this as 512 so it would have only been 2K and the total char data in the 2 functions being called, would have pushed this just over so it made sense to increase and use the the 8K setting. Since doing this, everything has been behaving well and there is no corruption or crashing of tasks now. I have been used to using UCOS on the Rabbit and it's limited memory and not used to embedded systems with MB of RAM )

Cheers,
Dave...

[lgitlitz]

I would make sure that you have a few KBytes of extra space on your stack then what is being used in the task. If an interrupt occurs during the task then the same task stack will be used for storage. This includes about 80 bytes for saving all the processor registers and then any local variables needed by that interrupt routine. You also have to consider the worst case scenario where every interrupt enabled fires during this task in such a way that they are all nested on top of each other. It is much better to have a safe stack size then have a rarely occurring stack overflow in the field. 8K is usually pretty safe unless you are using more then 4 or 5K worth of local variables. 2K is risky, requires detailed analysis of the max space that can be used by the task and all interrupts combined.