Hi and welcome aboard!

There was no updated bootloader release because there was no changes to bootloader since previous release. So using old one is the correct thing to do. Regarding UART error:

Do you have anything connected to serial MIDI port? That’s what used by UART peripheral. I think there were some problems in previous release (22.0) related to it that should be fixed in 22.1. So try disconnecting whatever is using MIDI ports before booting OWL if you run 22.0.

You should see updated version in “CONNECTED TO: Owlsy v22.0” when you run latest firmware, make sure that it says 22.1. Otherwise it could be that you haven’t flashed 22.1 successfully (i.e. MIDI data got corrupt).

I think this error would mean that serial MIDI doesn’t work, but everything else should be fine. You can clear error message by clicking encoder, turning it to the right until you see “Status” menu and clicking there.

Hi, thanks for the quick reply

I dont have anything connected to the midi port, maybe its the sysex librarian that im using to upload DaisyPatch.22.1.0.syx (which sysex librarian is giving me an error saying the file is too large)

If i upload DaisyPatch22.0.0 with sysex librarian does not give any errors when uploades de 1378 bytes, and i get the Owlsy logo on the Daisy Patch Screen

So with sysex librarian closed, i open the Owl webpage and i get the same UART error, no other app is using midi at the moment

How can i upload the DaisyPatch.22.1.0.syx without Sysex Librarian?

I think i have seen another utility mentioned:

https://www.openwarelab.org/Tools/firmware.html

but when i try to upload the 22.1.0 syx the console of the tools says sending data but hangs there…

It says:

Connected to Owlsy v22.0

I reset To bootloader
I press reload page and the console says:

Firmware version: Daisy Boot v22.0

Program Message: Invalid SysEx
*I choose file - DaisyPatch22.1.0.syx
*I press flash firmware and the console says:

Reading file DaisyPatch.22.1.0.syx

Sending data 344412 bytes

And it stays there…

I think im goiing to restart both computers and the daisy patch and make sure there is no background midi somewhere.

Ill let you know how i do, thanks a lot for your help and support

Edited:

After closing all apps and going to https://www.rebeltech.org/patch-library/device

It recognises it as Owsly v22.1
CPU : 0 % Memory
Message : Storage Used 0 Deleted 0 Free 786.

I think that did it

Thanks a lot @antisvin for your feedback and support.
This port of owl is great.
What changes would be neccesary for daisy field to work with owl patches?
Gracias

Thanks @antisvin !
Im going to get to learn the in and outs of the Electrosmith Platform and i see if can gather enough knowledge to consider this port to Field.
All those OWL patches will keep me busy for sure!
Thanks

Hey hey,

Sorry I was away for such a long time. That happens when you get a child haha

So but yeah thanks again for you’re worked. The owlsy patch was working as a multi drum module in my drum rack.

But I have one question my friends, after such a long time not here in the forum I forgott how everything wprks haha no jokes aside. I want to give oopsy and max gen a chance and now I ask myself, how do I get my daisy seed back to the original daisy firmware? Kinda like a firmware reset.

Like I mentioned several posts before, I’m not a coder haha but I hope that works easy?! Never thought about how it works to go back to the original firmware/boot. Haha

Thanks for you’re help boys and girls.

Franky

It sounds like you only need to install bootloader again, you can just flash it with DFU. This is the last boottloader image - https://github.com/antisvin/OpenWare/releases/download/owlsy-v22.0.0/MidiBootDaisy.v0.2.bin

OWL firmware and patches are on the QSPI chip, so they should be still there if you were just flashing oopsy that can’t access QSPI.

Not yet. There’s no support for SD cards in upstream firmware and I haven’t got it to work yet. It will happen eventually.

Note that you can read data from QSPI storage, this is currently supported by C++ and FAUST patches. 8MB is plenty for using short samples, wavetables, etc. Patch integrations are not specific to Daisy are all handled by code in upstream OwlProgram repo. And when there would be support for reading SD cards in this firmware fork, it would still require to be supported by patch integrations to be usable. What I mean is that currently there are a few API calls for reading data that work with flash, later they would allow loading data from SD card as well - so any patch that reads resources from flash would be able to use SD card.

