Colourtwinkle does not work on MSP430

[brackendawson]

It's a bit spazzed out, if you compile with -O0 rather than -Os then the pattern generates an immediate reset rather than spazzing out. If you compile with very few patterns it works.

The pattern works on Arduino so the areas the bug might be are:

• random() as implemented by me - firework works, so I don't think it's this.
• code bug in colourtwinkle.h - maybe, arduino would need to be immune.
• gcc-msp430 has a bug - given it works with less patterns in play, I'd say this is probable.

[brackendawson]

I now believe this to be the stack and the heap colliding. We can probably reduce the heap size by taking all the buffers defined globally in all the patterns and move to the idea of using a common buffer, still some fraction of NUM_LEDS.

[brackendawson]

Have dug out the msp430 and re-created the issue on the tree, the lights just sort of flicker in some undefined pink colour in the colourtwinkle pattern, but otherwise the lights work fine.

Section sizes:

$ msp430-size lights.elf -x
   text    data     bss     dec     hex filename
 0x1328    0x38    0xae    5134    140e lights.elf

Annoteted memory dump at main() entry

Breakpoint 1, main () at main.c:25
25  USICTL0 = USISWRST;           // Stop spamming the USI during init
(gdb) x/128hx 0x200
0x200:  0x0101  0xe646  0xe0a4  0xe0a6  0xe0be  0xe5ae  0xe0c8  0xe0e0
0x210:  0xe1d0  0xe508  0xe0ea  0xe1f8  0xe4fa  0xe0f8  0xe6d2  0xe116
0x220:  0xe12e  0xe3e8  0xe146  0xe15e  0xe234  0xe278  0xe3ca  0xe858
0x230:  0xe16c  0xe3a6  0xe358  0xe4e8  0x0000  0x0000  0x0000  0x0000
                                      ^-- end of data, start of bss
0x240:  0x0000  0x0000  0x0000  0x0000  0x0000  0x0000  0x0000  0x0000
0x250:  0x0000  0x0000  0x0000  0x0000  0x0000  0x0000  0x0000  0x0000
0x260:  0x0000  0x0000  0x0000  0x0000  0x0000  0x0000  0x0000  0x0000
0x270:  0x0000  0x0000  0x0000  0x0000  0x0000  0x0000  0x0000  0x0000
0x280:  0x0000  0x0000  0x0000  0x0000  0x0000  0x0000  0x0000  0x0000
0x290:  0x0000  0x0000  0x0000  0x0000  0x0000  0x0000  0x0000  0x0000
0x2a0:  0x0000  0x0000  0x0000  0x0000  0x0000  0x0000  0x0000  0x0000
0x2b0:  0x0000  0x0000  0x0000  0x0000  0x0000  0x0000  0x0000  0x0000
0x2c0:  0x0000  0x0000  0x0000  0x0000  0x0000  0x0000  0x0000  0x0000
0x2d0:  0x0000  0x0000  0x0000  0x0000  0x0000  0x0000  0x0000  0x0000
0x2e0:  0x0000  0x0000  0x5a08  0x11c7  0x897a  0xeada  0xe0d0  0xe914
                              ^-- end of bss
0x2f0:  0xe9d4  0xea9a  0x010c  0x882d  0x0001  0x0006  0x0058  0xe09a
(gdb) info registers
pc/r0: e044  sp/r1: 0300  sr/r2: 0003     r3: 0000  
fp/r4: 9bff     r5: 5a08     r6: feff     r7: bddf  
   r8: dbff     r9: dff7    r10: fffe    r11: fbfc  
  r12: df4e    r13: 9b7d    r14: 0001    r15: 0000  

That doesn't leave much room for the stack at all, and it looks like the stack has already been there. Setting 0x2e4 and 0x2e6 to 0xf00d and then running even pattern 1 suggests the stack is overflowing this boundary already. colourtwinkle_buffer does occupy the very end of the bss section, so the colours in this pattern will be trampled first:

Breakpoint 2 at 0xe35c: file colourtwinkle.h, line 19.
(gdb) c
Continuing.

Breakpoint 2, colourtwinkle_frame () at colourtwinkle.h:19
19    if (colourtwinkle_div++ < 12) {
(gdb) print colourtwinkle_buffer
$1 = "\376\377\374\373p\353\000`\352E\000@\036D\003"
(gdb) print &colourtwinkle_buffer
$2 = (unsigned char (*)[16]) 0x2d4

Stack overflow confirmed, the solution is to either use less memory or have more memory.

[brackendawson]

With colourtwinkle removed from the rotation, can confirm that the stack never overflows the heap.