Make Owl Great Again!

OWL Firmware
, , , ,
#1

@mars here are some good news for you. I wanted to give Openware FW on Owl a go and noticed that current version won’t even build. So I’ve managed to fix some regressions and updated CubeMx to latest version (5.6.0).

There was an error due to codec_init function having different arguments for Owl’s codec. I’ve moved its definition to Codec.h file to have it in one place and made it conditional there to handle different codecs’ requirements for register data width. It’s possible to have each codec’s own definition in respective header instead, but then it should be removed from Codec.h to avoid conflicts.

Other than that, some fixes were required in linker script, makefile - figured that out based on current Magus files. Fixed USB to use MIDI IF instead of audio, as usual. For now I’ve only made sure that patches run and MIDI data is handled in user patches. Other changes are by Cube overwriting its own generated files (i.e. USB stuff had some changes), this should be double checked.

PR is at Update for building OWL FW with CubeMX 5.6.0 by antisvin · Pull Request #2 · pingdynasty/OpenWare · GitHub</tit .

Also, I’m thinking about adding V/Oct calibration procedure. I think it would be one of the following:

  1. done from patch and stored with a custom service call
  2. special mode triggered with sysex command
  3. triggered by pushbutton pressed on boot

Will do more research about this, but comments are welcomed.

3 Likes
#2

I looked over your pull request, but I am so new to this I have no idea what could possibly be wrong. It looks ok at a glance, but I think someone with more knowledge should approve it. I suppose if no one replies after some time, you can hit me up to OK it.

It looks like you did a lot of work on the driver. I don’t own an OWL, only a Magus. Is there something I can do to test the code?

wish I was more helpful, but I’m just a n00b.

1 Like
#3

I not sure what a lot of this means exactly but if you’re working on improving the Owl’s firmware, my hats off to you. I would do it myself if I knew anything about how to but my knowledge is limited to Max and Pure Data unfortunately.

#4

I looked over your pull request, but I am so new to this I have no idea what could possibly be wrong.

This PR is mostly intended for Martin to review. There’s no new features added yet, but there could be some issues fixed in more recent firmware version or in vendor-provided libraries.

I did make some customizations to Magus firmware too, actually quite substantial amount of issues/annoyances were addressed there. Details in this thread: V/Oct calibration on Magus . I’ve just uploaded a build for anyone interested in testing it, I think it’s better to discuss it in that topic if there’s some feedback.

2 Likes
#5

I’m on it now Stas!

I had a load of changes to merge in which I’ve now pushed as release v20.6

I’ve also published a firmware update tool (for devices with a MIDI bootloader: Alchemist, Wizard and Magus):
https://pingdynasty.github.io/OwlWebControl/firmware.html
Try it out - you will likely need to Chrome for it to work.

Will check and merge in your pull requests over the next few days.

1 Like
#6

Congratulations, it sounds like the joys of quarantine improved your productivity :wink:

Will give web based uploader a go today. I normally just use a script to send sysex to devices, but this can be convenient for sending other commands. And I’ll try rebasing current PRs as well. I think that firmware release for Owl1 can be added after that, it’s sad to see it omitted.

It’s a bit unfortunate that most Magus stuff wasn’t merged before this release - lots of useful stuff in there. But this calls for a shorter release cycle for next version.

1 Like
#7

I’ll do the rebasing of the existing PR’s, it’s only fair since I created the conflicts!

#8

Second one is already rebased and it had no conflicts. I don’t mind updating the first one myself too.

#9

Ok rebasing was not a big deal, looks like your last commits haven’t touched parts that I was changing before.

As for web control, turns out that currently my chromium doesn’t work with web midi. Well, it does support it, but won’t find any midi devices. I suspect it may be because it’s built without pulseaudio disabled. Pretty sure it’s not an issue in your code.

#10

Also, I’ve started looking into adding V/Oct calibration that would be usable for other devices.

One approach would be to add service calls for sending offset/scalar value and base code for doing calibration. Calibration itself would run as user patch, but the patch itself would mostly need to define device-specific callback(s). This sort of duplicates the effort done for Magus UI, but most code would go to OwlProgram repo and result would give user more control.

An alternative could be to have an extra sysex code for entering calibration mode in firmware.

Callback that I’ve mentioned above is for getting user confirmation before going to next calibration step (so it could check button state, encoder value or maybe even read results sent as MIDI/CC). If we rely on getting confirmations from physical controls, we’ll need device-specific code for handling that. But potentially we could have an approach with sysex-triggered calibration mode and MIDI/CC-based confirmation that would let us handle calibration on any device without using its hardware controls. And if we do it using MIDI only, it probably can be integrated into web control tool.

Would really love to hear what sounds best to you

#11

I like the idea of putting calibration into a user patch. Since it would only be used infrequently it makes a lot of sense. We already have a SysEx interface for setting configuration parameters, maybe we can use that.

So the calibration tool would consist of a Web MIDI page and a custom patch, that talk to each other. I like that. At the end, the settings would be sent to and stored in the device using SysEx. Perfect.

#12

