teamclouds / vtc-vaporware Goto Github PK

While in volt mode, holding increase or decrease button cause device to freeze. Screen stays on, but buttons are unresponsive. Battery pull is the only way to get it back.

As @s0be knows, I've been busy testing vtc-VaporWare on the threaded SDK. In particular, I had very nasty, random bus faults in some menus that I couldn't trace back to anything, so I feared a dispatcher bug. The dispatcher's fine, there's a much simpler explanation...

The SDK reserves 1kB for the application stack. vtc-VaporWare uses more than 1kB in some cases. How the heck is is possible it never crashed before, and crashes on threaded?
Before threads, the memory layout had four RAM segments (low -> high): data, BSS, heap and stack. The stack was 1kB, as I said. Since VaporWare makes very little use of heap (only for modes I think?) the stack has ample space to overflow and it never caused problems.
With threads, you still have four segments: data, BSS, heap and the main stack. This main stack is 1kB but it's now used only by the interrupt handlers (and briefly by the startup code). Your application thread stack is allocated on the heap. Since this is the first allocation ever, it'll be right after the BSS. When it overflows, it now overwrites the BSS, boom.

I've bisected the stack size and it starts to crash around 1.5kB. I'm running with 2kB and it works fine. From the linker map and needed size I estimate it was overwriting nearly the whole BSS, stopping halfway through the display buffer after breaking havoc in VaporWare and almost every SDK module, apart from dataflash and thread manager.

I will provide stack size control for the main thread (the only one you don't create yourselves). I will also include fault dumping code in the SDK.

In light of this, do you guys think I should provide some stack protection? There's an MPU on chip. While creating a region for every writable piece of data isn't really doable, I could stick a 32-byte (smallest possible size) region at the stack limit and set it to fault if anything is ever attempted on it. That way it'd be easy to detect this, instead of random corruption.