Building the Magus firmware

OWL Magus
, ,
#21

There’s no separate repo for this, it’s been added to bootloader project itself. Just not distributed to end users yet. Bootloader itself is built similar to Magus firmware. So what you should do:

  1. Build MidiBoot with USE_IWDG enabled in MidiBoot/Inc/hardware.h

  2. Build whatever firmware you want to use for Magus with USE_IWDG enabled in Magus/Inc/hardware.h . Not doing this would cause your device to return to bootloader - for watchdog there’s no difference between device that just hangs or is built without this option.

And you’ll have to do your own research for using openocd. MidiBoot has all the necessary commands in its Makefile, but something may need tweaking in openocd config. IIRC, my Chinese clones of ST-Link don’t have a working reset andt require commenting out this line in openocd config: https://github.com/pingdynasty/OpenWare/blob/master/Hardware/openocd.cfg#L10

#22

Yes, sorry! I think it is part of the same problem, of having to first generate then customise the libraries. I’m not keen on maintaining a patch-script for every subproject, and trying to keep them up to date with whatever the Cube might throw at us.

Around 50M in source, after pruning. Not small.

#23

We could have a fork of cube drivers with custom patches and FreeRTOS as git submodules. Then main repo won’t be slowed down from extra code.

I think CubeMX can be configured to only generate source for project and not fetch all dependencies. So running cubeMX would be required only for setting up new projects.

1 Like
#24

Hm, so to be clear, does this mean if I install the upgraded/safe bootloader, and then I install an official Magus build from the releases page, that the official builds WON’T work with the safe bootloader? Or are the official builds being built with USE_IWDG now?

#25

Yes, without watchdog-enabled FW you will be returned to bootloader. And I think that doing it the other way around (stock bootloader + watchdog FW) may leave you with device that hangs after booting. Currently there are no FW releases that enable it (it was actually added not so long ago). I suspect that it would only be used officially by later devices.

Btw, it’s not mandatory to use bootloader at all if you’re using programmer to flash FW. FW can run on its own and you will probably end up not using bootloader to run debugger.

#26

@antisvin , I’m trying to follow your instructions on attaching the programmer so I can install the watchdog bootloader… I am trying for now to do it without soldering. The programmer comes with the female version of “jump wires”, I am not sure the term for them, so I just need to affix those to the pins.

EiX_KPFWoAAK41K.jpeg2048×1152 295 KB

Uh oh. So I think I need to remove the white card and attach the programmer wires to it. But the white card is basically fixed in place by all the wires above it. I’m not sure where to pull.

I assume the white card “on top” is the “IO card”, which you said I might have to remove? But I am not sure how to remove that, either…

How should I proceed? Maybe I could test the USB branch without installing the new bootloader.

Sorry for all these basic questions, I’m pretty helpless with hardware :frowning:

#27

Hi @mars, I tried checking out the current head of develop branch so I could test if it fixes my USB-MIDI woes. I got the following build error

make[1]: Entering directory '/mnt/c/Users/Andi/work/gh/OpenWare/Magus'
/mnt/c/Users/Andi/work/gh/OpenWare/Source/ProgramManager.cpp: In function 'void onProgramReady()':
/mnt/c/Users/Andi/work/gh/OpenWare/Source/ProgramManager.cpp:245:20: error: 'parameter_values' was not declared in this scope
   updateParameters(parameter_values, NOF_PARAMETERS, adc_values, NOF_ADC_VALUES);
                    ^~~~~~~~~~~~~~~~
/mnt/c/Users/Andi/work/gh/OpenWare/Source/ProgramManager.cpp:245:54: error: 'adc_values' was not declared in this scope
   updateParameters(parameter_values, NOF_PARAMETERS, adc_values, NOF_ADC_VALUES);
                                                      ^~~~~~~~~~

I tried doing a make clean, “git clean xffd” and a reset and I re-ran STMcube. I got the same error.

I see adc_values is defined behind a USE_ADC ifdef guard and parameter_values is behind a USE_SCREEN guard. Am I doing something wrong in my build, that these two defines are not being set? I don’t know what changed but I did not see this error with builds of older commits.

In any case I think it is a bug that when USE_ADC and USE_SCREEN are undefined, the updateParameters() call is still included. Probably that call should be behind the USE_ADC call (for example) also.

By the way, I have sent you a minor pull request.

#28

