Building the Magus firmware: 2022 edition

Hello, I have what I think is the first generation of Magus (from 2019?), there was a long thread before where I received some help on building and uploading OpenWare for the magus. I wrote this guide summarizing what I found.

Today I checked out the v22.4.0 tag and attempted to do a build. (Because I installed the special “watchdog” bootloader at some point, afaik I cannot install the public releases from the github page; also because of this I specifically added #define USE_IWDG to the end of Magus/Inc/hardware.h).

I got an error:

Andi@Alita:/mnt/c/Users/Andi/work/gh/OpenWare$ make magus TOOLROOT=
make[1]: Entering directory '/mnt/c/Users/Andi/work/gh/OpenWare/Magus'
make[1]: *** No rule to make target 'Inc/usb_device.h', needed by 'Build/main.o'.  Stop.
make[1]: Leaving directory '/mnt/c/Users/Andi/work/gh/OpenWare/Magus'
Makefile:63: recipe for target 'magus' failed
make: *** [magus] Error 2

How should I proceed?

I see there is a Inc/usb_device.h in the Magus3/ directory, but I usually build out of Magus/. I assume Magus3 refers to a new hardware revision and I shouldn’t use it?

My questions:

  • How do I get the Inc/usb_device.h? Should I copy the one from Magus3/, or from a previous git revision? Do I have to run STM32CUBE?
  • Used to I sometimes needed to run the Magus/ script before building. Is this ever still needed?
  • The last time I built Magus there was a problem where the LEDs were causing signal noise. Should I assume this is fixed? In an emergency, is there a way to disable the LEDs? Is setting LEDS_BRIGHTNESS to 0 in Magus/Inc/hardware.h enough? (The default hardware.h sets “LEDS_BRIGTHNESS” to 2, but this is a typo and will do nothing.)
  • (Not important) I see now instead of MidiBoot there are three directories, MidiBoot1, MidiBoot2, and MidiBoot3. Should I be aware of the differences? Is MidiBoot1 the one I have?


It should no longer be necessary to use CubeMx for building firmware, only to setup a new project. All libraries get pulled as git submodule in repo’s root.

Also, watchdog is enabled in current firmware too, you don’t need to enable it yourself. However it gets enabled only when firmware runs, so you have the advantage of having fallback to bootloader that would work even if firmware fails to run thanks to having that updated bootloader.

LED brightness can be changed in Magus UI directly and it’s saved to settings.

Magus3 is unreleased hardware yet, you should keep using the same project name as before. And you need MidiBoot2 as it’s for different OWL1 versions:

  • OWL1 for the original OwlPedal / OwlModular
  • OWL2 for everything else on STM32F4
  • OWL3 for STM32H7, i.e. Genius, Magus3 and there’s more to follow.

I think that at this point you should just install the official firmware, unless you want to do some hacking.

Okay, fantastic! “Hacking” has been a little chaotic for me so far, so maybe I will stick to writing patches for a bit :slight_smile:
Wiping the storage and installing the sysx from the Github page worked great. All USB host and client recognition issues I was having before are gone. I can now finally use the Magus from both my PC and mac! :​D

I am seeing a couple odd issues. I don’t know if here or elsewhere is the best place to report them. Most noteworthy:

  • I am having serious problems now with the “system” knobs I never had before. Usually if I punch the upper right knob to switch to the Status page then turn the knob, it moves me through the various system pages. Now I am often seeing a problem where I cannot turn past the “patches” page; or where it sticks on the “Status” page and will not move, and attempting to turn the upper right encoder causes the screen to flicker between Status and, sometimes for a single frame, the patches page. A couple times I could get to the patches page fine but then the upper left encoder got stuck flickering between the first two options when I turned it. The knobs seem to always work just fine with normal patches, and on one boot when the upper left knob was wedged on the Patch page it worked fine on the LED slider page. Rebooting often fixes the problem, or sometimes makes it worse. I can post a video of this if it helps. This is a pretty big problem because turning to set the volume and LED brightness are pretty essential on every single boot.
  • Also the LED brightness is not being saved. It always sets itself to 20 when I reboot. This wouldn’t be a problem, except for the other problem.

I also saw one very unusual persistent screen glitch I had never seen before once when I had self-patched the Magus between several patch points and yanked out all of them at once, I may post a video of it just for amusement.

Thanks for the help!

I guess @mars would have to look into that as it sounds pretty bad. Code for processing encoders has been updated some time ago, it seems like something is off now.

The UI system has also been rewritten as old code was getting embarrassingly messy. But we’ve lost a few pages (resource browser, V/Oct calibration) and apparently settings don’t get saved at the moment:

And I think we used to have a flag for marking that settings are dirty to prevent unnecessary writes just because some menu was entered without changing anything. That said, maybe we should have an explicit “save” action on click in “Exit” menu page instead.

Okay, thanks! I filed a Github issue about the encoder problem with a video:

I also filed about the UI glitch I saw, tho obviously this is low-priority or zero-priority: