Avrdude error programmer did not respond to command exit bootloader

dda

5,9322 gold badges25 silver badges34 bronze badges

Jan ČernýJan Černý

1,2042 gold badges18 silver badges31 bronze badges

Detecting USB port, reset your controller now........
Device /dev/tty.usbmodem14601 has appeared; assuming it is the controller.
Waiting for /dev/tty.usbmodem14601 to become writable.

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

avrdude: ser_recv(): read error: Device not configured
avrdude: butterfly_recv(): programmer is not responding
avrdude: ser_drain(): read error: Device not configured
avrdude: ser_send(): write error: Device not configured
avrdude: ser_recv(): read error: Device not configured
avrdude: butterfly_recv(): programmer is not responding
avrdude: ser_send(): write error: Device not configured
avrdude: ser_recv(): read error: Device not configured
avrdude: butterfly_recv(): programmer is not responding
avrdude: ser_recv(): read error: Device not configured
avrdude: butterfly_recv(): programmer is not responding
avrdude: ser_send(): write error: Device not configured
avrdude: ser_recv(): read error: Device not configured
avrdude: butterfly_recv(): programmer is not responding
Found programmer: Id = ""; type =
    Software Version = .; Hardware Version = .
avrdude: ser_send(): write error: Device not configured
avrdude: ser_recv(): read error: Device not configured
avrdude: butterfly_recv(): programmer is not responding
avrdude: ser_send(): write error: Device not configured
avrdude: ser_recv(): read error: Device not configured
avrdude: butterfly_recv(): programmer is not responding
avrdude: error: buffered memory access not supported. Maybe it isn't
a butterfly/AVR109 but a AVR910 device?
avrdude: initialization failed, rc=-1
         Double check connections and try again, or use -F to override
         this check.

avrdude: ser_send(): write error: Device not configured
avrdude: ser_recv(): read error: Device not configured
avrdude: butterfly_recv(): programmer is not responding
avrdude: error: programmer did not respond to command: leave prog mode
avrdude: ser_send(): write error: Device not configured
avrdude: ser_recv(): read error: Device not configured
avrdude: butterfly_recv(): programmer is not responding
avrdude: error: programmer did not respond to command: exit bootloader
avrdude: ser_close(): can't reset attributes for device: Device not configured

avrdude done.  Thank you.

make[1]: *** [avrdude] Error 1
make: *** [contra:sirovia:avrdude] Error 1

Could you please post the output of the avrdude command, but with -vv?

Copy link

Contributor

Author

Do you also see a /dev/tty.usbmodem14501? If so, does that work instead?

Copy link

Contributor

Author

Can you flash it on a different device?

Copy link

Contributor

Author

Sorry, I mean on a different host computer.

The fc660c is using DFU, not caterina/avrdude, so it’s a very different ballpark.

Also, i may be worth running ls /dev/tty.usb* to get a list of devices. Which would check to see which COM ports are active.

Also, it may be that the controller is soft bricked. And if it is, you’ll need to ISP Flash the bootloader.
And in that case, you want to take a look at this link: https://docs.qmk.fm/#/isp_flashing_guide
And if you do end up doing that, you may want to look at this link (to replace the bootloader with something a LOT more sane): https://www.reddit.com/r/olkb/comments/8sxgzb/replace_pro_micro_bootloader_with_qmk_dfu/

Copy link

Contributor

Author

I meant on the Toolbox repo 😉 but in any case, I can tell from a quick glance at that crash log what the problem is, and I should have picked up on it when you mentioned the DZ60RGB. See qmk/qmk_toolbox#84 (comment)

Copy link

Contributor

Author

Don’t know why I didn’t think of this before, but does running avrdude with sudo have any effect?

Copy link

Contributor

Author

@sidcarter were you able to fix for the command line?

Copy link

Contributor

Author

Any update on this? Or a workaround for the new beta?

Copy link

Contributor

Author

Bummer. — I tried to flash an avrdude the other day to no avail. I will try to find a workaround 👍

From what I understand, this may actually be a bug in Catalina, specifically. Not sure there is a workaround. At least at this point.

Still need to be fixed.
Here’s what I got from the last version of Catalina.

