Bootloarder 'gone' - happened twice in a few days

Hello

I have run into the same problem twice now in a few days. Once with an STM32F103 board and once with a genuine micro. Initially the boards work fine, I can upload sketches etc and then for no reason I can explain the board no longer connects (tried Windows, Mac and Linux). The last sketch uploaded is still working so I guess the board is ok but somehow the usb connection with the device fails.

Does anyone have any idea how I manage to get myself in this mess? The procedures I found to reset the bootloader are a bit above me I am afraid so I will soon get a 3rd board. In that context I would really like to avoid the same mistake but I have no idea what that mistake is. So, all tips welcome!

Many thanks!

Peter

PS The Linux system log is as follows

Dec 24 15:01:32 pclap kernel: [31669.550274] usb 1-1: new full-speed USB device number 59 using xhci_hcd
Dec 24 15:01:32 pclap kernel: [31669.700528] usb 1-1: New USB device found, idVendor=2341, idProduct=0037, bcdDevice= 0.01
Dec 24 15:01:32 pclap kernel: [31669.700534] usb 1-1: New USB device strings: Mfr=2, Product=1, SerialNumber=0
Dec 24 15:01:32 pclap kernel: [31669.700537] usb 1-1: Product: Arduino Micro   
Dec 24 15:01:32 pclap kernel: [31669.700540] usb 1-1: Manufacturer: Arduino LLC
Dec 24 15:01:32 pclap kernel: [31669.704884] cdc_acm 1-1:1.0: ttyACM0: USB ACM device
Dec 24 15:01:32 pclap mtp-probe: checking bus 1, device 59: "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-1"
Dec 24 15:01:32 pclap mtp-probe: bus: 1, device: 59 was not an MTP device
Dec 24 15:01:32 pclap snapd[992]: hotplug.go:199: hotplug device add event ignored, enable experimental.hotplug
Dec 24 15:01:32 pclap upowerd[1331]: unhandled action 'bind' on /sys/devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1:1.1
Dec 24 15:01:32 pclap upowerd[1331]: unhandled action 'bind' on /sys/devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1:1.0
Dec 24 15:01:32 pclap upowerd[1331]: unhandled action 'bind' on /sys/devices/pci0000:00/0000:00:14.0/usb1/1-1
Dec 24 15:01:39 pclap kernel: [31677.314421] usb 1-1: USB disconnect, device number 59
Dec 24 15:01:39 pclap upowerd[1331]: unhandled action 'unbind' on /sys/devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1:1.1
Dec 24 15:01:39 pclap upowerd[1331]: unhandled action 'unbind' on /sys/devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1:1.0
Dec 24 15:01:39 pclap upowerd[1331]: unhandled action 'unbind' on /sys/devices/pci0000:00/0000:00:14.0/usb1/1-1

I don't know anything about the STM boards, but on the Micro, your sketch code can break, suspend, or override the lower level USB CDC serial port code. This could be caused by a bug in the code, or just be a normal part of how the code works. For example, if your sketch puts the microcontroller to sleep, then it can't run the USB code. In this case, you should find that the problem goes away when you upload a simple known-safe sketch like the bare minimum one you get from File > New.

Of course, it's tricky to do an upload when there is no longer a port, but you can recover the board by manually resetting it when the upload starts. The thing to note is that the Arduino IDE always compiles before upload, so if you reset the board immediately after pressing the "Upload" button, the bootloader will have timed out before the compilation finishes and the actual upload begins. Instead, wait until you see something like this in the black console pane at the bottom of the Arduino IDE window:

Sketch uses 444 bytes (1%) of program storage space. Maximum is 30720 bytes.
Global variables use 9 bytes (0%) of dynamic memory, leaving 2039 bytes for local variables. Maximum is 2048 bytes.

As soon as you see that, press and release the reset button. The upload should now finish successfully.

If so, your next task is to identify what it is in your original sketch that causes this.

Hello 'pert',

How quick and to the point. Worked from the second attempt. You saved my xmass eve :slight_smile:

I am out of the woods.

Tx!!

Peter

You're welcome. I'm glad to hear it's working now. Enjoy!
Per