Daisy Bootloader: Now Open Source!

Andrew Ikenberry · 5/19/26

Hi Friends!

We have some big changes to announce to the Daisy bootloader.

TL;DR: The Daisy bootloader is now open source and can be modified for use in custom projects. Among other things, this enables custom USB ID names when connecting Daisy-based hardware to a computer. 

Head to the Daisy Bootloader Repository

What is a bootloader anyways?

A bootloader is a small, low-level program that runs immediately when an embedded device powers on, before your main firmware. On a platform like Daisy, the bootloader’s job is to initialize essential hardware (like clocks and memory), check for valid application code, and then load and jump to that application. It is also responsible for updating firmware in a safe manner, and defining the USB ID that will load when the device is connected to a computer while in the bootloader. 

Why would I want to modify the Daisy bootloader?

For most use cases, you might never need to modify the Daisy bootloader. However, there are two situations that are worth mentioning here:

1. Custom USB ID Names - If you want your Daisy-based sampler to show up on a computer with the ID name of “My Super Cool Sampler”, this would need to be defined in the bootloader. Otherwise, it will show up as “Daisy Bootloader”.
2. Bootloader Access: You can customize access to the bootloader based on any input devices, start up conditions, etc. that make the most sense for your project.
   
3. Firmware Updates: Add new ways to update firmware like QPSK encoded audio, MIDI SysEx messages, etc.

How do I use the Daisy bootloader?

Using the bootloader is quite similar to the way you've been loading programs – actually you've been using a bootloader all along. When you hold boot while tapping reset, it causes the Daisy to boot into the STM32's "System Bootloader". This is what allows you to connect over the built-in USB port, and update your application onto the board.

Knowing that, much of what we're going to accomplish below, you're already used to with some small differences. 

To update your program for use with the Daisy Bootloader, we'll need to do a few things:

1. Compiling your code for the Daisy Bootloader
2. Flashing the bootloader onto the Daisy
3. Flashing your application binary onto the Daisy Bootloader.

Let's take these step by step.

Compiling your code for the bootloader

For most applications, this is quite simple, and will only require checking a box, or updating a build file.

You can build applications for the bootloader from:

• C++
• Oopsy
• Plugdata

For information on the specifics, check out the bootloader page of the support site.

Flashing the bootloader onto Daisy

Fundamentally, the Daisy Bootloader is just an application built for the Daisy's internal flash (i.e. BOOT_NONE). So any of the variant binaries, or custom builds can be flashed the same way as an application built that way.

The latest official binaries/variants are available on our web programmer
in the bootloader tab. These variants are also kept up to date within libDaisy, and can be programmed via the Make build with make program-boot.

Flashing your application onto the Daisy Bootloader

Our application has been updated to compile for the bootloader, and we've flashed our Daisy with the Daisy Bootloader. Now the fun part: flashing our application onto the Daisy.

The beauty of the Daisy Bootloader is that it provides additional methods of loading firmware onto the Daisy beyond the Device Firmware Update (DFU) interface used by the built-in bootloader.

There are a few methods of update that can be used:

• DFU
• External Media File

DFU

DFU works similarly to the System Bootloader with a few exceptions.

To stay in the bootloader, press reset, and then tap boot while the LED is pulsing.
Make sure you are not holding the boot button down when you press reset.

Instead of looking for "DFU in FS Mode" on your computer, you'll look for "Daisy Bootloader," or if you've customized the bootloader with a custom descriptor, the name you've chosen.

There are two DFU variants: intdfu and extdfu.
The intdfu build uses the built-in USB port for DFU, while the extdfu will use the external USB interface (pins D29, D30) for DFU.

External Media File

All variants of the bootloader will attempt to find a ".bin" file on an SD Card that is connected at bootup.

The intdfu variants will also check the external USB (pins D29, D30) to see if there is a USB flash drive attached, and attempt to load a file from there.

The search for the file itself is simple: it looks for the first file ending with a .bin extension in the root directory of the attached media.

Short Timeout Variants

The short (10ms) bootloader variants are intended to be jumped to with an "infinite timeout" from the user's application code. These will boot up, and jump to your application faster than you’re likely able to press the boot button.

For example, in C++ you can do this:

This will reset the Daisy into the bootloader, where it will stay until the Daisy updates its firmware, or is reset/powered down.

Switching Variants

If you run into an issue where, for one reason or another, you are unable to access the bootloader for a specific variant (e.g. you remove the Daisy Seed from its daughter board, but it has an extdfu variant installed), you can easily switch bootloader variants without affecting the application that's stored.

There is no difference in this process than installing the bootloader in the first place.

Conclusion

Hopefully this answers your bootloader questions. For more information on working with the Daisy bootloader, make sure to check out our support page which has much more information than was presented here.
 
We’re looking forward to seeing Daisy projects take advantage of the new bootloader licensing!

Happy sound making,

Andrew