Don't install the Fidget Spinner app! - Get help here

I’ve had my Arduboy for a week now, and been enjoying uploading games, and having a dabble at coding.

This morning I tried a “Fidget Spinner” (I hope it wasn’t malware!) ‘simulator’, and it was when this program was running that I ran into problems getting a new program uploaded.

I’ve ran through the usual processes to get something uploaded - pressing reset, and hitting upload at the same time, pressing up when I turn the device on, and then uploading, trying a different COM port, and 3 different PC’s.

It appears to be the behaviour of the Arduboy.

When I turn it on - it behaves normally, the fidget spinner program runs, and it also gets recognised as a Leonardo in Device Manager.

BUT - this is where it all goes wrong. When Arduino IDE uploads a sketch, it warm reboots the device. When it does so, the device doesn’t respond with any device ID! So it’s not recognised.

Checking in Device Manager - “Unknown USB Device. (Device Descriptor Request Failed).”


Hm - I experimented some more.

I’ve followed the instructions VERY closely here:

My result is different from the one there - I press the recessed reset button by the USB plug, the device screen goes blank FOR GOOD. It disappears from Device Manager and I hear the disconnect, then it comes back (the connect music plays) BUT INSTANTLY (there’s NO 8 seconds!) it appears as an unknown device.

If I turn the Arduboy’s power off at the switch then back on - it appears as a Leonardo again.

