Atmega32U4 bootloader - can it be changed to another one?

I'm currently considering to exchange the controller on my application from a 328P to a 32u4, mainly because latter has USB capabilities so I do not need an FTDI any more.
Dilemma I face is, that the Software running on my application board really uses the full Flash size the 328P can offer, and the 32U4 has 2kbytes less Flash due to the larger bootloader size (both Chips have 32kBytes of Flash).

So I wanted to ask: can the bootloader of the 32U4 be overwritten with another bootloader, say that of the Nano or even Uno to obtain more Code space? Would the USB still work?

Yes you can change it to the Optiboot bootloader that the Uno uses. You would have to compile it for the 32U4. The USB will still work, but not for uploading sketches. For uploading sketches you would use a separate USB to serial adapter. Sketches compile larger when written for Leonardo, because the larger bootloader for the 32U4 also requires additional code running in the background of your sketch looking for the reset signal to come across the USB connection. You can notice this if you compile the blink sketch for a Leonardo, and compare the size with the blink sketch compiled for Uno. So, if your sketch barely fits on a 328P, you will probably find it won't fit at all on the 32U4. You don't need to use a bootloader at all if you upload your sketches using an AVR programmer or using another Arduino as ISP.

dmjlambert:
Yes you can change it to the Optiboot bootloader that the Uno uses. You would have to compile it for the 32U4. The USB will still work, but not for uploading sketches.

Thanks for of all for the hints. Actually the requirements I have can be summed up like:

  • use USB to charge a single LiPo/LiIon battery, much like the LilyPad USB does
  • use USB to upload code without an external FTDI chip or breakout board
  • use same USB to interface to an USB Flash or SD-card

In the target application I want to have a simple USB dangling out, and no more access to the insides of a battery operated device.

So if I get it right I cannot overwrite the bootloader without disabling the USB, which is a nogo.

If I want more code space, I need to go to the next level of Atmega chips, which as far as my reseraches went, would be one of the ATxmega chips, which are huge leaps in features and capabilities from a 328P. Still, I could use them, but I did not find any Arduino or Arduino compatible board using ATxmega Chips... is there any which I can take as a guideline to my design?

You have ambitious requirements there. If I were you I would be looking at just using a Raspberry Pi Zero or Teensy board in your design.

If you want to stay in the more common AVR Arduino world, that is OK too. After developing for some time on a Leonardo, you realize there is nothing particularly desirable or fantastic about uploading through the USB built-in on the ATmega32U4. Anyway, that USB port can't be a USB host like you are suggesting, to interface with flash memory. Malfunctioning sketches will hang the processor and make it difficult to upload a revised sketch. It is more trouble-free and just superior design to use an FTDI chip on the same board and just use a conventional processor such as ATmega328P, ATmega1284P, or ATmega2560. There is also total cost of ownership to consider. There are a lot more people familiar with the regular ATmega series chips that are in common designs, so if you want to ask questions or use common libraries, you would be better off using something common and popular.

If you want to stick with AVR, there are the AT90USB646/647 and AT90USB1286/1287 that have 64 KB and 128 kB of flash. I don't know if the Leo's bootloader is trivially recompileable to that device, or how easy switching between a host and client would be to code, but it's an option.

You'd have to reimplement the Arduino core for it too.

I think for a better picture I have to tell the whole story.

I’m planning to design a small bro of this circuit:
DIYino Prime v1

In this application size plays a paramount role. But not only that, idle more current consumption is also an important factor.
So I face the following decisions for small brother:

  1. I for sure do not have the space or luxury to include an FTDI. It takes a lot of board space and it has a totally uncontrollable current consumption due to no idle mode and I want a board which can be put to an idle/sleep mode with <1mA current. So I have two choices:
  • make it like a pro-Mini, no FTDI, upload via FTDI breakout. But I still want to have the USB port to access the flash or SD-card over the YX5200-24SS chip (MP3 chip with USB capability) AND more importantly I want to have one single access point through the USB. Which means if I go for uploading via an FTDI breakout board I have to share sigals between breakout and USB like:
    Tx->U-
    Rx->U+
    DTR->ID
    and to be frank I do not have any idea if that’s gonna work. For sure I can cut power to the MP3 chip, but I do not know how this chip would load the signal lines in either sleep or active mode…?

  • other option is to use the Atmega32U4, which has in-built USB. Of course I still need to find out if I can simply wired-or the U-/U+ of the Atmega with those of the MP3 chip, but no risk no fun :slight_smile: If I go this way I do not need FTDI breakout, I have more SRAM (not to neglect), but less code space. But since it’s supposed to be a simpler board, it will come with simpler application software: i.e. features need to be cut. I think this would be more than feasible, so I do not think any more that the ~28k is not enough.

In terms of common libraries I assumed that any AVR with Arduino bootloader will be able to cope with any of them…am I wrong?

Protonerd:
In terms of common libraries I assumed that any AVR with Arduino bootloader will be able to cope with any of them...am I wrong?

Most Arduino libraries that work on ATmega328P should also work on ATmega32U4 since it's a common Arduino microcontroller. Most library authors will make the effort to add support for ATmega328P, ATmega2560 and ATmega32U4 at a minimum. I have encountered one or two that didn't but it's pretty rare. If you used a less standard microcontroller you will run into problems with some libraries not being compatible. These can usually be solved fairly easily but might make your board less usable for people who don't want to go digging into library source code. The bootloader will usually not make a difference for library compatibility. The only exception I can think of is the Pro Mini bootloader's watchdog bug that would make it incompatible with any library that uses the watchdog reset, not a common feature of libraries.