Thank you for all your work making this work! I’ve been dreaming of a multi-FX module and this fit the bill perfectly.

I am having one tiny issue I’m hoping you or someone could help with. Instead of buying a Daisy Patch, I bought a Seed and built a module based on the Daisy Patch schematics. Obviously, I’m in somewhat uncharted territory here, but I’ve built my module pretty close to spec. However when I loaded Owlsy, the OLED stopped working. I had a couple screens laying around and neither worked. I used an SH1106, but the screen just put out static. I also tried a SSD1306 which I saw referenced in the Daisy documentation. That didn’t work at all. Both of these OLEDs worked when I was using stock firmware, so I imagine that there is issues with drivers.

Anyway, I am pretty clueless when it comes to software etc so I’m kind of grasping at straws. Is there any way to make my OLED work? If not, what is the correct OLED? I can’t find what specific type Electro-Smith uses for the patch…

I was able to figure out how to change patches without the OLED so I can make the module work, but obviously having a screen would be better.

Thank you!!!

Hey @moonfriend ,

It’s cool to see someone using this for a custom hardware. Regarding OLEDs, AFAICT SH1106 only differs from SSD1306 in that it doesn’t support some graphic memory addressing modes. I’m not sure yet if those modes are what the OWL firmware uses, but I’d suggest trying to get SSD1306 as they are known to work. I think that whatever prevents it from working for you might be not software but hardware related. Software wise, we’re just sending some commands to configure OLED controller and update graphical buffers, there’s not much to change here once it works for a particular controller.

You might try building firmware with lower SPI clock for your display to see if that makes any difference. That would require changing this line to use SPI_BAUDRATEPRESCALER_16 to make it run at half speed.

If you’re curious about all display options, here’s what you can consider:

SSD1306/1309 (SPI, monochrome, from upstream firmware, use on Daisy Patch and RebelTechnology Magus). I think those displays would be interchangeable.

SEPS114A (SPI, color, used in upstream firmware for unreleased hardware and might be hard to find)

another SSD1309 used with I2C, made it for KxMX bluemchen.

ILI3941 (not in OWLsy repo, but can be added if necessary). a bit challenging to work with as it’s large and has some special requirements, but I’ve mostly got it working in another version of OWL.

Interesting, I’ll give the clock change a try. I’m kind of learning as I got, but I can probably figure it out! Do you know which OLED the daisy has specifically? I see you mention that the 1306 and 1309 should be interchangeable, but I saw that other people in the forum have had some trouble with the 1306 and since my own 1306 isn’t working, I wonder if the Patch has a 1309. I also saw that there is some code in the binaries that you posted that reference the 1309 specifically. Maybe I’ll just search for one on ebay or whatever. Like I said I am able to work with what I have for now!

The only other thing that I’ve changed from the Patch schematic is that I am powering the OLED off of the Daisy’s 3v3_D power supply instead of using a dedicated switching power regulator. Again, that worked fine with the stock Daisy Patch set up, but I wonder if that is a factor.

Anyway, I don’t want to take up your time with this, you’ve already provided a great utility! Greatly appreciated!

I don’t mind helping with this a bit, no worries. It’s interesting where your effort would lead to.

So I did a bit more research. As expected, SH1106 won’t work out of the box with OWL as that controller only supports page addressing mode, while OWL maintains its graphical buffer in format that should be sent with vertical addressing mode. So it’s not compatible due to different pixel layout and changes required to support that display are outside of low level display driver.

SSD1309/1306 are supposed to be compatible in software, so I’d expect you to be able to use both with identical hardware setup. OWL driver was made for SSD1309, but LibDaisy lists both controllers as supported in their drivers. I couldn’t figured out which one is used on Patch based on Daisy hardware docs and would rather ask @shensley than take off the panel. But I don’t expect that to make any difference in this case.

