Does anybody know where the stack is supposed to reside? When I print the current stack pointer it always points to an area well outside the 80k dram0 area (in the 16k area above it). Is this also ram? Or some mmu trick (aliasing)?
Can you provide the code used to print the sp, and also the .map file generated by the linker?
The code to print the SP is very simple. Just take the address of a random function parameter or a local variable. It appears that the first six function parameters are passed using registers, so to be sure, you need to declare more than six local (auto) variables. Normally you can’t take the address of a register variable, and the compiler would take care that a variable that the address is taken from, is not allocated in a register, but hey, you never know. Some architectures feature memory address aliases of the basic cpu registers.
The load map is irrelevant. The stack pointer is setup by the boot loader and/or the SDK setup code. The linker has no involvement in the address of the stack pointer.
As the both boot loader and SDK init code are closed source, we cannot find this out ourselves, but maybe somebody knows from information by Espressif…
Usually the stack is statically allocated, unless you are using an os that can dynamically create tasks. What address are you getting? In which portion of the memory map does it fall? This should be the memory map https://github.com/esp8266/esp8266-wiki/wiki/Memory-Map
Usually you can find the stack range(s) in the memory map, for the same reason.
I know this page. Where do you find the location of the stack pointer there? Like I said, the stack pointer will be somewhere outside any region declared there. For me it’s now at 0x3ffffef8, but it can vary of course. According to any known information, including the post you refer to, physical ram ends at 0x3fffc000. Do you see the problem?
Also if you start googling for stack pointer values (mostly mentioned in relation to stack dumps from exceptions), you’ll they’re in the same range. It’s not something unique to my environment.
It seams this baby has a memory management unit.
That’s an ESP32. Not an ESP8266.
Anyway the ESP32 is just two ESP8266’s + a bit of extra I/O on one die.
Yes, they have a MMU. Well, sort of. It’s very basic. It’s only there to fetch and cache pages from SPI FLASH into RAM that are required at any moment. That’s all it does. It’s not a MMU like you know of microprocessors that do logical to physical address translation and protecting memory between user processes.
Okay, I’m not so familiar with Tensilica as you are apparently. I can imagine that the system stack defaults to the “ETS system ram”, which is probably only described in Chinese manuals. If you print the stack pointer from the context of an own-created task, I would imagine it will end up in the 80k of application ram.
But it doesn’t. So there is the $1m question why and how much stack can we use?
I have found out a few things. It seems the stack area is ~5 kb. See http://www.esp8266.com/viewtopic.php?p=73084#p73084 for details and how I came there.
Nice work. It seems to be a single stack OS that is running, so not fully preemptive.
We already knew that, that is no secret 
For me counts: the lesser OS layer the better, a microcontroller should be programmed on the registers not on some shady layer in-between.