Bricked boards when programming 32u4 Micro boards under Linux

I recently started porting a project that I'm working on from the 328p to the 32u4 MCU. I usually work on Linux Mint (version 19.2) and have been using Arduino IDE 1.8.9. The hardware I am using for this work is the Arduino Micro board.

One of the difficulties that I have had with this board is that every time I tried to upload a sketch to it using the serial port (/dev/ttyACM0), the board would get bricked. I was able to rescue the board by using an AVR programmer to burn a bootloader to it, again using the option within the IDE. I'm not using any special bootloader here, just what comes as standard with the Arduino IDE. Since this tiny board does not have a suitable SPI header, this was not particularly convenient and required soldering wires to the appropriate GPIO pins. Since I hadn't been able to get around this problem, I left the wires attached and I started using the IDE option to export the compiled binary and then using the AVR programmer to upload the version with the bootloader to the Micro. This, at least, allowed me to continue working on the project.

One thing I hadn't tried - until today - was to upload the sketch using the Windows version. It turns out that the process works just fine in Windows. I tried both IDE version 1.8.8 and 1.8.10. I then went back to Linux and tried version 1.8.10 there, but the result was a bricked board again. Re-booting back into Windows, I burned the bootloader and the sketch uploaded fine again.

Clearly, there is a problem uploading sketches to 32u4 boards when using Arduino IDE under Linux. Up until now I had been using Uno, Nano and Mega 2560 boards and never encountered a problem.

Can anyone advise what the problem might be and how to report it to the developers? I do notice that in Windows, when the board is connected, it comes up in device manager as COM19, but after a few seconds this changes to COM20. When programming, the reverse is true. The port changes to COM19 and then back again to COM20 when the process is complete. On Linux the port seems to stay as /dev/ttyACM0. The only time I have seen it change to /dev/ttyACM1 is when the Serial Monitor has been left open keeping /dev/ttyACM0 busy.

Please disable 'verbose output during compilation' in file->preferences and enable 'verbose output during upload'.

Post the output of the normal upload (for your linux system) here. Although I know what it should look like for Windows, others might not so post that as well. I (or somebody else) might be able to determine what what is going on.

Any pointers in the linux tools (e.g. dmesg)? I haven't used linux for a long time so not sure which other commands can be useful.

Reporting issues should be done on github; not exactly sure which section.

PS
for the Pro Micro, double tapping the reset button (I know, adding extra wires) might help.

Thank you for the reply. I can confirm that 'verbose output during compilation' is turned off.

As for the normal upload, below is thew output of the 'bricking' process:

Status of USB and serial port with connected 32u4 Micro board:

$ lsusb
Bus 002 Device 007: ID 2341:8037 Arduino SA
Bus 002 Device 006: ID 413c:2010 Dell Computer Corp. Keyboard
Bus 002 Device 004: ID 413c:1003 Dell Computer Corp. Keyboard Hub
Bus 002 Device 003: ID 046d:c03d Logitech, Inc. M-BT96a Pilot Optical Mouse
Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

$ ls /dev/ttyA*
/dev/ttyACM0

The test sketch that I am uploading:

void setup() {
  // put your setup code here, to run once:
  Serial.begin(115200);

}

void loop() {
  // put your main code here, to run repeatedly:
  Serial.println("Hello :-)");
  delay(1000);
}

Error messages from the IDE (I have removed excessive '***failed;' and some repeated iterations of messages but left the substance) :

Arduino: 1.8.9 (Linux), Board: "Arduino/Genuino Micro"

Sketch uses 3598 bytes (12%) of program storage space. Maximum is 28672 bytes.
Global variables use 161 bytes (6%) of dynamic memory, leaving 2399 bytes for local variables. Maximum is 2560 bytes.


avrdude: butterfly_recv(): programmer is not responding
avrdude: error: programmer did not respond to command: write block
 ***failed;  
 .....
 ***failed;  
