Is there a way to set the stack size (photon) and/or a way to determine if I am running out of stack space? Calling System.freeMemory() only shows me how much total mem I am using, not specifically stack space (right?)
1 Like
Did you ever figure this out? Have the same issue.
@larse, there is no way to set the stack size except for new FreeRTOS threads. Calling System.freeMemory() show he available space on the Heap but does not indicate how fragmented it is. Often, memory issues are due to using functions that dynamically allocate and release memory on the Heap, creating fragmentation. This includes some Standard Library functions (eg. <vector>) and more commonly the Arduino String commands. The solution to the latter is to use c-string (char arrays) functions.
If you can describe problem more specifically, we may be able to help more.
If you have issues with the stack size that’s usually not a problem with the size of the stack but an indication that you may have some systematic problems with your code/style.
e.g. excessive function call depths (i.e. recursions) and/or use of too massive automatic variables and parameter lists, just to name a few.
Without addressing these issues first, your stack may be much bigger and your code would still eat it up, it just takes longer.
1 Like
I don’t have recursion. My code is very complex (a QUIC stack) and so there are large stack allocations, etc. I’d hence like to monitor stack growth, to get an indication of what to optimize first.
FWIW, if I double APPLICATION_STACK_SIZE (for a monolithic build) things work fine.
@larse, you could also use static buffer allocations instead of using the stack where possible. QUIC wasn’t necessarily designed with small embedded platforms in mind. With limited RAM, increased stack means less heap and vice-versa. This is the fine balance that Particle tries to strike with their 6KB stack size. I highly doubt Particle will make the stack size user-definable outside of using a modified firmware version in order to ensure stability and reliability for the large number of typical users.
2 Likes
As @peekay123 already mentioned, setting the stack size is not possible. I found that one can very quickly run out of stack on this platform - best way to resolve it is with static buffers (globals if you will) as already mentioned above also.
I did find this process a bit hit and miss. I.e., the big offenders are generally quickly identified but its a heap of small allocations that together put a significant crimp on the stack I had problems with. I could never get much of an accurate picture of the stack size - perhaps there are some OS function calls you could make, don’t know. I also found that particle OS 0.7 and up use so much more RAM (and possibly give your app less stack?) that my app just could not survive and I stayed with 0.6.3
My packet buffers and metadata are preallocated on the heap. The stack growth is probably due to regular protocol operation, but it’s hard to pinpoint where the stack might grow unreasonably - which is why I’d like to instrument that.
Nope, the stack size is "constant" at 6KB but when more RAM is used by the device OS the sum of available space for global variables and dynamic heap space will be reduced.
I don't know of any API or the actual STM32F function call to retrieve the current position of the stack pointer, but a general approach could be to write a simple function that just puts one dummy variable on the stack and then retrieve its position in RAM.
If you call that function in STARTUP(), you should get a good idea about the base line for your stack and should be able to calculate the distance.
This way you'd also not need to care whether you should look at the MSP (main stack pointer) or the PSP (process stack pointer).
@ScruffR thanks for that tip, this let me add enough instrumentation to find where I was exploding the stack