- Fri Jan 12, 2018 4:44 am
I've done some experimentation and I'd like to share what I found, maybe someone can comment.
To start with, during the very early boot process, some functions in user code can be called from the SDK code:
During this period the stack pointer points to an area half way through the memory area designated as user ram area (dram0). Weird.
When the SDK code is done initialising, user_init() is called. After that, optionally a function user_init2() can be called from SDK code (after which all wlan initialisation has finished). In both functions the stack pointer is on the top of the memory area designated as "system ram" (as mentioned before) and remains there. So apparently "non-OS SDK" user code has it's stack there.
Now is the question, how big is the usable stack area? It could be anything between 16kbytes (where the sysram area starts and the dram0 area ends, writing beyond there will corrupt the heap) and 384 bytes (the max stack space I am using now and which doesn't seem to be a problem).
So I started "painting" the sysram area with a magic number (4 bytes) and watched the area. Conclusions from that:
- If you write anything in the area between the sysram start (3fffc000) and halfway through (3fffe000) the system will crash. Especially if started from the top of this area (3fffe000) downwards, so I suspect that's where the stack is that's used for system functions (interrupts, some sort of CPU supervisor mode, background SDK code?)
- Writing in the area between 3fffe000 and 3fffeb2c is "harmless", everything will keep working, but there is a huge caveat, somewhere in the process between user_init2 and regular execution of the user code, the last part (top area, a few bytes below 3fffeb2c) gets overwritten by the SDK code, with zero's. So you can't use it as stack area.
- The area between 3fffeb2c and 3fffffff is "clear".
- The area between 3fffeb30 and 3fffffff is the designated area for the user stack and is 5328 bytes in size (not too bad anyway)
- The area between 3fffe000 and 3fffeb2c could maybe be used for some storage, but take care that a small part of it gets overwritten during the startup. When all is up and running, the SDK doesn't write there. So it's not suitable for use as stack, but it might be used for extra storage, outside the heap, of size of about 2.5 kbytes, when memory is really tight.
- The area between 3fffe000 and 3fffc000 is used for system/SDK usage, don't touch it.
To be able to keep monitoring this and just for info, I implemented "stack painting" where at system start I write the complete stack area with signature long words. Everywhere the stack has been, the signature will be overwritten, so the effectively needed stack size can be determined. From the other side of the area, everywhere the SDK has been written, the signature will be lost as well, so this can be monitored. As for the moment, I haven't seen that happening, luckily.