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
I can’t believe I forgot to post it here when we added it!
We added a short guide to the libDaisy docs going into detail on how to build applications using the bootloader.
Edit (Jun '23): the above link does not seem to work now, so we’ll look into it more. Here’s a link that does work in the meantime: libDaisy: Getting Started - Daisy Bootloader
I just tried the Daisy Bootloader and I like it very much. At least I can see 3 benefits:
- I can run bigger applications now.
- According to my test results, the code in SRAM runs even faster than in the internal flash.
- The internal flash of STM32H750 is guaranteed 10,000 erase/program cycles. While the QSPI flash (IS25LP064) is guaranteed 100,000. So I need worry less about it.
Not sure if it’s an issue or not: when using Daisy Bootloader and APP_TYPE is set to BOOT_SRAM or BOOT_QSPI, the system clock is forced to be 480MHz.
-------------------------- 1 hour later ----------------------
Now I know why running in SRAM seems faster. It’s just because in this mode, the data is put in the DTCM RAM in stead of SRAM. Same as putting macro DTCM_MEM_SECTION in front of the variable declares.
@shensley is there a way to use a board pin to extend the grace period with an external momentary button?
@netherwaves This one’s a bit tricky. The button that extends it is the BOOT button, which isn’t presented on any of the Daisy pins. Theoretically one of the GPIOs could serve this role with a pullup enabled, but this could end up breaking someone’s design if they have that particular pin configured as an input.
Hello @shensley ,
I wanted to take a moment as an FYI the link to “https://electro-smith.github.io/libDaisy/md_doc_md__a7__getting__started__daisy__bootloader.html” does not seem to work anymore. I’m getting a 404 error.
Not sure how much it matters, but i wanted to let you know.
Thanks,
Brett
A minor correction to the original post in this topic (from @bikerboyroy September 2020!): The processor on the Daisy Seed is NOT an STM32H705, but is actually a member of the STM32H750 ‘value line’, specifically an STM32H750IBK6.
And now back to present day, June 2023…
Thank you for bringing this up, Brett. We’ll have a closer look at what happened but here’s a link that does work in the meantime: libDaisy: Getting Started - Daisy Bootloader.
1 Like
You did say you would (Kickstarter) open source everything - “firmware” - is that not the bootloader ?.
“All firmware that we develop will be released for free under a permissive open source license(MIT)” link