avrdude: Error: butterfly programmer uses avr_write_page() but does not
provide a cmd() method.
 *** page 127 (addresses 0x0000 - 0x007f) failed to write

 ***failed;  
.....
 ***failed;  
avrdude: Error: butterfly programmer uses avr_write_page() but does not
provide a cmd() method.
 *** page 127 (addresses 0x0080 - 0x00ff) failed to write

 ***failed;  
.....
 ***failed;  
avrdude: Error: butterfly programmer uses avr_write_page() but does not
provide a cmd() method.
 *** page 127 (addresses 0x0100 - 0x017f) failed to write

 ***failed;  
.....
 ***failed;  
avrdude: Error: butterfly programmer uses avr_write_page() but does not
provide a cmd() method.
 *** page 127 (addresses 0x0180 - 0x01ff) failed to write

 ***failed;  
.....
 ***failed;  
avrdude: Error: butterfly programmer uses avr_write_page() but does not
provide a cmd() method.
 *** page 127 (addresses 0x0200 - 0x027f) failed to write

 ***failed;  
.....
 ***failed;  
avrdude: Error: butterfly programmer uses avr_write_page() but does not
provide a cmd() method.
 *** page 127 (addresses 0x0280 - 0x02ff) failed to write

 ***failed;  
.....
 ***failed;  
avrdude: Error: butterfly programmer uses avr_write_page() but does not
provide a cmd() method.
 *** page 127 (addresses 0x0300 - 0x037f) failed to write

 ***failed;  
.....
 ***failed;  
avrdude: Error: butterfly programmer uses avr_write_page() but does not
provide a cmd() method.
 *** page 127 (addresses 0x0380 - 0x03ff) failed to write

 ***failed;  
.....
 ***failed;  
avrdude: Error: butterfly programmer uses avr_write_page() but does not
provide a cmd() method.
 *** page 127 (addresses 0x0400 - 0x047f) failed to write

 ***failed;  
.....
 ***failed;  
avrdude: Error: butterfly programmer uses avr_write_page() but does not
provide a cmd() method.
 *** page 127 (addresses 0x0480 - 0x04ff) failed to write

 ***failed;  
.....
 ***failed;  
avrdude: Error: butterfly programmer uses avr_write_page() but does not
provide a cmd() method.
 *** page 127 (addresses 0x0500 - 0x057f) failed to write

 ***failed;  
.....
 ***failed;  

.....

 ***failed;  
 ***failed;  
avrdude: Error: butterfly programmer uses avr_write_page() but does not
provide a cmd() method.
 *** page 13 (addresses 0x0d8e - 0x0e0d) failed to write

avrdude: butterfly_recv(): programmer is not responding
avrdude: butterfly_recv(): programmer is not responding
avrdude: verification error, first mismatch at byte 0x002a
         0x2b != 0x75
avrdude: verification error; content mismatch
avrdude: verification error; content mismatch

This report would have more information with
"Show verbose output during compilation"
option enabled in File -> Preferences.

Status of USB and serial port after the bricking:

$ lsusb
Bus 002 Device 006: ID 413c:2010 Dell Computer Corp. Keyboard
Bus 002 Device 004: ID 413c:1003 Dell Computer Corp. Keyboard Hub
Bus 002 Device 003: ID 046d:c03d Logitech, Inc. M-BT96a Pilot Optical Mouse
Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

$ ls /dev/ttyA*
ls: cannot access '/dev/ttyA*': No such file or directory

After programming, the board is no longer detected and a serial port is not assigned, rendering it inaccessible. I will now have to recover it again with using the AVR programmer.

I should also point out that I have tried different USB cables and these same USB cables work fine when programming using the IDE on Windows.

The board is connected directly to the USB port on the PC and not via a USB hub.

I don't think that I can solve this one.

Any pointers in dmesg?
I assume that you have tried to disconnect/connect the bricked pro micro and see what happens.

//Edit
I think that you're using a (Sparkfun) Pro Micro and not an Arduino Micro; the latter actually has a SPI header :wink:

//Another edit
Maybe Arduino/ProMicro — Tech Note Wiki might be of use?

Thank you for trying to help. It is appreciated.

I did have a look at dmesg. If I plug in the bricked board, I get no indication of anything happening at all. Its just like I haven't plugged anything in at all.

If I plug in a working (i.e. non-bricked) board, dmesg shows this, which looks quite normal:

[ 9814.612456] usb 2-1.6: new full-speed USB device number 6 using ehci-pci
[ 9814.723983] usb 2-1.6: New USB device found, idVendor=2341, idProduct=8037, bcdDevice= 1.00
[ 9814.723986] usb 2-1.6: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 9814.723989] usb 2-1.6: Product: Arduino Micro
[ 9814.723991] usb 2-1.6: Manufacturer: Arduino LLC
[ 9814.761450] cdc_acm 2-1.6:1.0: ttyACM0: USB ACM device
[ 9814.761754] usbcore: registered new interface driver cdc_acm
[ 9814.761755] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters

Thank you for pointing out the distinction between the Arduino and Sparkfun versions of the board. You are correct, this one more closely resembles the Sparkfun design.

The problem now seems to be solved.

Firstly it turns out that mangled board does come up as /dev/ttyACM0 but only for about 8 seconds and then disappears. During this time I was able to observe the following output in dmesg:

[  413.384345] usb 2-1.6: Product: Arduino Micro   
[  413.384348] usb 2-1.6: Manufacturer: Arduino LLC
[  413.384865] cdc_acm 2-1.6:1.0: ttyACM0: USB ACM device
[  420.989299] usb 2-1.6: USB disconnect, device number 16
[  421.221044] usb 2-1.6: new full-speed USB device number 17 using ehci-pci
[  421.301003] usb 2-1.6: device descriptor read/64, error -32
[  421.488971] usb 2-1.6: device descriptor read/64, error -32
[  421.680942] usb 2-1.6: new full-speed USB device number 18 using ehci-pci
[  421.760931] usb 2-1.6: device descriptor read/64, error -32
[  421.948919] usb 2-1.6: device descriptor read/64, error -32
[  422.057052] usb 2-1-port6: attempt power cycle
[  422.660777] usb 2-1.6: new full-speed USB device number 19 using ehci-pci
[  423.076714] usb 2-1.6: device not accepting address 19, error -32
[  423.156712] usb 2-1.6: new full-speed USB device number 20 using ehci-pci
[  423.572654] usb 2-1.6: device not accepting address 20, error -32
[  423.572806] usb 2-1-port6: unable to enumerate USB device

I raised an issue on the Arduino GitHub. There I was advised to have a look at ModemManager. I was not aware of this service but found that it was running, evidently by default, on my computer. Since there are no modems of any kind connected to this machine, I stopped and disabled the service. The board was then recovered using the AVR programmer and the upload re-tried. This time it succeeded. I tried it a couple of times more and it worked each time consistently. Evidently, then, the ModemManager service was interfering with the upload process. Hopefully this will mean trouble-free uploading from now on!

sterretje, thank you for your feedback.

Good luck.

The 8 seconds is normal, at least with a Leonardo. As you discovered under Windows, there are two ports. A 'normal' serial port and an upload port.

I don't think that the Pro Micro behaves exactly like the Leonardo but this is the Leonardo
1)
Power on will take you straight to the application and the 'normal' serial port will be available.
2)
Any form of (other) reset (reset button, opening and closing the 'normal' serial port with 1200 baud) will reset the board and start the boot-loader and you will get the uploader port.

328u4 is what we said SAM D12 type its different then UNO or Nano mcu. I found the new IDE not working well and the symptom was the same as you say. I tried couple leonardo it's killed the comm port after I uploaded something. I use 1.6.x the problem solved