It’s fairly straightforward to remove the digital board from Magus:

  1. unscrew audio jacks on the outside

  2. remove IO panel (the narrow panel that hold all jacks) - there’s no need to unplug cables, just move the panel outside the case

  3. now there’s enough space to pull out digital board

Do it a few times and you’ll really want to solder headers for quick access.

And yes, you don’t have to install the bootloader. I mostly tried to explain that you should have a programmer ready when installing unstable FW. Updated bootloader is an alternative to that, but it’s not mandatory to use it.

#29

Speaking of PRs, I’ve made one for fixing this very issue just yesterday - Develop branch won't build on devices with screen by antisvin · Pull Request #15 · pingdynasty/OpenWare · G

But I haven’t run it on Magus, just made sure that it builds. Actually, recent updates in develop branch broke something related to USB interrupts on device on which I’ve ran it. So there’s a good chance that it won’t work on Magus, since it’s obvious that Martin never built latest commits on it. Nevermind, seems to run fine.

#30

Thanks @antisvin. Can confirm your PR#15 makes it build.

When you say “unscrew the audio jacks on the outside”, what do you mean? I see a little hex screw thing on the side. Or am I supposed to find a hex wrench thing and physically unscrew the jacks…? Again sorry about these basic questions.

EiZNQQbXsAcQstK.jpg2048×1152 170 KB

#31

@mars: I did a test with ddfe79cf55f1 (current develop head) merged with a447765258d9 (antisvin’s PR#15). Testing with the Korg microKEY Air, I am still seeing the MIDI drops in both patches I tested. If anything the success rate may have dropped a little.

What would you recommend? Should I try the USB Full Speed setting as antisvin suggests? The USB-MIDI drop issue is the main thing preventing me from using the Magus for music right now.

#32

A second thing for @mars – Here is my attempt at a “how to build firmware for Magus” tutorial.

I’m not sure where the proper place to submit tutorials is.

I think the tutorial is unfinished because (1) I am still confused how to attach the programmer by these instructions… and (2) I would like to add a final section explaining how to build a patch locally. But the main part should be good reproducible steps.

1 Like
#33

Yup, those 3 hex nuts for audio jacks should be unscrewed using a wrench or pliers. A good engineering solution would be to try fingernails in case if they’re not too tight :wink: Teeth are not recommended, because device warranty won’t cover potential dental damage.

#34

Sorry I’ve not had time to dig deeper into this. I don’t think changing between USB FS/HS will work, tbh, at least I don’t see how. We use the internal FS PHY (physical interface), to run in HS requires an external PHY.

There are a couple of other things we can try: USB DMA, and a dedicated IRQ for one of the USBH endpoints. But the latter will probably required circumventing the USB Host middleware.

What I really want to try is running the USBH process on a 1ms timer - I’ve got some code for it, but need a bit of dedicated time to test it. Definitely will happen this week.

#35

A bit more digging reveals that there is (I think) an interrupt associated with USBH IN and OUT requests, in the HCD handlers - see HCD_HC_IN_IRQHandler and HCD_HC_OUT_IRQHandler. So perhaps there’s a more elegant and efficient solution to this.

#36

I have not founds precedents of anyone using those interrupts for something like this. I think they would be called too frequently to be used for processing user data. Most discussions about those interrupts on ST forums are related to our old friend - mr. “NAK flood fix”.

I thought it was running in HS mode after seeing #define USBH_HANDLE hUsbHostHS in config, now I see that it’s using FS mode for it in cube project.

Not sure if that’s relevant, but recently I’ve noticed that Axoloti FW had its USB stack change the same ST USB library that we use from USB library developed by chibios community. The commit message mentioned that it was done because previously used library required USB DMA. I haven’t understood what exactly was the problem, but sounds like there were some issues.

#37

Anything you can do to look into the MIDI drop problem is appreciated, I do wonder about this one solution— does this mean MIDI would have up to 1ms latency to be processed? Is that normal? It seems like MIDI events can happen on finer timescales than that )but I don’t know if PC operating systems do any better)

#38

[EDIT: NEVER MIND]

Eidg1E2XYAAoUCH.jpeg2048×1152 329 KB

#39

This is probably normal and totally fine, because:

  1. MIDI data will be stored in buffer

  2. Your patch would be processing it every 1.33 ms with current sampling rate and buffer

So processing MIDI more frequently would mean that it would just spend more time in buffer, waiting for patch to process new events.

And if you really want to compensate this 1ms latency, you can move monitors closer by 34.3 cm.

1 Like
#40

It’s a bit tight, but you simply need to pull