Now about regulator, that might be the culprit here. I’ve noticed that libDaisy enables it with 0x8d, 0x14 command and it’s not used in OWL. You might try adding it around here: OpenWare/ssd1309.c at daisy · antisvin/OpenWare · GitHub . I’m not too familiar with details of this as had the hardware working out of the box on Daisy Patch, so something else might have to be tweaked in OLED setup commands. Btw SSD1309 doesn’t have that command in datasheet, but this might mean that it always enables it and can be included in driver usable for both devices.

Also, you might end up using external regulator either way in case if the internal one ends up generating too much noise. That’s fairly common with OLEDs.

Thanks, this gives me something to look into. Though to be honest I’m quite clueless with writing and compiling code. I spent about an hour or two looking through the binaries and trying to make sense of how to edit and recompile everything without much luck. No problem though, your explanation gives me something to go on if I have some time to really commit to learning. In the meantime, I still have a completely usable module, which I’m very happy with.

If I ever get improved, I’ll be sure to let you know!

Having a working display makes a huge difference in usability on Daisy Patch, so I’d suggest not to give up on that!

I can make a custom build to try those fixes if all else fails, but would prefer people to experiment on their own. And getting familiar with firmware could let you experiment with modifying hardware later too. In most cases you won’t even have to edit code, but enable various features in config file.

Actually building firmware is fairly easy, you just need a working ARM-GCC toolchain for your OS and the rest is a matter of calling GNU make with correct arguments. I can help with that a bit if you have problems.

Yeah I think I’d prefer to be able to learn too. Maybe you can give me one more push in the right direction. Here’s what I did so far (I’m on windows 10):

Cloned your GitHub and initiated the sub module

Downloaded and installed the ARM tool chain

Put in the directory location of the toolchain in the common file

Downloaded GNU Make (4 files with unfamiliar file extensions) but had no idea what to do with those files so I put them in the Daisy patch folder

Tried running “make” in git bash in the Daisy patch folder. Got some errors about missing freeRTOS.h

Did some research on freeRTOS and downloaded that, but I started to get the feeling that I was going in the wrong direction and stopped there.

All the documentation for GNU Make was kind of like reading a different language haha. So maybe you could give me the dummy’s version how to call GNU Make etc. should I use something other than git bash? Do I need to edit any files etc?

If I can get this working I think I’ll be pretty set to experiment and figure things out for myself.

You don’t need to install freertos separately, you probably haven’t called “git submodule update --init” in repository root that pulls it as a subrepo.

Regarding building, something like “make clean sysex” should give you firmware in “Build/DaisyPatch.syx”

Ah yeah, I did run the submodule init but for whatever reason it didn’t update the Library folder, so I downloaded that from your github manually. Is there anything special I need to do to call GNU Make? Do I need to put the files in a specific directory? (EDIT: Never mind, I think I was able to add this to my system Path, still getting some errors that I’ll work on though). Also, let me know if you want to move this conversation to a DM so this thread doesn’t get too muddled.

EDIT 3: I stuck with it and got close, everything was compiling nicely but now this is the error I receive:

$ make clean sysex
mkdir ./Build
process_begin: CreateProcess(NULL, ~/2020-q2-update/bin/arm-none-eabi-g++ -c -O2 -nostdlib -nostartfiles -fno-builtin -ffreestanding -fdata-sections -ffunction-sections -fno-builtin -ffreestanding -DDAISY -DDAISY_PATCH -mtune=cortex-m7 -DOWL_ARCH_H7 "-DGIT_REVISION=\"master a2db5a6 Release\"" -fno-rtti -fno-exceptions -std=gnu++11 -mcpu=cortex-m7 -mfloat-abi=hard -mfpu=fpv5-sp-d16 -mthumb -fsingle-precision-constant -I./../Libraries/Drivers/CMSIS/Include -I./../Libraries/Drivers/CMSIS/Device/ST/STM32H7xx/Include -I./../Libraries/Drivers/STM32H7xx_HAL_Driver/Inc -I./../Source -I./../LibSource -I./Inc -I./../Libraries/Middlewares/ST/STM32_USB_Host_Library/Core/Inc -I./../Libraries/Middlewares/ST/STM32_USB_Device_Library/Core/Inc -I./../Libraries/Drivers/STM32_USB_OTG_Driver/inc -I./../Libraries/Middlewares/Third_Party/FreeRTOS/Source/include -I./../Libraries/Middlewares/Third_Party/FreeRTOS/Source/portable/GCC/ARM_CM7/r0p1 -I./../Libraries/Middlewares/Third_Party/FreeRTOS/Source/CMSIS_RTOS -I./../Libraries/Middlewares/Third_Party/FreeRTOS/Source/CMSIS_RTOS_V2 -I./../Libraries/Middlewares/Third_Party/FatFs/src -I./../Libraries/Drivers/CMSIS/DSP/Include -DSTM32H750xx -DARM_MATH_CM7 -D__FPU_PRESENT=1 -Wa,-a,-ad,-alms=./Build/callbacks.lst ./../Source/callbacks.cpp -o Build/callbacks.o, ...) failed.
make (e=2): The system cannot find the file specified.
make: *** [../Hardware/common.mk:59: Build/callbacks.o] Error 2
I feel like I’m close. I’ll keep at it but let me know if you have any ideas. Thank you!
EDIT 2: I think I may be setting the TOOLROOT incorrectly in common.mk. I assumed that I just copy and paste the location of the ARM folder like so:

`TOOLROOT ?= C:/Program Files (x86)/GNU Arm Embedded Toolchain/9 2020-q2-update/bin/
But maybe I'm wrong. The error I get when I do "make clean sysex" in the Daisy Patch folder is:
mkdir ./Build
/usr/bin/sh: -c: line 0: syntax error near unexpected token `('
/usr/bin/sh: -c: line 0: `C:/Program Files (x86)/GNU Arm Embedded Toolchain/9 2020-q2-update/bin/arm-none-eabi-gcc -c -O2 -nostdlib -nostartfiles -fno-builtin -ffreestanding -fdata-sections -ffunction-sections -fno-builtin -ffreestanding -DDAISY -DDAISY_PATCH -mtune=cortex-m7 -DOWL_ARCH_H7 -DGIT_REVISION='"master a2db5a6 Release"' -O2 -std=gnu99 -mcpu=cortex-m7 -mfloat-abi=hard -mfpu=fpv5-sp-d16 -mthumb -fsingle-precision-constant -I./../Libraries/Drivers/CMSIS/Include -I./../Libraries/Drivers/CMSIS/Device/ST/STM32H7xx/Include -I./../Libraries/Drivers/STM32H7xx_HAL_Driver/Inc  -I./../Source -I./../LibSource -I./Inc -I./../Libraries/Middlewares/ST/STM32_USB_Host_Library/Core/Inc -I./../Libraries/Middlewares/ST/STM32_USB_Device_Library/Core/Inc -I./../Libraries/Drivers/STM32_USB_OTG_Driver/inc -I./../Libraries/Middlewares/Third_Party/FreeRTOS/Source/include -I./../Libraries/Middlewares/Third_Party/FreeRTOS/Source/portable/GCC/ARM_CM7/r0p1 -I./../Libraries/Middlewares/Third_Party/FreeRTOS/Source/CMSIS_RTOS -I./../Libraries/Middlewares/Third_Party/FreeRTOS/Source/CMSIS_RTOS_V2 -I./../Libraries/Middlewares/Third_Party/FatFs/src -I./../Libraries/Drivers/CMSIS/DSP/Include -DSTM32H750xx -DARM_MATH_CM7 -D__FPU_PRESENT=1 -MMD -MP -MF"Build/freertos.d" -Wa,-a,-ad,-alms=./Build/freertos.lst Src/freertos.c -o Build/freertos.o'
make: *** [../Hardware/common.mk:56: Build/freertos.o] Error 1