Building the Magus firmware: 2022 edition

mcc · June 7, 2022, 10:58pm

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/cube-update.sh 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?

Thanks!

antisvin · June 8, 2022, 7:14am

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.

mcc · June 9, 2022, 4:30am

Okay, fantastic! “Hacking” has been a little chaotic for me so far, so maybe I will stick to writing patches for a bit
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!

antisvin · June 9, 2022, 6:58am

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:

github.com

RebelTechnology/OpenWare/blob/develop/Source/MagusParameterController.hpp#L819

    
      
          
          
class ExitPage : public Page {
          public:
            void enter(){
              uint8_t patchselect = selectPatchPage.patchselect;
              if(patchselect != program.getProgramIndex() &&
                 registry.hasPatch(patchselect)){
                program.loadProgram(patchselect);
                program.resetProgram(false);
              }
            } // todo: save settings if exited with ENCODER_BUTTON_R
            void draw(ScreenBuffer& screen){
              if(!params.isEncoderPushed(ENCODER_BUTTON_ANY)){
                // leave configuration mode on release
                setDisplayMode(STANDARD_DISPLAY_MODE);
              }else{
                screen.setTextSize(2);
                screen.print(40, 26, "exit");
              }
            }
          };

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.

mcc · June 9, 2022, 7:40pm

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

github.com/RebelTechnology/OpenWare

v22.4.0 breaks encoders in "system" menu UI

opened 07:33PM - 09 Jun 22 UTC

mcclure

Installed v22.4.0 from the Github releases page on a 2019 Magus (with custom-ins…talled MidiBoot2 with watchdog). It works great EXCEPT that on something like 50 to 70% of bootups, the system UI is broken. By "system UI" I mean the special UI where you press the upper-right encoder in and it takes you to the "Status" page, and then you can use the upper-right encoder to switch between various pages and the upper-left encoder to select/alter items on those pages. Depending on the boot, I see various combinations of symptoms: 1. It works as expected 2. Turning the upper-right encoder has no effect at all, but if I do enough of it it sometimes flickers the "Patch" page for a single frame 3. Turning the upper-right encoder works, but I can only access the Status and Patch pages, not Volume or LED brightness 4. Turning the upper-right encoder works, but on the Patch page the upper-left encoder does not work, it will not leave Patch 1 but if I do enough of it it sometimes flickers between Patch 1 and Patch 2 for a single frame I made a video in which I show state 2 ["bad"], but then power cycle and it goes into state 1 ["good"]: https://youtu.be/xkTNR5fUAFw (Please excuse my messy desk) When I am in states 2, 3 or 4 both the upper-left and upper-right encoder work completely as expected in "normal" mode (IE upper-right encoder can select parameter and upper-left parameter can change parameter value) and in state 4 the upper-left encoder works as expected on system pages other than "Patch" (that is it changes volume or LED brightness no problem) When the bug happens the Magus is mostly unusable as I cannot select patches, and I usually want to change Volume and LED Brightness right after starting up.

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

github.com/RebelTechnology/OpenWare

One-time UI glitch after yanking patch cables

opened 07:37PM - 09 Jun 22 UTC

mcclure

Running v22.4.0 on a 2019 Magus (with custom-installed MidiBoot2 with watchdog) …I was running a patch with a series of patch cables running from Magus parameters to other Magus parameters. I yanked all the patch cables out at once and suddenly the UI started acting strange. About once a second the screen would randomly "scroll" horizontally and vertically, and periodically all the LEDs would turn a mellow red at the same time. I made a short video: https://youtu.be/ntaONKp6LMI I was not able to capture the red encoders in the video. the normal behavior of this patch is to display "F4 F4 F4" (or 3 of whatever note was last pressed on the keyboard) and the series of vertical lines at the bottom of the screen is also normal. The only unusual thing is the scrolling. This only happened once and is not interfering with device usage, so you may close this issue. But it was unusual I wanted to file it...