Is a ‘dead’ Seed that has had the blink example thus loaded, and then powered off and on still ‘dead’?
Yes, with the blink example loaded post-getting in this ‘dead’ state, They still take 3-5 seconds to launch the blink code.
Interesting point. I suspect that whatever is happening is messing with the initialization of the qspi, which is why applications built using the daisy bootloader do not launch. If I load the qspi seed example, code execution continues until the first qspi interaction, at which point the board immediately freezes.
I’ve got some STLink programmers on order so I will also be able to step through the code soon. My hunch right now is it is a problem with the clock switching
1 Like
If you’ve got the bandwidth for a test of a different bootloader option, (while you have a board in the ‘bad’ state (mine reverted to ‘good’ so I can’t do it)), it woudl be great if you could you please test this (in the ‘booter_dev’ branch):
MidiBoot-Seed.bin
in:
Just left the office with the boards. I’ll try this out tomorrow and see what happens. From the git commit message, looks like the user LED should turn on immediately, and then it’ll show up as a usb midi device correct?
yes, that’s correct, and thanks for doing this!
The owlsy bootloader starts up, the led immediately turns on, but then there is that same 3-5 second delay between that and the blinking.
How quickly is it enumerating? For me, it happens basically instantaneously. Three’s a little delay before the LED starts blinking for me (I don’t know this code that well yet to know what to expect).
One other idea: You could try configuring the Blink demo code to run at 400 MHz instead of 480, just as another datapoint…
I’ve figured it out. The delay occurs during the initialization of the qspi. At some point, one of the commands sent to the qspi put it into write protect mode and it is unable to be set into quad-spi mode until the write protect is disabled by pulling the WP pin high while performing a write to the flashes status register.
I think the reason why it can magically work again after a bunch of powerups is that during the qspi initialization, all the pins are configured as outputs before sending the commands, but the fall time to ground might not be constant, so it could at some point read as logic high while the write status register command gets sent, pulling the flash out of write protect mode.
I’m going to work with E-S to get a software solution into libdaisy
1 Like
Wow, nice work! And what a relief! And that explains the bi-stable states!
I wonder if we can get E-S to also make the bootloader more robust to failed/interrupted updates? (e.g. mark it as ‘invalid’ with a fuse bit, then download, and then check the checksum, then marks as ‘valid’)
Hi, @MichalC , just checking in to see if you’ve heard of updates about this issue? Thanks!
Yeah @TallMike, E-S and I are still going back and forth figuring out more about, and fixing this behavior. We’ve gone through a couple iterations of the bootloader, and have been able to fix the write protection on the qspi, but there are still intermittent problems jumping to the app code while using BOOT_QSPI that we are working out
Sounds like progress! Do you think there’s any way to add a final ‘checksum’ / validation to the DFU firmware update process so that if it’s interrupted or something goes wrong, it will stay in the bootloader?
@MichalC, any new news from E-S?
Yes, they’ve got a fix. The CTO is on vacation next week, but soon after returning, they will be creating a bootloader v6.3 and pushing changes to libdaisy.
1 Like
Any updates on this? I’ve just received a couple of submodules and one of them appears to be having this issue.
If I program and run using the STM32CubeProgrammer it works, but as soon as it gets power cycled/reset it locks up.
1 Like
Any updates ? I’ve got a soldered daisy showing this exact behaviour and it seems that I cannot get it up and running even though I’ve tried many power cycles.
thanks
There is a fix, but not sure if it’s been incorporated into things yet, hopefully someone from E-S will respond…
1 Like
Maybe also try the ‘contact us’ on their main page:
Thanks, I tried the contact form.