Latest Leonardo Bootloader? Someone developed one...

I described my tale of using the ICSP headers to program Leonardos and sure enough it works great at the cost of a nuked bootloader. Apparently, someone developed a better bootloader for a company named Red Bear Labs Corp. for a Leonardo clone with Bluetooth. This weird bootloader holds the ttyACMx port open like an UNO does. I tested this "BLEND" board with several sketches including a mouse emulation test sketch. That bootloader works great.

I wouldn't be surprised if they are keeping it to themselves. But like Opti-boot for UNOs, there has to be newer bootloaders for Leonardos. It would be awesome if one out there works as easy as the Red Bear Labs bootloader.

Hi,
Sounds great.

LINK?

The web site of the company is redbear.cc and someone will have to email them about that good bootloader for Leonardos. It would be awesome if an open source bootloader like the Red Bear one were made. Any other ATMega 32U4 chip device could sure use it too, like a Lilypad USB, the Micro, etc. The Lilypad USB and Micro will both require that "pogo" thing by Adafruit to program unless the bootloader is the good one now known to exist (though not necessarily open source).

A good bootloader for Leonardos would save countless hours of frustration that people currently endure until they take up using the ICSP pins and nuke the crappy bootloader in the process. I guess I'll have to be the someone to email Red Bear Corp about that awesome bootloader. Too bad Atmel chips do not have a von Neumann architecture. One could in that case "PEEK" the PROM and copy it to put it on new Leonardos.

Uh, guys?

That was cool of them.

@pentius I think you can peek the rom with an icsp tool unless the fuse is locked. If that can be done on the x86 Curie I doubt it would be a selling point.

I see Pentius once again finding a platform from which to bash the Leonardo bootloader. He’s been at it for three years, will he ever tire of the task? Now we're informed that someone else has finally created a better bootloader for the Leonardo.

Really? A better bootloader? Research much Pentius? Let’s dispel some very erroneous statements, one by one.

Apparently, someone developed a better bootloader for a company named Red Bear Labs Corp. for a Leonardo clone with Bluetooth

No disrespect towards RBL but they didn’t develop squat when they created a bootloader for the atMega32U4 for use with their product.

This weird bootloader holds the ttyACMx port open like an UNO does.

Nothing weird about that, so does the Leonardo bootloader. No changes there.

I wouldn't be surprised if they are keeping it to themselves.

We’ve already seen that it is in the public domain. RBL is legally bound to release it.

A good bootloader for Leonardos would save countless hours of frustration that people currently endure until they take up using the ICSP pins and nuke the crappy bootloader in the process

From the posts that I see on this board, you have no one to share that frustration with, since I don’t see others posting problems about the 32U4 bootloader. The only thing being endured here are your complaints.

Now for the real point of my little exercise here.

This better bootloader is the very same bootloader in the Leonardo. Byte for byte. RBL used the very same LUFA source from Dean Camera for their bootloader as is used in the Leonardo (and all other Arduino 32U4 boards). Line for line. The only thing that is different is the PID and VID, which is an obvious difference since they are different boards. Don’t believe me? If you have any doubts as to the code base being the same, just consult the README.TXT file in the RBL repo:

The source file - Caterina.c was modified for the Blend Micro board only.
For Blend, it is the same as Arduino Leonardo board.

So the only thing Pentius has achieved is to make his Leonardo board look like a RBL Blend board to the IDE. Which, IMO, will only lead to later confusion.

What we don’t know is this one very basic fact. Was Pentius’s Leonardo recognized the first time he plugged it in? If not, I’d suspect that the bootloader wasn’t intact from the factory. Rare, but it happens. If it was authentic Arduino and purchased from a legit dealer, it could have been replaced under warranty but that ship sailed long ago.

But, if it was recognized initially by the IDE, he most likely did what every rookie user has done sooner or later. That is to build a HID program without having a way to disable the USB use. Simple, easy mistake to make in spite of the mentions of this danger in the playground and elsewhere. The easiest way to fix this is to download a new bootloader via ISP, which erases the entire device, including the problematic user program.

That's what it looks like to me. Erase the device, reinstall the bootloader and poof, it magically works.

