Serial port disappears when the transfer is started

I have the trouble of the USB serial port with Arduboy.
The serial port disappears when the transfer is started.
Please let me know how to recover that.

(1) Turn on Arduboy
(2) Push the reset button of Arduboy
(3) (The serial port can be found at the time)
(4) (Red and orange LED turn on)
(5) Open Arduino IDE and read the sketch “Helloworld”.
(6) Push send button of IDE
(7) (When IDE start transfer, the serial port disappears immediately.)
(8) (After that, the green and yellow LED flash randomly.)
Here is the video:

Before the issue above, I sent the firmware for devkit below [1] to my Arduboy 1.0 with the batch file [2] mistakenly. (A)
[1] Tiny depth - taste of game watch
After that, I also sent another large image. (B)
So I think the cause is either of (A) or (B).

I already tried:


  • Arduboy: not for devkit
  • IDE: Arduino IDE 1.6.9
  • OS: Windows 10 Home

A note on the serial port, it will always disappear after the unit resets. As the unit turns off to prepare for the upload, and then back on, the operating system must repoll and reassign the port.

You have to time things exactly when you use the reset button. You only have about 8 seconds. Make sure you load the sketch into the IDE and compile it using the verify button before pressing reset and starting the upload.

It may also help if you use a small sketch to try to recover, such as the HelloWorld example from:
File > Examples > Arduboy > HelloWorld

1 Like

Yeah, I think that this is it too. Here is another resolution that seems similar.

So @koteitan, keep trying the reset button, and keep in mind your timing has to be just right.

1 Like

Hi Ross and Scott,
Thank you for your replying.

Yes I always use the reset button because the serial port can be no longer recognized without the reset button at first.

I tried many times and I tried any timing between pushing unit reset and pushing IDE send button, Immediately or 0.5–6 sec.
I push the reset button too much so that the reset button was broken today:)

On IDE, does pushing the transfer button after pushing the compile button makes transfer without compile?
It looks always compile occurs before transfer when I see detail console output.
(1) pushing compile button
(2) (compile is done)
(3) pushing transfer button
(4) (somehow compile starts again)
(5) (transfer begins after that)

The upload or transfer button will always recompile the code I believe, it does this to build the final binary (.hex) file before it is uploaded to the unit.

It might also be helpful to run something like in the background to see what signals are being sent and when to the Arduboy.

The operating system does not need the Arduboy to show up in the device manager as a com port for the unit to work with the IDE. I think Windows 10 is most notorious for this behavior.

So even if the com port doesn’t show up in the device manager, you should still be able to use the Arduino IDE to upload a sketch.

Also, if your unit is bricked, you will only need to press the reset button one time to upload a new sketch and fix the unit. After using the reset button successfully once, the unit should work as normal, and you shouldn’t have to press the reset button again.

What happens when you upload a sketch that is too large is the unit will look for the instructions to start operating at a specific address, and a sketch that is too large will put something else in that usual location, causing the unit to no longer function until a correctly sized sketch is used.

If things are a little unclear…

私たちも私たちの日本語セクションを促進しようとしています!あなたにもそのカテゴリに質問をすることができます。あなたは、より良い答えを得る可能性があります。 #ja

