Bring your Arduboy back from the dead (burn bootloader)

This thread is amazing! Thanks @eried, so i guess we don’t need to send you a replacement? :stuck_out_tongue: :wink:


Only a green one now (because it is a zombie :stuck_out_tongue:)


I am not sure if they came to any conclusion (or any simple one at least). I mean, having to make those pin clamps (some guy says that the pads are really weak to solder and he destroyed his Arduboy doing that) or getting an expensive programmer (genuine Atmel) is going to be a bummer when you are repairing your dead device.

I was tinkering on using some pogo pins attached to a 3d printed holder… but holding the pins with an extra pair of hands was the perfect solution.

I am not really sure either why the bootloader was corrupted either but has not happen again.

1 Like

Now this is excellent and amazing!!! Thank you

Yours are the best solution!
Amazon also sales usbasp under $10 and an extra pair of hands are most stable.

I think the bootloader is corrupted when you write the big program (>28672 bytes) because it is in the last 4kb of the 32kb flash memory and it is overwritten then.

Only 10 bucks? That’s only like 7 times more :smile: what a deal.

The thing is the Arduino IDE forbids to upload a bigger code. I don’t really remember what actually broke mine but corruption started trying “.arduboy” loaders and games

My Arduboy is bricked, my PC is not longer detecting the unit.
I uploaded a program that was to big and the whole thing stopped working.

Will this fix my problem?

Yes it will fix that. How did you achieved to do that?

I’m using Visual Studio with the Arduino addon, It does track how big the program every time I compile and upload.
Shows this:
Program size: 26,780 bytes (used 93% of a 28,672 byte maximum) (3.83 secs)
Minimum Memory Usage: 1584 bytes (62% of a 2560 byte maximum)

So I assumed it wouldn’t upload if I was over.
But It only showed
Minimum Memory Usage: 1584 bytes (62% of a 2560 byte maximum)
and uploaded anyway voila bricked…

I checked my program on the regular Arduino editor and it shows
Sketch uses 30776 bytes (107%) of program storage space. Maximum is 28672 bytes.

so ya bug bug… hehe

@emutyworks did a great job here

I purchased myself a pair of these clamps used in this thread and it works like charm. Just in case you have no helping hands.

Finally received all the parts I needed.
It worked, my Arduboy is ALIVE!!!
Thank you for this guide


Congrats! Fancy clips, where did you get those?

1 Like



The clamps are 2 times the price of the usb programmer xD


“fancy” never comes cheap.


Once the boot loader has been successfully re-burned, you should make sure the bootloader area protection fuses have been set, to prevent the problem from happening in the future.

You can verify that the protection fuses have been set properly by uploading a sketch I wrote:

Strange, my only Arduboy that says OK with your sketch is the one I “repaired” with the method exposed here. The two other untouched units have Lock bits: 0xEF

It makes sense that the one you repaired says OK. Using the Arduino IDE to re-burn the bootloader should also set the lock bits properly after burning.

All Kickstarter units probably will say Bootloader UNLOCKED!
And, although @bateske has stated that production units should have the lock bits set properly, there is some evidence that this is not the case with at least some of them.

Are these Kickstarter or production units? What message do you get on the last line of the sketch output? If it says the lock bits are 0xEF, the sketch should and this with 0x3F and then compare with 0x2F and then report LOCK bits are OK. Are you sure the untouched units report Lock bits: 0xEF ?

All are production models, the one in the middle is the one I “repaired”. Yes, it seems the untouched ones are still not being properly locked. Maybe that is why they fail so easily :open_mouth:


True. It should be almost impossible to completely brick a properly protected Arduboy, even after attempting to upload a sketch that’s too large. The reset button should always work as a last resort.

The fact that all your units are production ones and were unprotected helps explain reports of other production units being bricked, and contradicts @bateske’s statment:

Either that or (some) preorders were protected but the factory then went back to shipping unprotected units.