Ouch. My Magus stopped working completely.This happened after it stayed unpowered for a few days, not after flashing new firmware and it doesn’t seem to even start booting. Powering with different USB cable or PSU makes no difference. I only get a brief flash from LEDs (red&green color) when cable gets inserted. Is it time to write support email?

Is the header marked “Boot” on IO board for booting into DFU mode?

#13

Yes that header is for DFU mode, but depending on the chip revision it might not work.
You can send it back to us and we’ll fix it, please email info at rebeltech dot org.

#14

And the header didn’t work. But I think that there’s a possibility that I’ve uploaded firmware for Owl while Magus was connected and haven’t realized that it happened. It looks like current Sysex firmware upload procedure doesn’t validate that incoming data was built for the same hardware on which it will be loaded. Maybe Sysex firmware command should be accepting device hardware ID as parameter.

Could you let me know if there’s some other way to access DFU mode or maybe there’s SWD header that I could use on Magus? I think that I should at least confirm that this is not a mere firmware upload issue before sending it for repair.

#15

There is an SWD header on the digital board. Have you got a programmer, like the STLink v2, a Nucleo or Discovery board, or similar?

The SWD header is in the same position as on the old OWL Digital board:
https://web.archive.org/web/20161005013354/https://hoxtonowl.com/mediawiki/index.php/OWL_Digital

To flash it you should take the digital board out, connect the USB VBUS pin to a +5v pin with a jumper cable, and power it with USB Micro. Happy to help with the details. Also happy to do it for you, if you prefer to send it back!

#16

Yeah, I’m using Stlink v2 clone - been working on a custom firmware for another device during last few months (Koma Fieldkit FX). Your instructions are clean enough for me, so I’ll give it a go soon. I see that MidiBoot directory has openocd commands for erasing/flashing it, so I could probably use that to reset device state to empty bootloader and then load correct firmware from Sysex file. If that won’t work, this would likely mean it’s a hardware issue after all.

I think that a roundtrip by mail to UK would take close to 2 months nowadays, so I’d rather do that only as last attempt.

#17

Ouch! Well as long as you don’t run over it with a truck you’ll always be able to send it back to us for repair, in case it doesn’t work out. Warranty not void!

First thing would be to simply connect with openocd and see if it establishes a connection. If it does, all should be fine.
To build and reflash the bootloader, in MidiBoot do something like: make PLATFORM=Magus clean all unlock flash
And yes, go ahead and try out erase and other targets to clear it completely first, it will prevent it trying to load a corrupt firmware. With a programmer connected I don’t think there’s anything you can do in software that will brick it.

Building the Magus firmware
Building the Magus firmware
#18

Well, it’s been (almost) a success. I managed to flash bootloader and after that MIDI device appeared upon reboot. Yay, no need to go to post office amid zombie infestation. So it was a firmware issue after all. But then I flashed current firmware from master branch (not including my custom code just to be safe) and now Magus is bricked again. Which means that I didn’t flash wrong device firmware like I thought, but there’s either a regression in firmware or my build environment.

Here’s what I’ve previously used:

FirmwareSender -in Build/${PROJECT}.bin -flash `crc32 Build/${PROJECT}.bin` -save ${PROJECT}.syx
amidi -p hw:3,0,0 -S f07d527ef7
amidi -p hw:3,0,0 -s ${PROJECT}.syx
amidi -p hw:3,0,0 -S f07d527df7

Does it look like it should still work?

Next things to try:

  1. Re-export cube code
  2. Rebuild FirmwareSender - I’ve noticed that there’s been a few recent commits in that repo.
  3. Try older firmware version
  4. Try last stable and previous release from github releases

Also, I’m thinking about getting some double height pins to replace headers connected to SWDIO pins - to make extra height accessible from back side of digital board. This would make it possible to connect programmer without taking out front panel and digital board. Would you say that such modification (if done with no additional side effects) should void warranty (or only trucks do that?)

1 Like
#19

For now I can confirm that:

  1. Updating FirmwareSender made no difference
  2. I get the same result when sending official release (using Magus.syx blob)
#20

Great that you got the bootloader flashed with the programmer. Did you erase the flash beforehand? If not, maybe there’s a dodgy patch causing the firmware to hang.

On a related note, I’ve been meaning to add IWDG functionality, ie set up the built-in watchdog so that if the firmware (or a patch) hangs, it reboots into bootloader mode. But first I need to verify that we can do it without breaking support for existing (and shipped) versions of the bootloader.

Soldering the header: if it will make it easier for you to contribute to the project, then I would say do it.
The SWD pins are not used on the Magus analogue board, so you could even just remove the existing header pins and put new, regular ones in on the back. Just make sure that the ribbon cable that goes over the back of the digital board still fits.
Alternatively you could populate the little 5-pin PicoBlade connector, that is what we use here for debugging. Very handy for a small, removable connection. The connector breaks out VREF, SWCLK, GND, SWDIO and NRST pins.

btw have you tried debugging with gdb remotely, using the programmer? It’s really magical stuff, you can single step et c directly on the device, just like you would a locally running program.