Seed bootloader + dfu-util

Software Development
42

After contacting them I’ve been sent an update to the bootloader by ElectroSmith that fixed the problem straight away. Thanks !
Hopefully it will be released soon for everyone to enjoy.

1 Like
43

Hey everyone!

We recently revamped the Daisy Web Programmer and the Daisy Bootloader in it is the version that addresses the issue brought up in this thread.
Hope this helps!!

3 Likes
44

Figured it was worth mentioning here that the fixes applied in the dev bootloader have been integrated into libDaisy, and all of the bootloader variants have been updated with the fix as well.

You can find all four variants of the v6.3 bootloader here.

The PR itself had a few details about what the actual issue was, as well as the solution.

The fix being integrated into libDaisy means that any program compiled with libDaisy will automatically recover from the intermittent issue, and it should no longer cause any issues.

3 Likes
45

Hi all,
thanks for the fix and instruction!
I also caught this issue and still can’t solve it in my project. Would be happy if anyone can help.

I’ve done all the steps to fix:

  • through the steps from the PR, got success in serial output
  • updated libDaisy submodule, rebuilt it
  • via Daisy web programmer flashed bin with new bootloader in libDaisy/core folder (v6.3, external, 2000ms)
    After, press->unpress Reset, press/unpress Boot I have glowing led.

After trying to flash my project with build_and_program_dfu I still have the issue

abariska 2025-05-31 at 13.25.19
abariska 2025-05-31 at 13.25.19886×418 19.3 KB

In makefile I have
APP_TYPE = BOOT_QSPI
When use APP_TYPE = BOOT_NONE everything works as expected, but I’m about to out of memory so need the external FLASH.

So, to me it looks like the program is trying to flash internal memory, despite the fact that all (not sure at this point) set for the external one. Probably I missed something

46

Hi @abariska,
Can you check the compiler flags and see if -DBOOT_QSPI is set when you’re running the build_and_program_dfu task?

I noticed last night that when I was trying to build with APP_TYPE = BOOT_QSPI it wasn’t working and that the Makefile in the core folder in libDaisy might have had an error where the APP_TYPE for both BOOT_SRAM and BOOT_QSPI was always set to BOOT_APP instead.

I’ve raised a pull request for libDaisy to fix: Update Makefile to fix incorrect APP_TYPE by joseph-holland · Pull Request #671 · electro-smith/libDaisy · GitHub

With this in place I was able to flash to QSPI using the bootloader. I’ve made a VSCode task that simplifies this, because I wasn’t fast enough sometimes to flash after the bootloader started.

    {
      "command": "make clean; make; make program-boot; sleep 2; make program-dfu",
      "label": "build_and_program_boot_and_dfu",
      "problemMatcher": [],
      "type": "shell"
    },

I’m having errors myself now trying to keep the main program in FLASH, but store some larger arrays in QSPIFLASH, I alway get dfu-util: Last page at 0x90087333 is not writeable errors.

1 Like
47

thanks @Xavier2069,
I’ll check it out with my project. Hope it’ll work..

1 Like
48

@Xavier2069 it didn’t help, unfortunately.
I reproduced steps described here, and I see glowing which means boot loader is flashed successfully.
Also, I re-cloned DaisyExamples repo with all the submodules to be sure everything is up to date. No changes..

49

Did you flash while it was doing the slow glow?
By the way, you can extend the grace period indefinitely by pressing the BOOT button as oultined here Daisy Bootloader - Daisy.

During that grace period (and with Daisy connected to your computer via USB), you can run make program-dfu and it should be working.

50

I am having this issue right now. It started by failing a few times and working others, now I can’t do a DFU anymore to the Daisy.

Erase   	[                         ]   0%            0 bytesdfu-util: Error during special command "ERASE_PAGE" get_status
make: *** [program-dfu] Error 74

This is with the latest libdaisy.a built from the master branch from github. Using the 6.3 bootloader.

Is my Daisy faulty? Bricked?
I’ve only been using it for two weeks, does it have a limit to QSPI flashing?

51

Also tried the Web programming tool. It goes to ‘connecting to Daisy’ but nothing else happens. It says DFU in FS mode.

52

I am wondering whether the QSPI flash has a limit to the number of times it can be erased/rewritten.

I tried the ST32CubeProgrammer and I cannot erase it, but I can download the program without erasing. It won’t run though.

53

Thank you for the wait, and we’re sorry to hear that you’re running into an issue erasing QSPI.

Here’s a tester program to see if the QSPI is working as expected or not:

  1. Flash the attached binary file to the Daisy Seed using the Web Programmer
  2. Go to a serial monitor (we recommend this site)
  3. Click Connect and select the “Daisy Seed Built In” option
  4. Uncheck the “send with \r” option
  5. Type: QSPI into the text entry and hit enter

If it’s working, it should pretty quickly output:

QSPI
Test Message:
Test: QSPI
Result: Test Requested
Extra Data: 0
Test Message:
Test: QSPI
Result: Test Pass
Extra Data: 0

Please let us know what output you see, thanks!!

DaisyTesterV2_DUT_v1_3_1.bin.zip (62.7 KB)

54

Thanks for this.

I got

Daisy is online
===============
Test Message:
	Test:	QSPI
	Result:	Test Requested
	Extra Data:	0

and nothing else after that. Does it mean the QSPI is toast?
I had the Pod for literally two weeks, I am surprised I would have run the limit (1-10k erases).