Witch with OWL 3


I got a Witch (DIY kit from Befaco), and I upgraded the OWL to mk 3 (it came with an OWL mk 2). The OWL came from Befaco with the Lich3 firmware.

Using the firmware upgrade tool I tried to upload the Witch firmware I got from here using the Witch.syx file. Which did not work. What I get (after flashing the with firmware) is still " Firmware version: OWL Lich3 Boot v22.5.0 " and " * Program Message: Invalid resource " when on the firmware update page.

Next, I got the code from Github and compiled. I then tried to update the board with the Witch3.syx file I get from compiling (also used the FirmwareSender). I thought the “Witch3” project is for the the Witch with OWL 3. This didn’t work: after trying this I could not connect to the board anymore: I could not even see the USB device registering on the kernel.

I’m running Debian 12.2 (stable)

Then, I followed the hints from here, used an ST-Link V2 to connect to the owl board and (with the gui application) flashed again with the MidiBoot-Lich3.bin file. I got then the OWL board back and I could see it in the system.

I also tried to flash the board directly with the Witch.bin or Witch3.bin files I got from compiling the OpenWare gihub repository I mentioned above. Neither did work.

So, my question is: How can I use the OWL mk 3 with the Witch?

Thank you for your help!

P.S. I would be very helpful to have an updated pinout diagram for the OWL 3!

1 Like

There’s no official release for Witch3, although they have a pre-release build that is being installed for currently sold Witches. You could try to get in touch with their support if @Befaco won’t offer us an update here.

Regarding bootloader, it’s mostly compatible between OWL3 devices. The difference is typically in which pin is used to force bootloader mode, which will is usually not important as you can force bootloader by MIDI or it will switch to bootloader mode itself if firmware crashes on boot. And with ST-link you can flash firmware if necessary, so that’s not a big deal either way.

Regarding not functional USB - this is something that happened to me in the past. I got it resolved by switching Libraries submodule to a different revision (9e8f64e07b7a64b76de32f67c164ecf9068b728c), so you could try that since you sound like you understand what you’re doing :wink:

As for pinout, I don’t know too why it wasn’t addressed for OWL2/3, while it was decently documented decently for OWL1 and Xibeca. Maybe it’s just due to lack of interest from the users, are you planning to do some kind of modding?

@antisvin you wonderful person! :wink:

Regarding not functional USB - this is something that happened to me in the past. I got it resolved by switching Libraries submodule to a different revision (9e8f64e07b7a64b76de32f67c164ecf9068b728c), so you could try that since you sound like you understand what you’re doing :wink:

It took a bit of time to understand that you actually mean the “feature/h7-usbh-nak-fix” branch ;). Re-compiling using this branch for the libraries and then converting the Witch3.bin file to .syx with the FirmwareSender worked.

So, for completeness: what I did was: with flash ST-Link V2 the MidiBoot-Lich3.bin file. Then, using the “normal” firmware upgrade tool" upload the newly compiled Witch3.syx file. After this, the witch appears in the system as “OWL-WITCH” and is seen by with online tools.

I’m still not so sure that everything works properly though: I have no time to test it now, but will do in the next days: will let you know.

P.S. It would be useful to know why only that branch of the libraries works. And also: I tried to flash the Witch3.bin file directly on the OWL using the ST-Link, but this did not work: any idea why? Shouldn’t it work? Or am I misunderstanding something?

Yes, it would be interesting to hear if there are anything wrong with that branch. The short story is that last firmware release was made after upgrading those libraries to a newer version and I believe some changes where made to “improve” USB audio. But result is that it’s no longer working, not sure why. So my solution for that was to use just something I had before that was known to at least work until we have a proper firmware release.

Yes, remember that we have a firmware and bootloader. When you build the firmware, it’s configured to be written after the bootloader and that effects addresses used for various data. We don’t have anything like virtual memory on desktop OS, so raw pointers to flash will enevitably be a part of firmware code.

You most likely were trying to flash it to beginning of flash, but that’s where bootloader lives normally. You have two options here - either customize LD script to use flash from the very first sector or just flash it to correct address (0x08020000 instead of 0x08000000). The latter makes more sense and IIRC you can do it by specifying address in the end of openocd command arguments.


Thank you very much for your explanation regarding bootloader / firmware. That makes sense now.

In the meantime I got some time to test and experiment a bit more. Unfortunately it’s sill not working properly.

First I tried flashing with the firmware by compiling the current master branch of the git hub repository and, as you suggested, using the feature/h7-usbh-nak-fix branch of the libraries. This gives ma a valid, working OWL witch. However, testing with a very simple pd patch, I notice that parameter inputs do not work as expected: names do no correspond and some parameter inputs do not work at all.

The next thing I tried is to switch to the feature/witch3 branch for the OpenWare repository and recompile. That again, gives me a valid firmware. Further testing, things seem to work a bit better. Paramters correspond and work. BUT, as soon as I push any of the 4 buttons the witch freezes immediately and resets. Same thing happens if I patch a cord in the lower “1 2 3 4” named patch positions. This also happens with the firmware I get when compiling the feature/witch3 branch with the master branch of Libraries.

At first I thought I might have a soldering problem somewhere (shortcircuit, this is a diy), but could not find any problems. ALSO, this (the freezing) does not happen when using the firmware compiled with the master branch of the OpenWare repository. So, I think this cannot be an electric problem, but a problem in the firmware. What do you think?

Do you have any pointers as the where I could look further? Or test further?

It probably makes more sense to test with official patches from the Witch site. Even though I would expect them to give the same problems.

It sounds like dealing with this yourself would be too complicated (figuring out which pins are misconfigured for ADC, troubleshooting failure on button press, etc). And I don’t even have a Witch myself to test the firmware. So I’ve pinged Manu&Martin about this issue, hopefully that would bring a proper firmware release sooner.

