ERROR: Too much recursion - the stack is about to overflow

Hey,

I've got a new problem.
While the MD5 code I am using worked fine on the original espruino board, it triggers this stack overflow warning when running on the HY32.

Since both boards seem to have the same amount of ram and I have plenty of vars left, I assume that it uses some ram to support the build-in display?

Should I try to lower the number of VARs in a custom build (which I can now do virtuously, as I got that toolchain working on my Mac ;) or is there a fancier way to get rid of that error?

It shouldn't actually use any noticeable amount of RAM for the display, so I'm not quite sure what's happening... Are you building with WiFi support now? That uses RAM.

The best bet is just to drop the var count in HYSTM32_32.py to 1800 and that should fix your problems... Either that or try and reduce the amount of recursion (you could use setTimeout(..,1) with a callback).

Out of interest, what changes have you made to get a working HYSTM32 build? Which compiler are you using?

@Stev
I would also be interested in how you got the toolchain set up on your Mac and how you get the executable onto the board from the Mac.

Not sure if it's actually a working build :)

I am using the GNU ARM Toolchain on OS X 10.9 combined with the make from Xcode and the gdu from MacPorts. It compiles the pure 1.64 without errors and it boots up on the HY32 including the LCD.

However, the board does not come back from reset() like yours does. And once I do a save, the LCD will not boot up and the whole system seems to hang in "loading from flash..."

I also did a custom build where I added USE_NET and changed the CC3000's pins to SPI2 plus B12,B8,B9. I also changed the optimization to -O2 or -Os to make the binary fit into flash. I changed the number of vars to 1843, which solves the recursion problem.

Still, the problem with save() and coming up after save() or reset() remain. So I only run once :)

Learned a lot about the codebase though. Not sure if all the pins in the tables are right, though. There's also one half way empty line for C11 (first column) which stands out. And the mentioned SPI3 thing that does not match the borad description and is mapped onto the same pins as SPI1 anyway.

Cheers
Stev

@mikewop
I added a comment in http://forum.espruino.com/conversations/1195/?offset=25. It's actually quite straight forward now. I can add a more thorough description if this might not be enough, or you can pm me.

I am transferring the executable using a self-hacked tool as the python script did not work for me. Takes ten to fifteen minutes each time though :/ (there still is optimization potential, though)