How to upload a .hex to the Arduboy?

As @filmote said, do you have any idea what the right settings are?

I’ve attempted to use avrdude in the past with something along the lines of avrdude -p m32u4 -c arduino -P COM# -U flash:w:"file.hex":i but with no success (the command line just locked up, it would not even accept ctrl+z to cancel).

Yes, in fact all uploaders use avrdude internally.

I always go to github and download the zip with the source, then wait few minutes for arduino, compile and fiddle around selecting the right port and… just kidding I always use my uploader of course :stuck_out_tongue:


Is it Windows only or does it do Mac & Linux too?

(Knowing you, I’m guessing it’s written in C# and thus needs Wine to run on Linux.)

Yes, only Windows. And does not work on mono nor wine because depends on avrdude.exe, so no Linux/Mac

1 Like

Makes sense … just never made the connection.

If you upload a sketch using the Arduino IDE and set checkbox Show verbose output during: upload in the IDE preferences, somewhere in that output will be the avrdude command it uses, including the switches and options.


avrdude works on Linux and Mac, so it’s possible it might work with mono/wine if they support whichever function you’re using to start avrdude.

I assume you’re using System.Diagnostics.Process.Start to run it?

It seems it’s not quite that simple.

Aside from pulling both the avrdude executable and config file from %APPDATA%, it seems that before calling avrdude the IDE does something significant to the COM port that severs the Arduboy’s connection to that port and moves it along to the next free port in preparation for the avrdude upload.

Forcing reset using 1200bps open/close on port COM4
PORTS {COM4, } / {} => {}
PORTS {} / {COM5, } => {COM5, }
Found upload port: COM5

Attemping to use the same command the IDE claims to be using yields

avrdude: ser_open(): can’t open device “\.\COM5”: The system cannot find the file specified.

And attempting to replace COM5 with COM4 yields many

Connecting to programmer: .avrdude: butterfly_recv(): programmer is not responding

messages, until it eventually gives up.

Maybe… never tried. All the steps are very clear in my uploader source. I am pretty sure most of them work in mono, but there is stuff that I do not know, for example how to handle the “arduboy:” links in other platforms

Oh, you’re providing avrdude yourself?

In that case you’d have to be able to detect the OS and provide the correct copy if you’re providing the executable.

If are allowing the user to provide the avrdude path rather than letting the program provide the executable then it should work (assuming wine/mono are implementing Process correctly).

Oh, but the ManagementObjectSearcher code won’t work…

Yeah, it would need to be changed to run with mono/wine.
It’s a shame, but it’s probably not worth the effort.

Well, it is a resource just for convenience of having a single exe. For a mono version, avrdude could be required as a prerequisite.

But it just drills down to the low interest I have in mac stuff in general.

1 Like

I’d consider having a go myself, but I don’t have access to a mac, so I’d be flying blind.

Plus I’d have to substitute ManagementObjectSearcher for a custom class using that interops some of OSX’s OS-specific library functions, which could get a bit hairy.

Well, not quite, but if you’re pulling values from %APPDATA%, it seems like you’re doing it the hard way. I get the following output for mine, copied directly from the log window:

/home/mwm/Downloads/x/arduino-1.8.2/hardware/tools/avr/bin/avrdude -C/home/mwm/Downloads/x/arduino-1.8.2/hardware/tools/avr/etc/avrdude.conf -v -patmega32u4 -cavr109 -P/dev/ttyACM0 -b57600 -D -Uflash:w:/tmp/arduino_build_466848/Blink.ino.hex:i 

The Arduino bootloader is only active for a short period after a reset. You can force that by toggling one of the tty control lines, which is what the various loaders do before running avrdude.

For real arduino’s, hitting the reset button works fine. The Arduboy doesn’t have a reset button, so you have to power cycle - which also causes the USB devices to be reset, which can cause the serial port to change if the PC doesn’t shut down the old device before the new one is set up.

Personally, I power off the Arduboy, set up the command line, make sure the old serial device is gone, power on the arduboy and hit enter. That works pretty reliably for me.

That’s what the verbose output gives.

I’ve tried with both the avrdude.exe the Arduino IDE uses in AppData and the avrdude.exe that comes bundled with the Arduino IDE.
(I suspect it’s just copying that one into AppData anyway, or something obscure. The Arduino IDE seems to use AppData as scratch space.)

Actually, it does.

And I’m glad you mentioned it because it seems using the reset button with proper timing got avrdude to work. Seems doing it too much in quick succession does leave the old COM port occupied, but it’s pretty predictable. On my computer at least, the Arduboy only ever occupies one of two COM ports.

It seems that setting up the command line, resetting the arduboy and then pressing enter does the trick (assuming the COM port is right).
It works for both the version bundled with the IDE and the one living in AppData.

I suspect the process on a Mac will be much the same.

Ah, so Windows apparently expands this stuff after the invocation instead of before. But I didn’t have the verbose output to look at.

It should be searching them in order, which - if you’ve got nothing else plugged in - means you get the first one, and sometimes the second one. The Mac tends to use long messy names; both my Arduboy and Leonardo show up as /dev/tty.usbmodemFD131; if I plug them both in at the same time the second one becomes /dev/tty.usbmodemFA121. Not sure what’s going on there.

BTW, another - possibly easier, depending on how hard it is to find the arduino command - way to get the command line if you’ve got Arduino installed is to run “arduino --upload --board arduino:avr:leonardo --verbose --port” followed by the serial port and a .ino file. Unfortunately, the command line doesn’t support just uploading a .hex file.

I think the IDE is purposely feeding it an absolute path, if it was splatting the %APPDATA% environment variable into the command line I think it would show up as %APPDATA% in the verbose output (I think, %APPDATA% is not exactly something I have to deal with often). I can’t be bothered to check the IDE’s source code to find out what’s actually happening. Whichever way round it is, the result is the same.

Theoretically, but if that is the case I don’t know what happened to COM1, COM2 and COM3 because they never get used by the Arduboy and they don’t register as being in use by anything else.

Good to know. I won’t add it to the list as this thread is aimed at specifically uploading .hex files. If there’s ever a thread on performing command line magic though, that’ll be a good one to bring up.

Or anything else, for that matter. I think it’s a compatibility thing - pretty much every early PC I used had COM1 & COM2 as motherboard serial, and COM3 as a modem. I recall cursing at DOS software that assumed that the first free COM port was COM4 on systems that had more than those 3 in them. Possibly those are still reserved for specific hardware ports, so not available virtual serial ports. MS has always been careful about backwards compatibility.

Closing then opening the port specifically at 1200 baud is what triggers USB based Arduinos to jump into the bootloader and await commands (normally to do an upload). (In actual fact, the Arduino is looking for the port to be set to 1200 baud and the DTR signal to be toggled.)

So yes, you have to reset the Arduboy by doing the above before you can use avrdude to perform an upload. Otherwise you have to manually reset the Arduboy using the reset button.

DTR is not relevant for Arduboy (and Leonardo, Micro and Pro Micro). Opening and closing a com port at 1200 baud is what resets it and causes the arduino to go into bootloader mode.

The com port also changes in bootloader mode on Windows (usually one port lower then in normal mode). This is because the bootloader uses a different USB VID (Vendor ID) and PID (Product ID) combo then in normal mode. (Windows registers and reserves a com port for a newly connected USB serial device based on its VID PID combo)

1 Like

And what exactly is meant by “opening and closing” a serial port? It’s normally DTR being active or inactive that indicates a port is open or closed. That’s what the Arduino USB code looks for. See Arduino core file CDC.cpp

Not under Linux. On my Ubuntu system the port stays on /dev/ttyACM0 both before and after the reset.

Forcing reset using 1200bps open/close on port /dev/ttyACM0
PORTS {/dev/ttyACM0, /dev/ttyS0, } / {/dev/ttyS0, } => {}
PORTS {/dev/ttyS0, } / {/dev/ttyS0, } => {}
PORTS {/dev/ttyS0, } / {/dev/ttyACM0, /dev/ttyS0, } => {/dev/ttyACM0, }
Found upload port: /dev/ttyACM0
/opt/arduino-1.8.4/hardware/tools/avr/bin/avrdude -C/opt/arduino-1.8.4/hardware/tools/avr/etc /avrdude.conf -v -patmega32u4 -cavr109 -P/dev/ttyACM0 -b57600 -D -Uflash:w:/tmp/arduino_build_999423/MYBL_AB.ino.hex:i