Ahh, spaces and parentheses in a file path. Grrr.
No, you don’t need to use CubeMX for this, this is only required for setting up a new project. The syntax error is likely because of the bracket in the directory name that doesn’t get escaped somewhere in Makefile
Hmm, the repository itself is in C:\GitHub\OpenWare_Owlsy\OpenWare_Owlsy so no spaces there, I forgot the escapes in TOOLROOT but after changing that I still have the same error 
Did you escape the parens?
I think so? This is my TOOLROOT:
TOOLROOT ?= /c/Program\ Files\ \(x86\)/GNU\ Arm\ Embedded\ Toolchain/10\ 2021.10/bin/
I’m out of ideas, I haven’t tried building this, and don’t have Windows.
It looks like even resetting parameters to unlocked state when a new patch is running won’t help with FAUST code. The problem is that setting parameter value would leave it in locked state again and that’s what every FAUST patch does on startup using parameter’s default value. There’s no standard way to disable this behavior.
For the time being I’ve made a firmware build that just disable locking altogether, since you’ve asked about something like this. But this means that you won’t be able to control parameters A-D with MIDI. With the next firmware release I’ll try to make it possible to enable/disable parameter locking on device via some knob combination in its configuration mode. But I’ll have to think what could be done here and also consider this behavior on other devices, so it might take some time to be ready.
Firmware build without takeover is here - https://filebin.net/lchzhlyys8waov3b/PatchInit.syx
I tested the firmware build and it works great, thank you! 
I´m just trying to flash a new Daisy Seed 65MB. But don´t work compared to the 1MB-Version. Bootloader Daisy Boot v24.0 can be flashed. But at OpenWareLaboratory the Bluemchen.sys can´t be flashed reliably. Even if it says…
- Program Message: Firmware upload in progress
- Program Message: Firmware upload complete
…after all it says: - Program Message: Unexpected firmware reset
Tried it a dozen times…
Anyone have an idea, if there is something blocking to finalize the flashing of the Bluemchen.syx at the 65MB-Daisy Seed?
Thanks for any hint!
I experienced this as well, for me the solution was to flash 25.1rc instead of 24.0
Interesting!
I found this one: v25.1 not v25.1rc: MidiBoot-DaisyPod-v0.4.bin
It´s not correct I think, since it is called DaisyPod and not MidiBoot-Bluemchen-v0.x.bin? But I didn´t find anything else on github here: Releases · antisvin/OpenWare_Owlsy · GitHub
Do you have a link please?
And for the latest Bluemchen firmware I found this one: Bluemchen-v25.0.syx
My bad, I meant v25.2-rc1
Which Daisy Seed hardware version are you using? Currently only 1.0/1.1 is supported, 2.0 should probably fail to run. If it won’t fail, there would be no sound due to different codec.
As for 1 MB version, I think SDRAM is used to store patch code before flashing them. So you won’t be able to use it as is. It’s not impossible to adapt it to run without SDRAM (and I have a version of OWL for another H7 board that only has internal SRAM), but I’m not sure if it’s worth the effort when a version of Daisy with memory chip is readily available.
I have a Seed 1.2 (or rev7? Not sure why 2 version numbers are present)
Ok, so rev7 is the new version with PCM3060 codec that I haven’t tested yet with OWL. But the datasheet says it’s supposed to be backwards compatible with rev4 and effectively presents itself as Seed v1.0 board. This is because the codec is used without I2C control and is compatible with “dumb” AK4556 codec that also doesn’t have digital control or initialization.
I’m not 100% sure that it’s going to work with current firmware or ends up running into some problem due to some differences with how hardware is used compared to libDaisy. I’ll probably order newer Seed version for testing, meanwhile somebody here might confirm if they’ve used OWLsy with rev7 hardware successfully.
Yess I used the rev7 here in this video with Owlsy! https://youtu.be/yTlH4q4axp4?si=-f9TWvxU-febvjvG
But only 25.2-rc1 worked for me, not 24
I couldn’t load all patches and a manual gate in trigger causes a crash but I don’t think that is codec-related
Which hardware gave you that trigger issue? I don’t quite follow you, since Blumchen has no gate inputs.
Let me make a video, that is probably helpful 
Ah, totally forgot about that feature, that’s why it didn’t get tested frequently. It’s just that there are many patches in Rebeltech library that use pushbutton since it’s present on most of their hardware, this makes them usable to some extend. I’ll check what’s the problem with it.
Sorry for the delay, but I needed to finish the Bluemchen hardware to do further tests. So here are the details:
- I bought recently two Seed 1.2 rev7. A 1MB-Version and a 65MB-Version (tho I don´t see any difference on the PCB).
- The 1MB-Version could be flashed and work without an issue.
- I got the 65MB-Version finally flashed in the same way, but it seems not correctly. Here are the details:
a) Used Chrome and Daisy Web Programmer to flash MidiBoot-Bluemchen-v0.3.bin
b) Used Chrome and OpenWareLaboratory to flash Bluemchen.syx (latest from v25.2 RC1: Releases · antisvin/OpenWare_Owlsy · GitHub)
c) Used Chrome and used CONNECT TO DEVICE here: OWL Patch Library – Rebel Technology
At first OWL-BLUEMCHEN was recognized.
d) Tried to load/store this patch: OWL Patch Library – Rebel Technology
Failed I think, or at least Bluemchen firmware was no more recognized. Only the bootloader.
e) Back again: CONNECT TO DEVICE here: OWL Patch Library – Rebel Technology
Only the bootloader was recognized.
Any idea, why the 65MB-Version of Daisy Seed 1.2 don´t work? Thanks for any hint!
Here are some pics of the process to visualize:
