In programming many good things has been invented out of laziness or if something is annoying enough. I was fed up with getting stack overflow situations out of the blue, and decided to make a stack checking function for the run time. In MicroPython, I statically allocate as much ram as possible for the MP heap memory, taking into account that the stack needs ram too. In MP implementation the C language function call chains can be over 20 levels deep, so it needs quite much ram for stack (in each function call many of the 32-bit registers are pushed to stack first, and also e.g. local variables need stack).
The problem is that there is no control in Pokitto (or in many other MCU devices) for the stack usage. If the stack gets too big it just overwrites statically allocated data (BSS) or heap. The stack in Pokitto starts in a high memory location and the pointer decreases when more data is pushed to the stack. The static data and heap is allocated from low addresses upwards. When these collide, ram is overwritten and anything can happen(!).
Many times, after updating PokittoLib in my env, have been literally wasting hours for searching various problems in Python when the reason was actually a stack overflow (!).
To fix this I am now frequently checking the stack overflow in MP code. It is done by quickly comparing the stack pointer address to the end of the BSS chunk. That do not yet take dynamic heap allocation into account as it is rarely used in code. When the stack pointer is decreasing near to the BSS chunk end, I am showing the Pokitto Crash Screen as follows. So the problem is immediately visible on HW.
The cryptic hex sequence (Guru Meditation number ) is the size of the stack (“7ec”) and the address of the stack pointer (“10007814”). Pokitto Crash Screen can be re-used for other messages and data also. I am using C64UIGfx font to “print” Pokitto image and the frame on screen.