Amazing, just amazing how many people cannot see the bigger picture. They're too busy looking into the wrong end of the microscope and complaining that they cannot see anything to notice that the problem is...

Im confused at how downloading a sketch via ISP (instead of regular USB) "nukes the bootloader"??

I was working on a design with a custom PCB using the '32u4...the board was going to be a "one and done", so I was thinking of just eliminating the USB port to save space and cost on the PCB...then just flash each board with my sketch via ISP, and send it on down the road.

I tried it on a couple test boards, and it seems to work fine....just flashing the entire sketch at once via ISP. Obviously takes longer (to flash via ISP) and is less convenient than via USB, but as I said, this will be a production PCB that wont need future updates......

I cant see any problem with doing a custom "Leonardo based" PCB this way? But after reading this thread Im a bit confused...

Ben

Loading via ISP (which does not take any longer, and is probably quicker) typically sets up to start running the sketch right after a reset completes. If it does that on a Leonardo too, the bootloader does not run, and even if not wiped out, is effectively nuked as there is no way to start it from a Reset.

CrossRoads:
Loading via ISP (which does not take any longer, and is probably quicker) typically sets up to start running the sketch right after a reset completes. If it does that on a Leonardo too, the bootloader does not run, and even if not wiped out, is effectively nuked as there is no way to start it from a Reset.

Hmm...definitely takes much longer for me.

Using a USBTinyISP, then I select "upload using programmer" in the Arduino IDE...seems to take about a minute to do the full write, then readback.

"regular" Leonardo board with flashing via USB takes maybe 10 seconds?

So you're saying that if I flash using ISP, my sketch will run normally, but if I press "reset", it wont boot at all? It will only start running properly after a full power on/off cycle? Sorry I guess Im kinda confused here...

When you program via ISP, it has to erase the flash anyway, so it removes the bootloader.

Reset works fine regardless of how it's programmed.

definitely takes much longer for me. Using a USBTinyISP

Various "Software USB" programmers are limited to low-speed USB access (and probably slowly), and may be significantly slower than full-speed USB programmer that communicates a page-at-a-time.

So you're saying that if I flash using ISP, my sketch will run normally, but if I press "reset", it wont boot at all?

Before you can program flash, it has to be erased. The bootloader can erase one "page" of flash at a time, so memory that isn't being replace (including the bootloader itself) stays however it was. The ISP programming protocol does not allow single-page flash erase; it can only erase the ENTIRE flash memory. Including the bootloader. If you do this, you should re-program the fuses as well, or after reset the chip will try to start the bootloader (which isn't there anymore), which can have 'random' results. (If your sketch is shorter than the normal maximum, it will probably work OK, since starting at the erased bootloader address will find "blank" memory that will do essentially nothing until it runs into the sketch itself.)

CrossRoads:
Loading via ISP (which does not take any longer, and is probably quicker) typically sets up to start running the sketch right after a reset completes. If it does that on a Leonardo too, the bootloader does not run, and even if not wiped out, is effectively nuked as there is no way to start it from a Reset.

Slightly wrong. Flashing a sketch will not change the fuse settings, so the processor will still be set up to start at the bootloader section on reset. The difference is that the bootloader will be blank, full of 0xFFFFs instead of the bootloader code. The processor interprets these as sbrs r31,7 instructions (skip next instruction if bit 7 of register 31 is set), which won't really do anything. Once the end of flash has been reached, it wraps around to 0 and starts the sketch.

As mentioned, that's if your code is smaller than a normal sketch, which won't write into the bootloader section to begin with. If your sketch crosses the bootloader boundary and you leave the Boot reset fuse programmed, you could start up in the middle of a function or data table with unpredictable results.

If you're going to get rid of the bootloader, reprogram the high fuse to turn of BOOTRST.

Flashing a sketch will not change the fuse settings

Well, it hasn't, historically. I consider this a bug, and it might get fixed at any time. There is not reason that the "upload using programmer" command SHOULDN'T reprogram the BOOTRST fuse (aside from the fact that there are other fuses that it should leave alone, and modifying ONE fuse in a byte doesn't seem to be supported. (another thing that COULD change!))