bootloader gets destroyed every time

[1inguini]

I can upload sketch, but once I do that the arduino stops getting detected by the computer.
I can fix it by burning arduino bootloader to it (arduino-ide seems to work fine), but if I upload sketch again the same thing happens.
My arduino is a clone of SparkFun pro micro.

[per1234]

Which version of arduino-cli are you using?

Please provide the arduino-cli commands you are using to compile and upload.

[1inguini]

command: probably ➤ arduino-cli upload -p /dev/ttyACM0 --fqbn SparkFun:avr:promicro Arduino/FirstSketch/ accrding to my fish's history.

version: arduino-cli version 0.3.4-alpha.preview

[cmaglie]

Is the Arduino IDE uploading without the issue?
If yes please:

1. please provide the verbose output of the Arduino IDE
2. provide the verbose output of the arduino-cli
   so we can compare them.

If you can test also the latest version of the cli (0.5.0) it would be great.

[bjanders]

I have the same issue, also with a SparkFun pro micro clone. I used a self compiled arduino-cli, commit 550179e

[ubidefeo]

@bjanders when you compile for a target board you also build a version of the firmware with included bootloader.
This is the one you should burn (upload) onto the board.

essentially it becomes a two part operation in which you compile choosing to --export-binaries,
thus creating a local build folder inside your sketch, and then upload with --input-file and passing the build/SparkFun.avr.micro/MySketch.ino.with_bootloader.hex

unfortunately I seem to have found an issue with this particular file in my case, which might be related to an old problem we had with CLI assembling the bootloader binary with the newly created hex.

@cmaglie and I are going to investigate asap

here's a recap of my actions for a sketch named BlinkMe.
I'm inside the BlinkMe folder

arduino-cli compile --export-binaries -b arduino:avr:micro -v
arduino-cli upload -b arduino:avr:micro -v -P arduinoisp --input-file build/arduino.avr.micro/BlinkMe.ino.with_bootloader.hex

[bjanders]

Thanks for the information! I verified that the method using --export-binaries and --input-file works. Is this just a work around for the issue you have found?

What I did previously was according to https://arduino.github.io/arduino-cli/latest/getting-started/:

arduino-cli compile -b SparkFun:avr:promicro
arduino-cli upload -p COMx -b SparkFun:avr:promicro 

Will this work when the issue has been fixed?

Is the problem only for avr:micro or other boards as well?

[ubidefeo]

@bjanders
this discussion is related to using a programmer to upload the firmware, so you'll have to pass in -P and the specific programmer supported by the platform.
It should work after the files are correctly combined, but not sure when this will happen right now.

I remember we fixed it for the SAMD21 a while back, but I need someone to look into this

[bjanders]

I'm sorry, I'm not able to follow what you mean. Which discussion is related to using a programmer are you referring to?

The problem I have, i.e the bootloader getting corrupted, manifests itself when I'm not using a programmer, but flashing using the USB bootloader. And it does not manifest itself when I flash with_bootloader.hex when I'm not using a programmer, but again using the USB bootloader. So in my case the issue is never related to a programmer.

So, to be specific with an example. The following corrupts the bootloader:

arduino-cli compile -b SparkFun:avr:promicro
arduino-cli upload -p /dev/ttyACMx -b SparkFun:avr:promicro 

My assumption is that the above should not corrupt the bootloader. (And I'm guessing it gets corrupted because the command will start writing on the bootloader region instead of the actual program region where I assume it is supposed to.)

The following does not corrupt the bootloader, and the program works as expected:

arduino-cli compile --export-binaries -b SparkFun:avr:promicro
arduino-cli upload -b SparkFun:avr:promicro -p /dev/ttyACMx --input-file build/SparkFun.avr.promicro/Test.ino.with_bootloader.hex

(Guessing this works, since it will write in the same region as the first corrupting command, but this time it contains the bootloader as well, so it doesn't matter as long as you are ok with replacing the bootloader. I assume this should corrupt the program, as I assume this would write the bootloader in the program region if it wasn't for the bug.)

Should this ticket be reopened, since it's still reproducible with the latest version from git?

[bjanders]

It seems I was wrong. Flashing with the above working command only worked as long as I kept it powered.