I got my Meggy Jr a few days ago, and had a blast playing with the example programs, and working on a couple of my own.

But today, I've run into a big snag - it seems all of the complex (or at least large) example programs have stopped working on my Meggy...while the simpler example programs still run fine.

I'm worried that I may have damaged the bootloader (?) with some clumsy coding. What is really odd thing is that a corrupt program seems to be persisting, and appearing in between powering on and off...read on for more.

The problems appeared after I was playing with a modified version of plasma.pde. I had put together a program that borrowed a bunch of code from that file, and suddenly after one upload of my app, the Meggy would only display a couple of slates of plasma data before going blank and appearing to restart loop() (instead of the usual smooth behavior of plasma.pde, where the display never goes completely dark).

I figured it was my fault - but I couldn't find the problem in my code. Eventually I loaded up the original plasma.pde and found it had the same problem (just a few slates are displayed before the display goes dark and seems to restart).

Then I realized that all of the complex example programs I previously had run successfully were no longer working - most of them show the same behavior described above (the brief flash of what appears to be a corrupted version of plasma.pde)

The example and contributed programs that fail to start properly on my device are:

MeggyJr_Attack
MeggyJr_FroggyJr
plasma.pde
invaders.pde

But all of the less complex/smaller example programs still work as expected:

MeggyJr_Blink
MeggyJr_CheckButtonsDown
MeggyJr_CheckButtonsPress
MeggyJr_CustomColors
MeggyJr_EasyDrawDots
MeggyJr_MeggyBrite
MeggyJr_ScrollText
MeggyJr_SetPxClr


Could I have fried my Meggy somehow via a coding mistake? It's really odd that the same corrupted app seems to appear between switching the power off and on.

I did notice one odd behavior in my app just before this all started happening - I briefly included this line, inside loop(), in my program:

return;

I was trying to return from loop() early - but what seemed to happen in practice was that the program would re-run the setup() function each time that return was evaluated! I didn't think that was possible, based on reading the docs.

Anyway, I don't know if that had anything to do with the larger problem or not.

Please let me know if anyone else has seen anything like this, or if there are any hints on how to fix it.

If I have managed to damage the bootloader, is there any way to flash it myself and make my Meggy factory-fresh?

If you can still use the bootloader to load some programs successfully, that means that it's still working correctly, and you should look elsewhere for the problem. In any case, the bootloader should be protected so that it can't be overwritten with a USB-TTL cable.

The first thing that you should try is a fresh set of batteries. The four programs that seem to crash your Meggy Jr are ones that are graphic heavy. The mode of failure that you should expect when the batteries go is that the voltage drops too low, and the thing restarts, when you display too many pixels at once. You may also notice some color changes when the batteries are going-- white may look yellow, for example.

a fresh set of batteries[/p]

That was it! Thanks so much. Don't know why I didn't think of that - guess it's easy to overlook the simple fixes sometimes.

Heh, that answers the question I came in here for. Nice to know it's not a serious hardware problem, but dang, this set of batteries only lasted two days... I guess the project I'm working on is a little power-intensive. >_>

Guess I'll have to install an external power supply...

Yeah... turns out that running 200 LEDs takes some power.

We don't actually swap out batteries in ours all that often, but we're pretty careful to turn off the batteries when we're doing playing-- the power consumption is nonzero even when there aren't any LEDs on.