Bring your Arduboy back from the dead (burn bootloader)

(Scott) #21

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 ?

(Erwin) #22

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:

(Scott) #23

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.

(Scott R) #24

Thought I would give the sketch a shot out of curiosity on my Arduboy and its reporting the bootloader is unlocked.
I assume this is fairly new stock as it was purchased from Pimoroni on 30th April 2017.
Think i’ll order a programmer now for just incase.

(Erwin) #25

Mine are also from Pimoroni

(Kevin) #26

@eried Wow thanks for doing some testing looks like we get to have a conversation with our factory and try to figure out how this happened!

I’ll have to admit after the first round of production came out we tested those units so it would seem at some point the factory made a change and switched test jigs or something? We don’t serialize our production batches (yet) so it’s actually pretty tough to say how many units would be effected.

It would be maximum of around 2,000 units but if you do end up having an issue bricking a device, and for sure the reset button doesn’t work then use the contact form to get a hold of us and we can help you resolve the situation.

It’s kind of frustrating and enlightening at the same time to see a post like @eried with the display on the screen of how the lock fuses are, this is kind of like the problem we had with the RGB led where it seems very easy to design a test for it but in the rapid pace of production some times it’s simple to forget that it’s pretty easy to put together something like this.

Anyways, its still remarkably difficult to overwrite the bootloader, as it requires some kind of glitch or malfunction to occur, but it does make it technically possible so obviously we will fix this in the future.

Don't install the Fidget Spinner app! - Get help here
(Scott) #27

Or attempting to burn a sketch that is too large using an uploader other than the Arduino IDE, which doesn’t check the length before uploading, such as @GrisWoldDiablo described earlier in this topic by using Visual Studio:


I just tested my 2 units. Only the one I “debricked” says LOCK.
Is there a way to set the lock bits with a simple program or I should just do an other burn boot loader?

(Kevin) #29

You can use the command:

-U lock:w:0xEF:m


Also using Arduinos “burn bootloader” will work with arduino leonardo set as the target, the fuses are set as part of the process.

(Scott R) #30

Maybe I’m missing something but I’m unable to use “burn bootloader” maybe its something wrong with my environment?
Its no big issue as I’ve ordered a USBasp and currently am not bricked its just perked my curiosity.

Arduino: 1.8.2 (Windows 7), Board: "Arduino Leonardo"
C:\Program Files (x86)\Arduino\hardware\tools\avr/bin/avrdude -CC:\Program Files (x86)\Arduino\hardware\tools\avr/etc/avrdude.conf -v -patmega32u4 -cstk500v2 -Pusb -e -Ulock:w:0x3F:m -Uefuse:w:0xcb:m -Uhfuse:w:0xd8:m -Ulfuse:w:0xff:m 
Error while burning bootloader.
avrdude: Version 6.3, compiled on Jan 17 2017 at 12:00:53
         Copyright (c) 2000-2005 Brian Dean,
         Copyright (c) 2007-2014 Joerg Wunsch
         System wide configuration file is "C:\Program Files (x86)\Arduino\hardware\tools\avr/etc/avrdude.conf"
         Using Port                    : usb
         Using Programmer              : stk500v2
avrdude: usbdev_open(): did not find any USB device "usb" (0x03eb:0x2104)
avrdude done.  Thank you.

(Pharap) #31

Look on the bright side, at least the program was very polite :D

(Scott) #32

You can only burn the bootloader, or set the fuses, using an AVR hardware programmer. You can’t do it using the Arduboy’s USB port. Since you said you’ve ordered a USBasp, I’m assuming you don’t already have a suitable hardware programmer.

(Scott R) #33

Ahh it makes sense I misinterpreted Kevins post [quote=Also using Arduinos “burn bootloader” will work with arduino leonardo set as the target,"][/quote] I assume it also impossible to for the hardware to lock itself with a sketch?

:blush: I should have read the whole post where I found your sketch.


(Scott) #34

Just a word of caution:

The signals that you attach a hardware programmer to are also wired on the circuit board to the display. The display is designed to run at a maximum of 3.3V so if you feed 5V power and/or signals into it you risk damaging the display. Therefore, it is advisable that the hardware programmer you use is capable and set to run at 3.3V

The widely available USBasp V2.0 “clone” programmer, linked to in the original post, has a 5V/3.3V jumper but this only sets the voltage provided on the connector’s VCC pin. Even when jumpered to 3.3V, the output signals (RESET, SCK, MOSI) will still swing to 5V, risking damage to the display. Although, as reported, others have had success using this programmer, with no apparent damage to the Arduboy, be aware that based on the display specifications there is some risk involved.

I have this programmer and have verified what I’ve said above. I’ve modified my programmer to provide both the proper power and signal voltages based on the jumper selection. (I also added some bypass capacitors to improve power supply stability).

(Kevin) #35

You’ll be fine with 5v :slight_smile:


And I can confirm.
I left the jumper at 5 volt on the USBASP when I reprogrammed mine.
I was wondering if I should change it to 3.3V.
But since the battery on the Arduboy says 3.7V so I guess this was not related. I figured the jumper was for input and not output.
Anyway it worked fine.

(Scott) #37

Sure, you could be fine. I’m just cautioning there’s a possible risk based on the data provided by the display manufacturer. Take it as you wish.

(Scott) #38

No, the jumper sets the voltage provided out of the VCC pin on the programmer’s connector, that powers the Arduboy (thus its display’s VDD pin) if you hook it up to the Arduboy’s VCC pad. Without modifications to the programmer, the jumper doesn’t control the high level voltage provided on the signal outputs (RESET, SCK, MOSI) which will always be 5V.

(Fernando Jerez) #39

Worked for me :grinning: !!! Thanks @eried

Just want to explain a llittle trouble i had and how to solve it.

After clicking ‘Burn Bootloader’ avrdude throws this error: avrdude: error: could not find USB device with vid=0x16c0 pid=0x5dc vendor=‘’ product=‘USBasp’

Problem was the USB drivers (i’m using Win 10).
Solved downloading this program:


And assigning WinUSB to the USBAsp device (didn’t recognized by my PC)

This can be useful for someone having same ‘drivers’ problem.

(Erwin) #40

How did you held the pins? Fancy clamps?