It behaves on 3 PC’s like this, when I’d uploaded things from them before. =(

So the situation is - ANY warm reboot causes it to crash, and the device descriptor is NEVER sent.

I can’t avoid it during upload, because ALL the uploaders (ARG, Arduino IDE, and Arduboy Manager ALL reset the device to get it into flash mode before sending the code up)

Does anyone have any ideas? Upload mode just isn’t recognised by any of my PC’s any more.

1 Like

Sounds like the bootloader’s busted.
That can happen for a lot of different reasons (from picking the wrong destination board when uploading to mysterious reasons nobody’s ever been able to pin down).

You can either send your Arduboy off to be fixed, in which case you need to use the contact form:

Or if you want to have a go at fixing it yourself (which might be quicker if you have any experience with electronics) then follow the instructions in this thread:

Also if it is the fidget spinner sketch’s fault, it won’t have been intentional.
It would be pretty difficult to purposely brick an Arduboy.
For one thing, there’s these fuses that are supposed to prevent a sketch from overwriting the bootloader.

Although it has been discovered that sometimes the fuses weren’t/aren’t set right at the factory so it’s been possible for some Arduboys to become bricked due to accidental overwriting of the bootloader because the fuses aren’t set.


Like @Pharap said your the bootloader is most likely corrupted (or a fuse setting is). maybe the download was bad if the sketch itself is bad but I would(will) expect more people to run into this problem. Where did you download it from?

In device manager. Can you right click the unknown device and click properties before it dissapears again? If so when you go to the details tab and select hardware-id what VID and PID does it show?


You’re right, it’s got to be co-incidence.
I got it from this popular page here:

Which leads to here: FidgetSpinner - A very simple fidget spinner simulator for Arduboy

It looks fine - a fair bit in PROGMEM, but I’m aware of the bootloader pointer issue with large sketches, and tried the fixes particular to that too.

As for the device manager information…

I get this when it’s first plugged in:

Device instance path:

Hardware Id’s:

… then after a warm reboot(reset button or setting baud to 1200 or pressing upload) - I see this:

Device instance path:

Hardware Id’s:

Ugh - looks like Windows gave up on it.

This is on 4 PC’s now - I’ve tried it in work too. =/

I’ve got one of those transparent blue ICSP programmers - which I’ve never tried using yet - it could be a good time to see if it works.

But I don’t want to void my warranty by opening it up - if it’s got a warranty that works like that?

Hello Sarah

I’m so sorry this has happened to your Arduboy while running my “game”. I confirm that this was not intentional. I have now posted a comment on my project to warn people against installing this while this issue is getting sorted out.

How did you flash the game? Was it from the pre-compiled binaries or was it compiled from source?

Unfortunately I’m at work right now, so I can’t really test anything or be of much help, sorry.

If we confirm that it is something with the sketch, I will happily pay you for a new Arduboy.

Sorry :frowning:


It can’t be your fault that your game messed the Arduboy, otherwise it would be super dangerous to try any game. For some bizarre reason, my Arduboy also got screw while testing the latest version of the spinner (from the pre-compiled binaries)… that is the reason why I finally designed a pogo pin isp gig for recovering my Arduboys more quickly.

I think the problem is because some Arduboys do not have the lock bits set properly so they corrupt easily when they shouln’t.

I think @bateske won’t care if you open it and fix it. Additionally, there is no way to say an Arduboy was opened or not.


I can’t really check right now, but iirc the Arduino IDE has two options for exporting pre-compiled binaries: with or without bootloader. I’m quite a novice on this, but could the wrong version screw things up with the bootloader or something?

To be honest I don’t remember which one I created. When I get home, I will check which option I used.

1 Like

Like @eried said, it won’t void the warranty as long as you’re following the instructions properly.

If you are worried that you might mess it up, it’s probably better to use the contact form to say what’s happened and arrange for the unit to be shipped over to Arduboy Inc be fixed. If you’ve got the tools to hand there’s no harm in trying though.

I know a guy who managed to burn through 3-4 Arduboys when developing a game (*cough* @filmote *cough*) and he had to send all of them away to be fixed and patiently wait for them to be returned. It’s still a bit of a mystery as to what caused it, but it was almost certainly a bootloader issue.

1 Like

Yeah it seems you used the one with the bootloader for creating the precompiled .arduboy and hex. I need to add a detection for that issue into my uploader


Thank you so much! :heart: I will update the project ASAP!


Hello @SarahC if you feel you can repair the device on your own, you can go for it. If you don’t feel comfortable cracking it open and soldering then you can reach out to us at and we can try to help from there.

There seems to be some occasional problems where units are bricking themselves in very strange ways. It all started happening somewhat recently (2-4 months) and the cause is not completely known.

How did you upload the code?


I didn’t want to say this earlier. But I used Erwin Reid’s repo of the fidget spinner on the computer using, the pc software Arduboy Uploaded.

I think you have the exact same problem I had. Reflashing fixed it, and I’m staying clear of that spinner hex.


Ok seems like there is an issue installing this via the hex. Just for the record was this done with the flashing tool from @eried website?

1 Like

Yes sir. For me it was.

And twenty more characters.

1 Like

Yeah, I uploaded the precompiled files from @Trigonated github instead of compiling my own (it is fixed now in my repo, I compiled it from the sources now)… And I will make my uploader smarter this week to avoid this issue in the future.


Yes the bootloader is corrupted and you need an ICSP programmer or an Arduino to reflash the bootloader.

You can but don’t try to mess with the fuse settings you don’t need to change them for flashing the bootloader.

I noticed the hex file includes the bootloader. I didn’t do a binary compare but I’m sure that when the bootloader tries to overwirte itself at the same place where it is executing it will be unsuccessul due to the way programming works.

A simple method for checking hex files that have code in the bootloader area is to look for a line that starts with :xx7 ( xx isdata length usually 10 or 20):

 if line[0] ==':' and line[3] == '7':
    print 'warning this hex file may corrupt the bootloader on unprotected devices'
1 Like

Yes, I am adding something similar, but the bootloader is at the end of the hex file. And I can take advantage of something lazy that Arduino IDE does:

They append the firmware without changing the format. So I can identify easily when the hex has the firmware appended. All other tools use :1XXXXXXX format instead of :2XXXXXXX

So, I will be lazy too and add that as the condition. I can change it in the future to something better like a pattern that all firmwares should share. But I already checked my hypothesis with all the games in the repo, and the assumptions are valid :slight_smile:

I hope the new rule leads to get a really safe uploader.


I’m not seeing how that can help in detecting bootloader code.

you could just load in the hex file and step throught each line and break when the check is successful. I’ve just added the check to my python uploader script

#scan hex file for data in bootloader area
f = open(filename,'r')
lines = f.readlines()
for line in lines:
	if len(line) > 4:
		if line[0] ==':' and line[3] == '7':	
			print 'Warning!!!\nThis hex file may corrupt the bootloader on unprotected devices. Upload aborted.'
1 Like

Ah, I see what you mean. Makes sense, I added something similar to the latest Arduboy Uploader, I hope it helps to prevent more unwanted Arduboy deaths :star_struck: