memset cause buffer overflow on STM32F4 platform with CMSIS2 RTOS for apparently no reason

[afezz.1]

Hi everyone,

during my work i have found a strange situation and i want understand what's going on so here i am to finding help. The situation is this: (we are using CMSIS2 api)

There are several task that made different operation.

When an event is triggered a function is called to write in an SPI memory some values.

Before do this an SPI struct (SPI_DATA_BUFFER_STRUCT) is written to 0 using a memset() call.

This memset() cause a buffer overflow for that specific task (the same function is also called from others task without causing any problem).

So the first thing that come in my mind is "ok let's increase the stack size for that task and see if this solve the problem" and effectively this solution solve it but i'm not happy with this so i go to further investigation.

The strange thing is that analyzing the stack memory there is no reason to have a buffer overflow, infact that struct is always all contained in the stack and always at the same distance from the end of the stack. (of course the bytenum for the memset() does not exceed the maximum stack size )

To add another level of strangeness i have tried to move the SPI struct in the global/static memory and i have notice that if the stack size is less than a certain size the task still give the same buffer overflow error.

This let me thinking that there is something that i miss in all this story, so come to the questions:

How can be possible that the memset() cause this problem even if the struct is all contained in the stack when the memset is called for a number of byte that not exceed the stack size and also when come from another memory area (global and static variable declaration)?

and also why that struct is always at the same distance from the end of the stack still when the size of the stack change?

Please let me know if my explanation is not clear in some point or if you need some others information. Thanks in advance to anyone can help with this or also give me some more information on it.

[Andrew Neil]

"This memset() cause a buffer overflow"

What, exactly, do you mean by that? What buffer is "overflowing", and how do you detect that?

[afezz.1]

the overflow is of the process stack memory. i recognize it cause it go in the HardFaultHandlerCallback() and i look at the stacktrace and come out that is a stack overflow exception

[Andrew Neil]

I don't see how that could be caused by memset?

memset just writes to memory at a specified address - it doesn't extend the stack.

Unless you are right at the limit of stack depth, and it's just that then calling any function - not specifically memset - blows the stack?

[afezz.1]

also suggestion of where to find more information or the handling of exceptions in better way are well accepted

[afezz.1]

thats was exactly was i though in the beginning so i made other tests and come out that i have enough space to allocate another array of the same size 0x120B memset it to 0 without problems but then when i call a memcpy on that SPI struct bad things happen.

this leads me to think that is not a stack overflow, as I thought in the beginning, but an illegal memory access in some way and that i misinterpret the fault interrupt signal.

Now the question become how can i better debug this to get information from status register or backtrace to reach to a solution?

Also have to be noted that the others things i said still remain valid so if you access that struct also from the global/static memory if the task hasn't enough stack size it fail in what the program signaling to me as "stack overflow"

[Andrew Neil]

Lots of resources for debugging Hard Faults mentioned here:

https://community.arm.com/support-forums/f/embedded-forum/3257/debugging-a-cortex-m0-hard-fault