Thanks for the update 
Hi
Any news on boot loading ?
I’ve been away for 6 months working on a totally different tech-stack
They’ve added bootloader to libDaisy recently and made some more changes to it since then. I’m not sure if it has been documented properly yet or used by anyone besides core developers.
Most of the support has been added to libDaisy at this point, but we haven’t streamlined it, or added documentation yet.
The bootloader (currently v4) can load firmware via SD card, USB drive, and/or DFU, and can be flashed to the Daisy over DFU using make program-boot, or by using the electro-smith web programmer.
Code can be compiled to target the bootloader (either to run upto 512kB from internal SRAM, or to run up to ~8MB directly from the QSPI) by manually specifying the LDSCRIPT in the user makefile.
The recipe make program-app has been added for DFU uploading of firmware compiled this way.
So most of the pieces are in place! We’re hoping to have some documentation, and do a more general announcement before the end of the year.
2 Likes
So I was just doing a few tests with the new bootloader and realized it’s already pretty easy to use (with the most recent libDaisy):
To compile an existing program you can add the following two lines to the application Makefile right after SYSTEM_FILES_DIR is set.
LDSCRIPT = $(SYSTEM_FILES_DIR)/STM32H750IB_sram.lds
C_DEFS += -DBOOT_APP
The linker script here will store the program in QSPI, but load it into the AXI SRAM and execute it from there. So program size can be up to 512kB (with no performance penalty).
Alternatively you can use the STM32H750IB_qspi.lds to execute code directly from the external flash chip on the Daisy (This allows for much larger program sizes, but can incur a bit of a performance penalty)
Once it’s compiled (it’ll be clear by the linker output at the end saying 0GB of flash used), you can flash the bootloader itself via DFU with:
make program-boot
To engage the the bootloader you can press the RESET button, and the usr LED will start to pulse. If there is no application on the QSPI, it will do this indefinitely, otherwise it will jump to the program after a few seconds unless the boot button is tapped during that period of time.
Once engaged, the bootloader will search an SD card, or USB drive (connected to the external USB pins) for a valid .bin file, and load it, or will wait for a dfu connection that can be flashed to with Make using:
make program-app
We’ll probably simplify it a bit more by using just a make variable to configure the project (like we did for adding the proper FATFS files), but this does work for now 
We’ll make a wiki page soon once we iron out the process a bit more, but feel free to start messing around with it!
2 Likes
I wasn’t been able to find bootloader sources. Is it open source? If not, do you have plans opening it up?
The bootloader is not open source.
We will be publishing some more thorough documentation with it’s capabilities, and how to with it once the process has been stabilized a bit (in the next few weeks).
Why is it not open source?
There are still a few aspects of the project that are undergoing structural changes, as well as parts that currently use the ST HAL instead of libDaisy, etc.
We’re also still discussing what license, contribution guidelines, etc. we’ll attach to it if/when we do open source the project.
We should have a bit more information around the time that we publish the usage documentation.
2 Likes
Thank you, @shensley, for this useful info. I’m having some issues trying to apply these steps to Blink. Probably is something related with my lack of knowledge of VS Code, since I started to use it just few days ago. After successfully running Blink on flash, I changed the Makefile to include the mods you suggested:
...
# Core location, and generic makefile.
SYSTEM_FILES_DIR = $(LIBDAISY_DIR)/core
# Upload app in QSPI, execute on SRAM
LDSCRIPT = $(SYSTEM_FILES_DIR)/STM32H750IB_sram.lds
C_DEFS += -DBOOT_APP
include $(SYSTEM_FILES_DIR)/Makefileand I’m getting this error message:
After that, the make program-app gives the same error (Error 74), and the user LED remains pulsing instead of blinking.
@vladuino Your changes to the Makefile look good. After changing the Makefile did you recompile the Blink program using make clean and make?
Since it’s only linker changes, running make by itself may not recompile the program.
If you did so, and you were still getting the error, we can try to recreate the issue on our end.
Ops. I miss that, @shensley. As I told you, I’m really newbie in VS Code. But I still get the same error after sending the sequence: make clean, make (no errors), and make program-boot, where I’m getting the error.
@vladuino no worries!
FWIW, the “Error 74” is not a critical error, and kind of just happens with this software. Essentially “dfu-util” expects the daisy to stay connected as DFU and say everything went well, but the daisy jumps to the application, and disconnects without acknowledgment. This happens with the STM32 system bootloader, and our own bootloader.
I was able to replicate the changes to the Makefile you made, and had the following results:
Build Memory:
Memory region Used Size Region Size %age Used
FLASH: 0 GB 128 KB 0.00%
DTCMRAM: 6684 B 128 KB 5.10%
SRAM: 44484 B 512 KB 8.48%
RAM_D2_DMA: 16 KB 32 KB 50.00%
RAM_D2: 0 GB 256 KB 0.00%
RAM_D3: 0 GB 64 KB 0.00%
ITCMRAM: 0 GB 64 KB 0.00%
SDRAM: 0 GB 64 MB 0.00%
QSPIFLASH: 0 GB 7936 KB 0.00%
arm-none-eabi-objcopy -O ihex build/Blink.elf build/Blink.hex
arm-none-eabi-objcopy -O binary -S build/Blink.elf build/Blink.bin
Program bootloader:
$ make program-boot
dfu-util -a 0 -s 0x08000000:leave -D ../../libDaisy/core/dsy_bootloader_v4.bin -d ,0483:df11
dfu-util 0.10
Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2020 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/
Warning: Invalid DFU suffix signature
A valid DFU suffix will be required in a future dfu-util release!!!
Opening DFU capable USB device...
ID 0483:df11
Run-time device DFU version 011a
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 1024
DfuSe interface name: "Internal Flash "
Downloading element to address = 0x08000000, size = 96780
Erase [=========================] 100% 96780 bytes
Erase done.
Download [=========================] 100% 96780 bytes
Download done.
File downloaded successfully
Error during download get_status
make: *** [../../libDaisy/core/Makefile:295: program-boot] Error 74
And programming the app:
$ make program-app
dfu-util -a 0 -s 0x90040000:leave -D build/Blink.bin -d ,0483:df11
dfu-util 0.10
Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2020 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/
Warning: Invalid DFU suffix signature
A valid DFU suffix will be required in a future dfu-util release!!!
Opening DFU capable USB device...
ID 0483:df11
Run-time device DFU version 011a
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 4096
DfuSe interface name: "Flash "
Downloading element to address = 0x90040000, size = 44484
Erase [=========================] 100% 44484 bytes
Erase done.
Download [=========================] 100% 44484 bytes
Download done.
File downloaded successfully
Error during download get_status
make: *** [../../libDaisy/core/Makefile:292: program-app] Error 74
Is that any different than what you’re seeing?
@shensley:
Everything is identical, including memory map, up to (but not including) make program-app. This command generates:
$ make program-app
dfu-util -a 0 -s 0x90040000:leave -D build/Blink.bin -d ,0483:df11
dfu-util 0.10
Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2020 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/
Warning: Invalid DFU suffix signature
A valid DFU suffix will be required in a future dfu-util release!!!
Cannot open DFU device 0483:df11
No DFU capable USB device available
make: *** [../../libDaisy/core/Makefile:292: program-app] Error 74 It seems that the board wasn’t in DFU mode, although the LED was pulsating. Did I miss something? Resetting the board has no effect, and if I change the board to DFU mode (reset + boot), it returns to normal DFU and I get this when sending make program-app:
Run-time device DFU version 011a
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 1024
DfuSe interface name: "Internal Flash "
Downloading element to address = 0x90040000, size = 44484
Last page at 0x9004adc3 is not writeable
make: *** [../../libDaisy/core/Makefile:292: program-app] Error 74 with “Internal Flash” instead of “Flash”
@vladuino hmm, that is strange indeed. If the light is pulsing it should be DFU-accessible.
I can look into this a bit more tomorrow.
Hi @shensley. I think you’d be glad to know that I managed to make Blink to work with the new bootloader. The problem was that Windows recognized the board just after the make program-boot as “DFU in FS mode (COM7)” with wrong driver, as you can see in the image below.
So I changed the current driver (usbser (v.1.0.0.0)) to WinUSB with Zadig. After that I had no problem to upload Blink with make program-app. Unfortunately some other issues come out after that. The user led blinks in an irregular way, flashing 4 times/sec instead of just one, with different pauses between flashing, more like a Morse code. Moreover, although I still can upload Blink in internal flash, I can no longer change the app when using QSPI, since the USB driver somehow rolled back to the old one (usbser), and since Blink is already stored in QSPI, the new bootloader always loads and executes Blink before Zadig manage to change the driver. I think we need a make program-clear to erase the QSPIFLASH 
@vladuino I’ve actually been meaning to push a full QSPI erase example soon for similar purposes.
A make program-clear or make app-erase is a great idea, though!
In the meantime, with v4 of the bootloader you should be able to force the daisy to stay in bootloader mode after power up (or pressing reset) by tapping the BOOT switch within the first few seconds. (Note: this is slightly different from the system bootloader entry).
Hello there!
Has anyone tried to store only the LUTs (like waveforms, math LUTS) or any other constant data in the QSPI (or SD card) allowing this way to keep all the internal MCU Flash for the code instructions?
This way I could easily flash and debug the program speeding up the development.
I tried the daisy bootloader workflow but it didn’t convice me.
Thanks