Yes. I tried the Witch official patches and the witch template in the patch library. But, as you expected, similar problems.

I would be willing to look into this even myself. I would however be happy to have a bit more information regarding the OWL mk 3. Pin out, schematics, etc. I can’t seem to find much… I could deduce everything from the STM Cube files, compare with the old OWL mk 2 sources and the more recent working versions of the OWL mk 3 for the Lich…but it will just take more time… :wink:

Let’s see if I can get someone to release info about OWL3 pin mapping. It’s not supposed to be a secret as it was done for OWL1 and Xibeca, most likely it never happened because it was a low priority thing.

Regarding that buttons problem, you should try to make a debug build (by setting CONFIG=Debug environment variable when build) and see what happens when you press them. There are 2 possibilities:

1.Try to pause and see what happens before firmware resets on button press. If impossible, you would have to place a breakpoint, most likely in EXTI interrupt handler or code that updates buttons

  1. It might be some unhandled interrupt (EXTI most likely), then you would end up in the default interrupt that also happens to be an infinite loop. It’s implemented in assembly in startup file, so you will notice that you’re not running normal OWL code.

To run this in gdb you have 2 choices:

  1. Keep the bootloader, send the debug build via sysex and expose its symbols. You will actually flash bootloader rather then firmware and this can be a bit glitchy, but allows you to run with unmodified linker scripts.

Something like this should be added in case of vscode:

            "postLaunchCommands": [
                "monitor arm semihosting enable",
                "add-symbol-file Magus3/Build/Witch3.elf 0x080202c0"

Address must be pointing to the beginning of your .text section and it might be a bit different, so check ELF file details to confirm. And yes, you will need semihosting to be enabled for running debug builds and you can use printf() for logging if you wish so.

  1. https://github.com/RebelTechnology/OpenWare/blob/master/Hardware/owl3.ld#L27 - change origin to be 0x08000000 here. Then you will be flashing firmware directly, without installing bootloader at all. I think this approach works too, also a few uncommon functions would end up broken. I.e. we store some metadata in the end of bootloader - things like protection bits for flashing firmware via sysex and some other metadata. But it probably won’t be a problem for debugging this issue as this is used as response to requests send over MIDI.

  2. You might be able to configure openocd to flash to 0x08020000 and it would catch up once you exit bootloader. Never tried this myself, but it seems like it would be a good approach if it actually works.

Using vscode + cortex-debug plugin is highly recommend, here’s what I have in vscode config for another project:

            "type": "cortex-debug",
            "request": "launch",
            "servertype": "openocd",
            "cwd": "${workspaceRoot}",
            "executable": "MidiBoot3/Build/MidiBoot-Magus.elf",
            "name": "Midiboot3 Magus3 boot",
            "device": "STM32H743ZGT",
            "svdFile": "/home/antisvin/.platformio/platforms/ststm32/misc/svd/STM32H7x3.svd",
            "armToolchainPath": "/home/antisvin/gcc-arm-none-eabi-10.3-2021.10/bin/",
            "gdbPath": "/home/antisvin/gcc-arm-none-eabi-10.3-2021.10/bin/arm-none-eabi-gdb",
            "configFiles": [
            "runToMain": true,
            "postLaunchCommands": [
                "monitor arm semihosting enable",
                "add-symbol-file Magus3/Build/Magus3.elf 0x080202c0"

Setting svdFile might not be necessary, also toolchain/gdb paths might not be necessary if you install ARM-GCC globally.

@antisvin Thank you very much for your help! Sorry I was (still am) sick and could not look into this more. I will very soon.

Just a quick question: do you know if it would be possible to do this debugging with the STM32CubeIDE? I see the project files in the repository and I have used that wonderful (sarcasm) program in the past…

Also: I asked befaco support if they have a pre-release version of the OWL 3 Witch firmware, but they don’t. They also said that they only sell Witches with the OWL 2, not the 3.

No hurry and hope you’ll get better soon.

Maybe. There are projects for CubeMX, but they are used only for generating project code. I recall trying CubeIDE (the Eclipse-based part) for something not related to OWL in the past and it was pretty inconvenient to use. I don’t even know if CubeMX projects are usable by CubeIDE or not.

I highly try vscode + cortex-debug plugin as this is probably the best way to work with embedded nowadays, or at least the best among software available free of charge. It may not be perfect, but at least you won’t have to use sarcasm to describe your experience - no doubt that most software coming from ST is pretty horrible.

This somewhat contradicts what I’ve heard from Manu. But either way, there probably can’t be anything different to what you’ve already built yourself.

So! I think I got it!

Yesterday I did some debugging and experimenting with a colleague and we found out that there’s not problem with the code at all! The problem seems to be the version of the arm gcc compiler. I was using the arm-none-eabi-gcc version that comes with the debian packages: which is version 12.2. We tried with the more recent version from the arm website (13.2.): in this case compilation fails.

But, compiling with the older version, 10.3. from here: Downloads | GNU Arm Embedded Toolchain Downloads – Arm Developer, works! At least I don’t get anymore the freezing problems! I still have to do an in depth test (also because patches page is offline), but all seems fine now.

This should be definitely documented somewhere!

Hm, so I’ve rushed with those debugging instructions after all :wink: Anyway, I’ve used 12.2/12.3 to build working firmware before, but not for Witch. No idea about 13.x, but generally regressions from compiler upgrade are not uncommon.

@antisvin those debugging instructions where very helpful! in getting those to work we found out about the compiler version differences.

Yes, compiler regressions are not uncommon. However, documenting this in the OpenWare repository README could save other people some time … :wink:

Thank you for all your help!