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
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
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
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
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
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
thanks @Xavier2069,
I’ll check it out with my project. Hope it’ll work..
1 Like
@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..
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.