Arduino Micro is detected as Leonardo - and flashes outdated firmware as well

[MartyMacGyver]

When programming the Arduino Micro, the only option is to use the Leonardo firmware which isn't quite the same - I'd expect to flash Micro-prod-firmware-2012-12-10.hex, which appears to be what my board came with (which was detected only as "unknown MD5 sum"). Reflashing the Micro using Arduino ISP with the firmware from the IDE restored the original bootloader successfully.

Note that the Leonardo firmware included is "Leonardo-prod-firmware-2012-04-26.hex" while the current version shipping with the IDE is Leonardo-prod-firmware-2012-12-10.

(My baseline is the bootloaders included with the Arduino 1.6.4 IDE.)

[nickgammon]

Yes, I see what you mean, but is there any information about the differences between these 3 bootloaders? I don't think it particularly matters what bootloader is on the chip, providing it does the job of bootloading. (I say that because it is the same processor chip, after all).

Once the sketch is loaded the bootloader is not used any more.

However to be more up-to-date I have updated the firmware from Leonardo-prod-firmware-2012-04-26.hex to Leonardo-prod-firmware-2012-12-10.hex.

I tested it on my Micro and successfully uploaded a couple of sketches.

https://github.com/nickgammon/arduino_sketches/commit/4c4e79e802a09207e07c8852b9e0e9e8807210fb

[MartyMacGyver]

For one thing the USB PIDs differ between these devices (and for the Esplora as well, which I don't have handy):

# USB product ID (PID)
# official Leonardo PID
# PID = 0x0036
# official Micro PID
# PID = 0x0037
# official Esplora PID
# PID = 0x003C

Those appear to be outside the scope of what you modify when you flash a new bootloader though. However, there are some other differences that are flashed - I'm working to understand what those are and if they are significant.

[MartyMacGyver]

I ran "avr-objdump.exe -D --architecture=avr:5 file.hex > file.obj" to examine the assembly. There are a few more differences in the bootloader code itself, but I'm not sure why they particularly matter, and most are of the form:

#Leonardo:
77e4:   5d 9a           sbi 0x0b, 5 ; 11
77e6:   28 9a           sbi 0x05, 0 ; 5

# Micro
77e4:   5d 98           cbi 0x0b, 5 ; 11
77e6:   28 98           cbi 0x05, 0 ; 5

These could be identical code, affected only by compiler optimizations (thus, equivalent binaries). There's a text signature at the end of the block with the distinguishing device name, but I'm not sure that's read by anything.

It'd help if they posted the source code for these.

[nickgammon]

I'm be pleased to hear if there are substantive differences.

Interestingly, if I upload the ASCIItable sketch, claiming it is a Micro (which it is) and do a lsusb I see this:

Bus 003 Device 034: ID 2341:8037 Arduino SA 

Now if I change to claiming it is a Leonardo, I see this:

Bus 003 Device 036: ID 2341:8036 Arduino SA Leonardo (CDC ACM, HID)

The only thing I can think that the "wrong" bootloader would do is not be detected when you go to upload your sketch. However my own tests show this isn't happening, at least under Ubuntu.

[nickgammon]

#Leonardo:
77e4:   5d 9a           sbi 0x0b, 5 ; 11
77e6:   28 9a           sbi 0x05, 0 ; 5

# Micro
77e4:   5d 98           cbi 0x0b, 5 ; 11
77e6:   28 98           cbi 0x05, 0 ; 5

As best I can make out these SBI/CBI instructions are referring to:

• 0x0b: PORTD
• 0x05: PORTB

And in particular PD5 (TXLED) and PB0 (RXLED).

Ah, I see, lol. On the Micro the LEDs are wired via a resistor to Gnd, on the Leonardo they are wired via a resistor to +5V. So the instructions have to be inverted to have the same effect.

Oh well, so far we just know the LEDs will blink the wrong way around while you are uploading a sketch. This won't affect the sketch running, just the uploading. And since the LEDs blink rapidly anyway, you would be hard-pressed to pick the difference.

[MartyMacGyver]

I see your points, and in this case it's not a functionally significant difference.

A larger question is whether the goal is to support flashing the bespoke firmware for a given board or simply the most common denominator of firmware for a given MCU. If the former, then I'd expect the Micro to bear (and dump) Micro firmware, not anything else. If the latter, then it'll work til it doesn't (e.g., some board detected as a Leonardo that is actually non-trivial in its differences). Either way, I wanted to alert you to this as it caught my attention when updating bootloaders today. Now I know how to update them from your code as well as directly from the IDE.

[nickgammon]

If the former, then I'd expect the Micro to bear (and dump) Micro firmware, not anything else.

True, and we have to weigh up being strictly correct, with other issues like, if we include different bootloaders for identical chips, you then have to ask "well, which board do you actually have?". I currently do this for the Atmega328P because of the desire to support 16 MHz (with a crystal) and 8 Mhz (with the internal oscillator).

The whole thing was intended to be a quick-and-easy way of uploading a bootloader for common Arduino-like boards/chips. There are other, more complex, ways of getting exactly the bootloader you want onto a chip.

Thanks for alerting me, I think I'll close this now. :)

[NicoHood]

There is no difference between those bootloaders except the USB PID and the leds. I've programmed those bootloaders myself and it doesnt affect at all. But if you have time to add both, why not with a #define to let the device show up properly?

[nickgammon]

Seems like a lot of work for little return. After all, the device only shows up for the few seconds the bootloader is active. And then the user of the sketch either has to answer a question, or select the correct define, to program the board properly.