How to Reset the Dev Kit

How to reset the Developer Kit

This is super rough and will be edited later, but here is a quick guide on how to reset the developer kit. More to come soon.

If your Developer Kit becomes unresponsive and won’t program or is unable to be recognized by the OS, resetting the device allows to boot loader to run for a few seconds before starting the application code.

To reset the Arduboy Developer Kit , short the two test pads shown in the picture below.

Looking down from the top of the board, the programming pinouts are:

Timing is important when reprogramming in the boot loader, you only have a few seconds. The best practice is wait for your IDE to say “Uploading…” before resetting the device.

The reason this happens is the sketch has lost its ability to enumerate as a USB device correctly. The boot loader itself has it’s own USB information so when it restarts there is a window of time where you can restore communication and quickly program a new sketch.

This tutorial should work the same fore Codebender as well the timings are just a little different.

If you are still having problems after using this tutorial please let us know. Thanks!


I managed to fix mine when it was soft-bricked with just the Reset pin. Although it took many tries to get it to upload at the correct time.

So, will there be an easy way to do a manual reset on the production Arduboy, or will the problem not occur on it?

I’ve already added a safe mode to the core library (pull request is submitted) to avoid all this drama - if you’re using the core lib. This would only become necessary if you’re hacking on the core lib itself and break things. Normal app developers would never, ever need to do a hard reset.

Safe mode:

Hold down UP and LEFT. Plug into USB. Devices turns on to blank screen - your sketch is not run. Reprogram as normal.

The screen could be nicer, but I was trying to avoid additional dependencies so there would never be a reason to disable safe mode - so it would always be built and linked and available in an emergency.

Well, technically your sketch is run but the library startup code puts it in “safe mode” when it detects the key combo at boot so the part of your sketch that likely borked everything never runs… so anything your sketch would have done to break the CPU state now never happens.

good show old boy. keep up the fire

1 Like

Yes, this worked! During these 8 seconds, my computer registers this device as ttyACM0, but after it is back to the old, bricky behaviour. Uploading the arduBreakout during this window then restored normal behaviour.

As mentioned below, 8 seconds is not a lot of time, but I managed by starting the process, and immediately after releasing the RST to GND.

Kevin mentioned a reset switch built in, something about requiring a pin to press it though.

I have a few small changes I’d like to make if we were to refresh the bootloader… changing this from 8 seconds to more like 16 would be on the list.

Here’s what @bateske posted in the Kickstarter comments section yesterday:

Additional Buttons: We are planning on adding a start and reset button to the final product. We need to try and find push buttons that are similar to the power switch we are using now. Reset button will be harder to push needing a paperclip or similar.

Yep, reset button on the final one, we are looking into modifying the boot loader to increase the time limit as well!

Please let me know if reprogramming the boatloader is going to be possible because there are a few changes it’d be great to get in there:

  • fix the LED flashing on reboot to use the single LED we actually have
  • change timeout
  • power on screen and maybe add Arduboy logo when reset (since we’re in there to begin with)
  • see if size could be reduced to 2k, but that’s probably not feasible


You should be able to reprogram the bootloader if the required In-Circuit Serial Programmer (ICSP) pins are brought out to pads on the board, or if a connector or some other method of connecting to the required pins is available. This should be true because they will be needed to program the bootloader at the factory in the first place.

You will need to hook up a programmer to these pins in order to program the bootloader. The programmer can be a dedicated one or an Arduino running a ICSP sketch.

Adding ICSP header to your Arduino/AVR board
Using an Arduino as an AVR ISP

You’re welcome to add this to a custom bootloader but I don’t think it should be part of the standard one. Initialising and controlling peripherals in the booloader, if not required, isn’t usually done. It adds code that would probably have to be duplicated in a library for the sketch to use, thus increasing overall storage size.

Also, doing this would make it more difficult to achieve another your other goals:

Well it could be up to @bateske to decide what boot loader ships. When I asked if it was possible I didn’t mean technically. I guess I was assuming the Atmega32u4 ships with the Catalina bootloader… maybe they ship empty - in which case something would have to be flashed to that area. Unless the boot loaded can be decreased to the next storage size (2k vs 4k) then any extra space is free to use and we could program it to do something nice with our hardware, like turn on the screen, show a logo, etc. We’re not taking up program space to do that.

Since we have a screen it would be really nice if the bootloader knew about it and could show you status of the reprogram, etc… would be a neat trick.

Also, doing this would make it more difficult to achieve another your other goals:

Right, it might be one or the other. :slight_smile: Have to see how close we are.

An Atmega32u4 straight from the factory would be empty, or if not it wouldn’t be an Arduino bootloader. These chips are used more in other embedded systems than they are in Arduinos. Many of these systems wouldn’t even have a bootloader since they only run a single dedicated program.

An Atmega32u4 straight from the factory would be empty, or if not it wouldn’t be an Arduino bootloader. These chips are used more in other embedded systems than they are in Arduinos.

Duh. :slight_smile: My thinking makes no sense in hindsight… so we will be flashing a bootloader. Good to know. Although I bet a lot of people sell the chips “Arduino ready”…

Mostly just DIP packaged ones (which isn’t available for the Atmega32u4), in small quantities at higher prices, for hobbyists.

I guess the default bootloader can’t reflash itself since the instructions to run on the CPU are fetched from flash as the program runs?


I’m guessing that the boot loader lock bits are set in Arduinos, which I think means that the bootloader area can only be changed by a programmer, not by code running on the chip.

If boot loader lock bits aren’t set, then the bootloader could reflash itself, with the proper code. A sketch could also be written and uploaded, which could flash a new bootloader. But again, the lock bits are probably set, to prevent users from being able to “shoot themselves in the foot” by accidentally destroying the bootloader and then needing to use the ICSP to recover a bricked Arduino.

Yeah, as they probably should be. So ISCP needed then to refresh bootloader… I’m not in any hurry to try this. :smile:

on DEV kit: VCC | RST | MISO | MOSI | CLK | GND
on Uno board: 5v | D10 | D12 | D11 | D13 | GND

I have soldered pins to those pinouts and tried to use an Arduino UNO as ISP to burn a sketch, WITH success :smiley:

on the Arduino Uno, I first uploaded the ArduinoISP sketch (examples > Arduino ISP)

BOARD: Leonardo
Poort: the port for de Arduino used as ISP (I used an Arduino UNO)
Programmer: “Arduino as ISP” watch it ! NOT “ArduinoISP”

sketch > uploading using programmer

BUT it didn’t fix the problem for uploading sketches directly into the DEV kit, I’ll always have to use Uno as programmer.

PS: I also re-burned the bootloader alone, but it didn’t help either.