With the detail information in the console, It looks success to grab COM5 but failed to connect to programmer.
Has DFU broken??

     PORTS {} / {} => {}
     PORTS {} / {} => {}
     PORTS {} / {} => {}
     PORTS {} / {} => {}
     PORTS {} / {} => {}
     PORTS {} / {COM5, } => {COM5, }
     Found upload port: COM5
     E:\program\Arduino\hardware\tools\avr/bin/avrdude -CE:\program\Arduino\hardware\tools\avr/etc/avrdude.conf -v -patmega32u4 -cavr109 -PCOM5 -b57600 -D -Uflash:w:C:\Users\fletcher\AppData\Local\Temp\build7b781f23ea553cdc5cbc6e57d2290188.tmp/HelloWorld.ino.hex:i 
     avrdude: Version 6.0.1, compiled on Apr 15 2015 at 19:59:58
     Copyright (c) 2000-2005 Brian Dean,
     Copyright (c) 2007-2009 Joerg Wunsch
     System wide configuration file is "E:\program\Arduino\hardware\tools\avr/etc/avrdude.conf"

     Using Port                    : COM5
     Using Programmer              : avr109
     Overriding Baud Rate          : 57600
     AVR Part                      : ATmega32U4
     Chip Erase delay              : 9000 us
     PAGEL                         : PD7
     BS2                           : PA0
     RESET disposition             : dedicated
     RETRY pulse                   : SCK
     serial program mode           : yes
     parallel program mode         : yes
     Timeout                       : 200
     StabDelay                     : 100
     CmdexeDelay                   : 25
     SyncLoops                     : 32
     ByteDelay                     : 0
     PollIndex                     : 3
     PollValue                     : 0x53
     Memory Detail                 :

                              Block Poll               Page                       Polled
       Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
       ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
       eeprom        65    20     4    0 no       1024    4      0  9000  9000 0x00 0x00
       flash         65     6   128    0 yes     32768  128    256  4500  4500 0x00 0x00
       lfuse          0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
       hfuse          0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
       efuse          0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
       lock           0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
       calibration    0     0     0    0 no          1    0      0     0     0 0x00 0x00
       signature      0     0     0    0 no          3    0      0     0     0 0x00 0x00

     Programmer Type : butterfly
     Description     : Atmel AppNote AVR109 Boot Loader
     Connecting to programmer: .avrdude: butterfly_recv(): programmer is not responding

Oh amazing you have the follow-the-sun support:)
I try to ask that in the Japanese section too when they wake up:)
Thank you for your supporting.

1 Like

I think the libraries are only compiled once if they haven’t changed and you haven’t changed board types. If it’s not the libraries, then it’s something else, resulting in the second (third, etc…) verify or upload compile process being shorter.

You can see this for yourself:

  • Select from the menus:
    File > Preferences
  • I the Settings tab, set the check box for Show verbose output during: compilation
  • Click on the OK button at the bottom right to save the preferences.
  • Shut down the IDE and then restart it.
  • Load a small sketch into the IDE, such as:
    File > Examples > Arduboy > HelloWorld
  • Click on the Verify button and note the amount of output during the compile. You can expand the output box by clicking and dragging its top border upwards.
  • Click on the Verify button again (or the Upload button if you want to upload the sketch).
  • Note that there will be less output, and the build time will be shorter, the second time .
  • If you’re ambitious, figure out what steps weren’t performed the second time :smirk:.

I wonder if the bootloader may have been corrupted? I don’t know if it’s been confirmed whether the factory failed to set the bootloader lock bits properly.

It is likely the bootloader has been corrupted, users of a earlier version of Platformio uploaded a sketch that was too large for the device and they had to use another arduino hooked up to the programming pins to revive it.

@koteitan do you have another arduino?

@ekem maybe we should deprecate the batch file stuff to the developer section due to the potential problems there?

Yes I got the new board today:)
Now I’m trying to rewrite the bootloader as same as veritazz’s.

I use my new arduino as the writer with ArduinoISP.

Do you have the better idea than that I mean?


Oh I think it works as an open issue better than a development technique. Any given developer could run into this problem if they try some wild style programming.

What I propose is: when we have created a topic/reply that is a series of steps a user can follow in the case they need to rewrite the bootloader we publish the steps as a guide and close this issue by linking to that guide.

Sound decent @bateske?

Here is the description of the process in ja

I will write english document after 1, 2 days.

The solution of a problem is waiting now. probably arduinoISP can reset arduboy.
I wait his report.

1 Like

YEP !! it is all about the right timing to find for yourself to get the bricked arduboy back to “life” again… maybe painful for the newbies BUT this is how we learn new things :neutral_face:

Not if the bootloader has been corrupted, which is looking like may be possible.

ah okay. is there any chance to fix the bootloader for the “not-so-technical-guys” if it is corrupted???

The only way to fix a corrupted bootloader is to burn it again using a programmer attached to the MOSI, MISO, SCK and RESET lines. (Actually you can also use a parallel programmer, but that’s even more complicated.)

You can’t do it through the USB port, so I’d say no, there’s no easy way for the “not-so-technical-guys” to do it.

The fact is, it’s very difficult to corrupt the bootloader if the proper lock fuses have been set after its been burned. However, as has already been mentioned earlier, it seems like there’s a possibility that the lock fuses weren’t set properly on the Kickstarter Arduboys (yet to be confirmed).

PS: You also need a programmer to set the lock fuses.