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?
Yes sir. For me it was.
And twenty more characters.
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'
...
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 
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()
f.close()
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.'
delayedExit()
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 
Hello!
I have finally updated the pre-compiled binaries to not include the bootloader, hopefully stopping the killing of more Arduboys.
Thank you all for all the help in troubleshooting this issue and sorry for all the distress caused 
@SarahC You will soon receive a pm. Sorry for all the trouble.
Hi Trigonated!
It’s been a learning experience for everyone, there’s no way you could have known some devices are a bit sensitive to the alternative bootloader.
I imagine you uploaded your FS simulator to your Arduboy multiple times - and nothing strange happened. It must be something about my chips fuse settings.
You’re very gracious to offer to replace it - but I cannot accept. My device is fine - it’s just some code that needs changing on it. I’ll flash it this weekend after I’ve bought some pogo pins and my house mate is around to hold them on the board. =D
Technically - the Arduboy is designed to survive “bad” sketches, due to the bootloader activating after reset is pressed, or via the “torch” mode that gets uploaded with sketches using the standard libraries. So this would be something the creator would need to address. Somehow some code got around the protection.
Kevin has already contacted me privately and offered to send out a replacement! That’s far more than required. He could have simply said everything works, and no replacement can be sent out because I uploaded the sketch, and so I need to flash using JTAG. He DIDN’T…
Awesome customer service!
Besides - It’s just a dodgy bootloader state and I’ve got a JTAG programmer - the device has nothing wrong with it. It would be remiss of me to be lazy and post it back.
I LOVE this community! Look at all this activity investigating the issue and getting a fix organised in 48 hours!
Tiago - are you working in a development position yet? With your attitude and passion you’d be a senior dev in short time. =)
Ooooo! Have you got a pogo device thingy for sale?
Does it go across all the pads in one, or in two halves?
I want to flash on the weekend.
Hi Kevin!
Yes http://arduboy.ried.cl/ , using the uploader program integrated with my Chrome browser.
I downloaded the Fidget Spinner sketch that was prior to Version 2.1.
The Spinner’s now been fixed (as of Version 2.1) info is here. YAY!
I can spin to my hearts content without making my fingers sore.
(The uploader works VERY well… just a browser click and game appears… my favourite uploader.)
What exactly happened?
Is the program counter changed to some address held in the EEPROM when the device is warm booted? … that points to the bootloader code?
I can imagine this being changed when a sketch containing a bootloader is uploaded, to point to the new bootloader between reboots.
If that’s not it - (just a guess from me) - how’s the bootloader normally started?
How did the sketch screw with it?
(I’m fascinated with the details - Later I’ll google the chip’s info for bootloaders, but I wanted to get a Arduboy specific explination.)
All pads in one, I do not have one to sell but you can print your own 
If you install the latest one (v1.1 or newer) it wont happen again even if you try to upload the same “broken” game
Thanks for pointing that out … the first two were a surprise the third was me just stupidly not believing the first two were gone and trying again.
Thank you and thank you @bateske for going out of your way to provide excellent customer service!
Tiago - are you working in a development position yet? With your attitude and passion you’d be a senior dev in short time. =)
Thank you, right now I work as an Android developer (thankfully, haven’t bricked any phones yet), occasionally playing around with dev for the Arduboy and Game Boy Advance for fun. I just love small portable devices 
As to exactly what happened in your case, I can’t say. But…
The bottom line is that in a perfect world it shouldn’t have happened. The bootloader is in an area that can be protected from being overwritten by setting “lock fuses”. This is generally done for Arduino products. Unfortunately, Kickstarter Arduboys and a good number of production units were shipped without the proper fuse settings, resulting in the possibility of overwriting/corrupting the bootloader code, preventing further sketch uploads via USB.
For details on bootloader capabilities of the chip you can look at the ATmega32U4 datasheet, specifically section 27.
A simple explanation of what the bootloader does can be found here.
For details on the actual “Caterina” bootloader used by the Arduboy, one option is to look at the source code.
You’ll be permenantly in the Arduboy history books for that incident.
I brought it up because aside from the similarities in the two cases all of your Arduboys work now, so it’s a testament to the fact that sending your Arduboy away to be fixed does indeed work.
Thanks for your two posts - I’ve got some evening reading tonight before bed. Cool!