Are you using the latest version of the IDE? 1.6.11 and later have LTO enabled, which gives a significant reduction in sketch size. Might be enough to get you in. It's often 10-15%...

I installed 1.6.12 IDE yesterday and compared code size for some of my sketches with ones compiled with 1.6.10. No difference at all. Is there a trick how to enable LTO. What it is actually? BTW I use AVR board manager version 1.6.11, because some of my sketches failed to compile with the default 1.6.12

But I've observed something strange (to me at least). When compiling the same sketch, code size varies depending on the board used. One sketch I compiled for Nano returned ~28k hex size, same sketch compiled for LilyPadUSB (Atmega32U4) returned ~30k... Where could this discrepancy come from?

The thing that determines if you're using LTO or not is actually the Arduino AVR Boards version. Arduino AVR Boards 1.6.12(included with Arduino IDE 1.6.10) and later use LTO so it makes sense that you'd get the same results. Even an IDE version older than 1.6.10 will still have LTO if you install Arduino AVR Boards 1.6.12 or newer.

Protonerd:
But I've observed something strange (to me at least). When compiling the same sketch, code size varies depending on the board used. One sketch I compiled for Nano returned ~28k hex size, same sketch compiled for LilyPadUSB (Atmega32U4) returned ~30k... Where could this discrepancy come from?

This was explained in reply #1 above.

Sorry, overlooked the implications. Its one thing when you read it and yet another if you are confronted with the reality :slight_smile: Now I made the connection. This sadly makes the situation worse, less space, bigget code size...bad combo.

Take a look at Teensy 2.0++, maybe it can work for you. It’s Arduino compatible.

http://pjrc.com/teensy/index.html

tf68:
Take a look at Teensy 2.0++, maybe it can work for you. It's Arduino compatible.

Teensy USB Development Board

I love this board, already considered revising my product to include one, main issue is the proprietary boot loader chip which I can source only from pjrc and it also takes quite a space, for the target application it is an overkill.
Actually if I go with a much more powerful CPU/uC/Processor, it would not make sense to keep the mP3 chip, but process the sound in the CPU as well. But that is not more in the spirit of Arduino in my eyes. Also power is an issue, that is why I like the low power AVRs.

  1. Teensy++ 2.0 is an AVR, an AT90USB1286 to be exact.

  2. It may be trivial to port the Leonardo bootloader to that chip. The LUFA build system supports that chip and is the original source of the Leonardo bootloader.

tf68:

  1. Teensy++ 2.0 is an AVR, an AT90USB1286 to be exact.

  2. It may be trivial to port the Leonardo bootloader to that chip. The LUFA build system supports that chip and is the original source of the Leonardo bootloader.

Apologies. There is a guy who built a similar application as I make my boards for, and he used a Teensy 3.x and I (wrongly) assumed that all of them use processorts other than an AVR. Thanks for pointing out that I was wrong. Well, the AT90USB1286 is an USB capable AVR, is the Teensy bootloader for Arduino open-source? I love Arduino, but I might be still not up to the challange of porting bootloaders. I like to think about them as something provided already.

The AT90usb1286 comes from atmel with a dfu bootloader.
LUFA has a open source dfu bootloader.

The Teensy bootloader is not open source.
LUFA has an open source clone.

The LUFA CDC bootloader can be used with no porting. I have used it on a 32u4 (Leonardo clone) and don't remember any problems.

I would use the CDC booloader myself, and use the Teensy board for testing. The Teensyduino package will work for building your code and you can use avrdude to load the binary for the other bootloaders.
Be sure to read and understand the LUFA docs before you leap into things.

I think the DFU boot loader comes pre-loaded on AVRs that have USB ports. (edit: I didn't read close enough, tf68 already mentioned it) Data sheet says "USB boot loader programmed by default in the factory." Nothing wrong with compiling the hex file using the IDE and then uploading to the chip using DFU.

Does this mean the DFU of the AT90usb1286 is the same as for the Atmega32U4? In this case, could both be used as a Leonardo in the IDE?
Of course coming to think about it, it is of no use, because then the IDE would stop and exit if the code size exceed the 28k of the 32U4 and the AT90 has 128k... But still, at least it would recognize the board, right?

Then the next question is: how to tell the Arduino IDE how the AT90 is configured? Does this chip exists in the Device Manager?

As to the LUFA bootloaders, I need to do a lot more researching before I'm confident to go down that path...

On the other hand side if the AT90 has USB capability and can be recognized by the IDE, it is a good alternative to a similar AVR wo/USB+FTDI combo.

The Leonardo DOES NOT use the DFU bootloader. The Leonardo bootloader is a slightly modified CDC bootloader from LUFA.

You can use the TeensyDuino IDE add-on to generate a hex file for your AT90usb1286. You choose Teensy++ 2.0 from the boards menu and verify your code. Then use a DFU utility to upload that hex file to your chip. The latest release of Avrdude (6.3) also supports DFU bootloaders, so you could use Avrdude from the command line to load the hex file.

The IDE generates code for whatever board you choose.