Caterina device connected
*** Attempting to flash, please don’t remove device
Found port: /dev/cu.usbmodem14301

avrdude -p atmega32u4 -c avr109 -U flash:w:/Users/silviogulizia/Downloads/contra_default_EA425786.hex:i -P /dev/cu.usbmodem14301 -C avrdude.conf
avrdude: warning at avrdude.conf:14976: part atmega32u4 overwrites previous definition avrdude.conf:11487.

Connecting to programmer: .avrdude: butterfly_recv(): programmer is not responding
*** Caterina device disconnected

I’m also having this issue on Catalina latest beta, having to flash using another machine for now 😢

Doing some initial investigation into the issue, it looks like the reset of the MCU (using the 1200 baud toggle method) that’s done before flashing isn’t working properly on Catalina. If trying to do stty -f /dev/cu.usbmodemXXX 1200, this error shows up in dmesg on Catalina beta only: mctl RS232_S_OUTPUTS failed e0005000.

Testing method:

1. Press hardware reset button (or short RST and GND) on Pro Micro
2. Run stty -f /dev/cu.usbmodemXXX 1200
3. Run sudo dmesg and observe mctl RS232_S_OUTPUTS failed error

The error is also observed when avrdude is run, presumably because it also tries doing the 1200 baud toggle to reset the MCU.

Further testing with Arduino IDE and stock Pro Micro also had the same problem on Catalina.

Apple doesn’t test anything that slow probably. Since this breaks Arduino IDE, I would except their much larger community to kick up a fuss.

Hey guys, just out of curiosity, when I upgrade to Catalina, will it work with docker or a vm solution such as Virtualbox? This issue is simply preventing me to upgrade.

@lattedesu I don’t know about Docker, but you can definitely use Windows or Linux on Virtualbox and pass through the bootloader device in order to flash

This only applies to the Caterina bootloader (Pro Micro, Arduino, etc), and possibly Massdrop boards as the ATSAM bootloader also appears as a serial port. dfu-programmer, dfu-util and teensyloader all seem to work fine.

Any updates on this??? Just updated from mojave to catalina yesterday and instantly noticed it broke avrdude flashing with caterina bootloaders. The device reset still works fine and port is changed/available from dev/cu.usbmodem.C1 to /dev/cu.usbmodem14011 after reset. But avrdude indeed can’t communicate with the bootloader -> basically ser_receive/ser_send is broken. It’s not an avr-gcc issue as compiling works fine and produces a .hex that is usuable when flashing with other methods(external programmer for instance). It’s purely a communication issue introduced on MacOs Catalina between avrdude and the caterina cdc bootloader (used on various arduino leonardos and clones). Mojave and any older os x (Sierra, High Sierra etc,) all work fine.

Als serial comms to regular sketch code still works fine. It’s only when in bootloader that serial communication is failing here.

More info. Suspecting that vdc assistant on mac os catelina that’s interfering with the communication. This background service tries to detect the arduino as a usb camera (and is sending most likely garbage on the serial that crashes the bootloader) and therefore messes up the communication with avrdude. When arduino leonardo enters bootloader in console log there are these errors popping up :
CMIO_DPA_VDC_Server_Assistant.cpp:1383:GetDeviceByGUID No match for specified GUID 0x1420000023418036

DeviceArrived caught an exception from determining the deviceType (0xffffffffffffffff) or removing the device

CMIO_DPA_VDC_Server_USBClient.cpp:334:USBClient [guid:0x1420000023418036] Could not find SC_VIDEOCONTROL interface

DeviceArrived Found a camera (0x1420000023418036) , but was not able to start it up (0x0 — (os/kern) successful)

Ok : UPDATE this is not the issue, nothing is fixed when stopping VDC Assistant. So bug must be elsewhere.

sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.cmio.VDCAssistant.plist

After stopping it same bug is still happening avrdude: butterfly_recv(): programmer is not responding
Found programmer: Id = «»; type =
Software Version = .; Hardware Version = .

I see that the bootloader crashes though as ours does some special led blinking on different steps and that is also disrupted on macos catalina.

Today big +900Mb update on Catalina, installed it. But still no dice, same issue remains with avrdude being broken here. Also noticed other broken things for instance the mini display ports no longer support higher 4k resolutions anymore. So apart from 32bit a whole other range of stuff got broken on Catalina (really regret this upgrade so far…). To others as advice: for now stick with Mojave its more stable / less bugs.

I have just sent a feedback to Apple via https://feedbackassistant.apple.com/ , regarding this issue. I wonder if anything would turn up, but I hope someone at Apple addresses this.

I can confirm flashing works on VirtualBox which is installed over Catalina. I’ve tried with Ubuntu 16.04 which was already installed, but I’m sure it’ll work on 18.04 or newer non-lts versions. I was tired as hell to compile the hex file on mac and then flash it on Windows. I’ve tried with a vagrant box which I had installed already for a local environment of another project.

You have to install the VirtualBox extension pack (you can find it on downloads page of Virtualbox) for USB support, and then you have to enable USB forwarding. I’ve enabled USB 2.0. Shut down the vm, at the settings page of the vm, go to USB settings, quickly set the keyboard at bootloader mode (short the reset pin), and click the green plus arrow at the right section (add a device icon). You’ll see the Arduino (or whatever it’s shown for your case) on USB devices list. Set it, save it and boot the virtual machine.

To test that USB works, while inside the vm (you can ssh or whatever), set your keyboard at bootloader mode again (short the reset pin), and type lsusb while at the bootloader mode. If you see Arduino device at the USB devices list while the device is at bootloader mode, you’re good to go.

Just a thing, my default vagrant user didn’t have serial port write access through USB, so I had to run the command as superuser, something like sudo make keyboard:layout:avrdude to circumvent this.

In my case，I have successfully flush the firmware by using Vagrant + VirtualBox on macOS Catalina.
My environment is as follows.

• macOS Catalina 10.15
• Homebrew 2.1.15
• avrdude version 6.3
• Vagrant 2.2.5
  • vagrant-vbguest 0.20.0
• VirtualBox 6.0.14r133895
  • VirtualBox Extension Pack 6.0.14

VirtualBox extension pack is required to use USB device on guest OS. I use following Vagrantfile.

# -*- mode: ruby -*-
# vi: set ft=ruby :
Vagrant.configure("2") do |config|

  config.vm.box = "hashicorp/bionic64"
  config.vm.provider "virtualbox" do |v|
    v.name = "VM to flash firmware into ProMicro"
    v.customize ["modifyvm", :id, "--usb", "on"]
    v.customize ["modifyvm", :id, "--usbehci", "on"]
    # Please rewrite according to your environment. VID/PID is required.
    v.customize ["usbfilter", "add", "0",
                 "--target", :id,
                 "--name", "Arduino Micro (writable)",
                 "--vendorid", "2341",
                 "--productid", "0037",
                 "--remote", "no"]
    v.customize ["usbfilter", "add", "1",
                 "--target", :id,
                 "--name", "Arduino Micro",
                 "--vendorid", "2341",
                 "--productid", "8037",
                 "--remote", "no"]
  end

  # I used local qmk_firmware repository.
  # Please rewrite according to your environment.
  config.vm.synced_folder "/Users/username/qmk_firmware", "/qmk_firmware"
  config.vbguest.auto_update = true

  # Install build tools
  config.vm.provision "shell", privileged: false, inline: <<-SHELL 
    sudo apt-get update
    sudo apt-get install -y python3-pip avrdude
    /qmk_firmware/util/qmk_install.sh
   SHELL
end

The procedure is as follows.

1. Install Vagrant and VirtualBox and Extension pack
2. Install vagrant plugin (vagrant plugin install vagrant-vbguest)
3. Update Guest additions (vagrant vbguest)
4. Confirm the VID/PID of your device (VBoxManage list usbhost)
   • In bootloader mode, the VID/PID will change. You should confirm it too.
5. Write Vagrantfile (I restarted my Mac after this）
6. Unplug the USB device
7. Launch VM (vagrant up) and SSH into it (vagrant ssh)
8. Plug the USB device
9. Build your firmware (cd /qmk_firmware && make KEYBOARD:KEYMAP:avrdude)
10. Short the reset pin if the command require to reset the device.

I was able to flush the firmware this way, but the procedure may be inaccurate

Had my fingers crossed that this would be fixed in 10.15.1, but alas… Will have to continue hoping for change. In the meanwhile, gonna use a spare RPI for QMK flashing purposes.

In my case，I have successfully flush the firmware by using Vagrant + VirtualBox on macOS Catalina.
My environment is as follows.

• macOS Catalina 10.15

• Homebrew 2.1.15

• avrdude version 6.3

• Vagrant 2.2.5

  • vagrant-vbguest 0.20.0

• VirtualBox 6.0.14r133895

  • VirtualBox Extension Pack 6.0.14

VirtualBox extension pack is required to use USB device on guest OS. I use following Vagrantfile.

# -*- mode: ruby -*-
# vi: set ft=ruby :
Vagrant.configure("2") do |config|

  config.vm.box = "hashicorp/bionic64"
  config.vm.provider "virtualbox" do |v|
    v.name = "VM to flash firmware into ProMicro"
    v.customize ["modifyvm", :id, "--usb", "on"]
    v.customize ["modifyvm", :id, "--usbehci", "on"]
    # Please rewrite according to your environment. VID/PID is required.
    v.customize ["usbfilter", "add", "0",
                 "--target", :id,
                 "--name", "Arduino Micro (writable)",
                 "--vendorid", "2341",
                 "--productid", "0037",
                 "--remote", "no"]
    v.customize ["usbfilter", "add", "1",
                 "--target", :id,
                 "--name", "Arduino Micro",
                 "--vendorid", "2341",
                 "--productid", "8037",
                 "--remote", "no"]
  end

  # I used local qmk_firmware repository.
  # Please rewrite according to your environment.
  config.vm.synced_folder "/Users/username/qmk_firmware", "/qmk_firmware"
  config.vbguest.auto_update = true

  # Install build tools
  config.vm.provision "shell", privileged: false, inline: <<-SHELL 
    sudo apt-get update
    sudo apt-get install -y python3-pip avrdude
    /qmk_firmware/util/qmk_install.sh
   SHELL
end

The procedure is as follows.

1. Install Vagrant and VirtualBox and Extension pack

2. Install vagrant plugin (vagrant plugin install vagrant-vbguest)

3. Update Guest additions (vagrant vbguest)

4. Confirm the VID/PID of your device (VBoxManage list usbhost)

   • In bootloader mode, the VID/PID will change. You should confirm it too.

5. Write Vagrantfile (I restarted my Mac after this）

6. Unplug the USB device

7. Launch VM (vagrant up) and SSH into it (vagrant ssh)

8. Plug the USB device

9. Build your firmware (cd /qmk_firmware && make KEYBOARD:KEYMAP:avrdude)

10. Short the reset pin if the command require to reset the device.

I was able to flush the firmware this way, but the procedure may be inaccurate

This worked for me with a few adjustments and clarifications:

• the «writable» arduino needs the PID/VID from the pro-micro in reset mode and the second is your normally running pro-micro (when attached as a keyboard)
• run vagrant up before you run vagrant vbguest
• your keyboard won’t work while the vagrant box is up as this filters the USB device through it, so be ready to use another keyboard (at least this was my experience)

Great work and thank you for making this so easy!

For vagrant, add the USB device while the keyboard is at the reset mode. Think like your keyboard is made of two devices. This way, in normal mode, it’ll work as any keyboard from your main OS, and will be forwarded to virtual machine only when the device is at bootloader mode (reset pin is pressed).

Also, I had a vagrant-puppet-virtualbox combo for another project which I’ve installed QMK over and flashed firmware various times, never had a need to type the product id or vendor id etc. .

Been struggling with this for two or three evenings now. I’m able to build firmware using the Vagrantfile included with the QMK repo. I’ve updated the VID and PID of my Pro Micro both in normal mode and again in bootloader/reset mode. I thought I had it. I got the prompt to reset controller, but then got Device /dev/ttyACM0 has appeared; assuming it is the controller after shorting my reset pins. Additional resets do not help. It’s just waiting. I’m new to all this. Any help? @pddg @tomwinget

vagrant@debian9:/vagrant$ make dpickett40:default:avrdude
QMK Firmware 0.7.75
Making dpickett40 with keymap default and target avrdude

avr-gcc (GCC) 4.9.2
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Size before:
   text	   data	    bss	    dec	    hex	filename
      0	  18916	      0	  18916	   49e4	.build/dpickett40_default.hex

Copying dpickett40_default.hex to qmk_firmware folder                                               [OK]
Checking file size of dpickett40_default.hex                                                        [OK]
 * The firmware size is fine - 18916/28672 (65%, 9756 bytes free)
Detecting USB port, reset your controller now..............................
Device /dev/ttyACM0 has appeared; assuming it is the controller.
Waiting for /dev/ttyACM0 to become writable.....................................................................................................................................................................................................................................................

Been struggling with this for two or three evenings now. I’m able to build firmware using the Vagrantfile included with the QMK repo. I’ve updated the VID and PID of my Pro Micro both in normal mode and again in bootloader/reset mode. I thought I had it. I got the prompt to reset controller, but then got Device /dev/ttyACM0 has appeared; assuming it is the controller after shorting my reset pins. Additional resets do not help. It’s just waiting. I’m new to all this. Any help? @pddg @tomwinget

vagrant@debian9:/vagrant$ make dpickett40:default:avrdude
QMK Firmware 0.7.75
Making dpickett40 with keymap default and target avrdude

avr-gcc (GCC) 4.9.2
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Size before:
   text	   data	    bss	    dec	    hex	filename
      0	  18916	      0	  18916	   49e4	.build/dpickett40_default.hex

Copying dpickett40_default.hex to qmk_firmware folder                                               [OK]
Checking file size of dpickett40_default.hex                                                        [OK]
 * The firmware size is fine - 18916/28672 (65%, 9756 bytes free)
Detecting USB port, reset your controller now..............................
Device /dev/ttyACM0 has appeared; assuming it is the controller.
Waiting for /dev/ttyACM0 to become writable.....................................................................................................................................................................................................................................................

Try running the make command with sudo, I had the same problem but that fixed it for me.

Yay!! I just flashed my keyboard on Catalina! @tomwinget, you are the best. I was afraid I was going to have to downgrade macOS.

Apparently I also did not have arvdude installed in the VirtualBox, but was able to solve that with sudo apt-get install avrdude.

Running the command as superuser helps, because the vagrant user doesn’t have serial port access as mentioned. Also, my ancient netbook (Intel Atom CPU, 2gb RAM, Lubuntu 18.04 installed) had the same issue, because it was so slow it couldn’t start uploading in 8 seconds 🤷‍♂

I tried the vagrant thing, but it didnt work for me with my iris. i could compile etc but when it was waiting, i presset reset and it just kept waiting..

Do we actually know if the fault is something with catalina or with avrdude or with pro micro?

@pvinis As mentioned, you both need to add the keyboard while it’s at reset mode from vagrant menu, or if you did that already, you also need to run the command as superuser (add sudo before command). I had to do both to successfully install the firmware. Simply adding the device while it’s in normal mode from vagrant menu didn’t work for me. Please see my comment on october 19th.

I had both there. I did it again today with sudo and it worked. Also, I noticed that what you said about the keyboard not working while it’s connected to vagrant. Yesterday it was still working, and I couldn’t flash it. Today it was not working and I could finally flash. Thanks. Hopefully the bug will be fixed soon, wherever it is.

Tested with recent 10.15.2 beta 4 released a few days ago, looks like things are working again, so looking hopeful for when normal 10.15.2 is released

Great to hear that @nooges, I’ve sadly failed with vagrant config and lost all hope until now. Great work all

10.15.2 officially released now, tested on there and all good now.

Had the same issue with Qmk_Toolbox on Catalina 10.15.2 for a romac 2.1 (atmel mega32u4), I finally tested with the command line «make kingly_keys/romac:custom:flash» of qmk_firmware and it worked all fine.

Another data point. On Mojave 10.14.6, I had the same issue being unable to flash a Pro Micro using QMK Toolbox and avrdude. Setting the serial port to 1200 baud before flashing with avrdude solved my problem. The serial port showed up as /dev/cu.usbmodem142201 on my Macbook Air.