Maybe try erasing settings in calibration page, there’s a button that handles that. If that won’t help, you could erase the whole flash storage in device page of patch library.
Thank you, but I tried both of those and it hasn’t changed the behavior in any way. The device status on the patch library page is showing the correct firmware and device UUID, but I’m getting a message of “Invalid Resource.”
Anything else I can try?
Well, if you get the error about invalid resource it means that the flash still wasn’t erased. That would leave you without any resources (or patches). You might try the same a few more times and it also makes sense to try erasing storage from the bootloader mode. It can be forced by keeping encoder pressed when the device boots or from firmware update page, might be in the library device page too.
Thanks again, I have tried all of this dozens of times now and the module is still not doing anything. I’ve tried flashing old firmware and it still says it is on 22.5.0. The 7 character display is totally dead and hasn’t shown anything since this behavior started. I’m getting Invalid Sysex and Invalid Resource errors. It won’t even recognize the device on the Openwarelabs pages until I put it into boot mode, and then it sees the device and will even seemingly update, but the module remains lifeless other than the dimly lit LED on Gate Out. Is this thing just bricked for good? I’m not sure what happened here, but I have tried erasing it enough times in all the ways possible that I can safely say that isn’t fixing it. I’ve spent the whole day on this, not sure what else to do.
Based on your description, that’s bootloader version and it won’t change by flashing a new firmware. You will only get a firmware version string once it runs. You can tell which one it is by checking device name which would be OWL-BOOT for bootloader or OWL-LICH for lich. Most likely you’ve flashed a firmware that doesn’t work correctly or had some problems while flashing or with MIDI transfers (which is indicated by invalid sysex errors).
BTW, I think v22.5.0 might have broken USB on OWL as it won’t run on my hardware unless I make a custom build with previous version of USB libraries. You should definitely try to restore FW version that you had as a starting point. But this issue might depend on OS used, because some people report running it successfully too.
These are the messages I received this morning after plugging the usb from the Lich to my computer. You see see where I initiated a FW flash, then at the end I pressed the Firmware tab, followed by device stats, then device ID. I’m hoping this can maybe help you see something about what is going on. The device was working fine for months until I tried the calibration. I may have accidentally plugged into the CV OUT 1 instead of the L OUT when doing the calibration, if that helps pinpoint anything. Again, thank you so much for your help.
I didn’t try flashing any of the old firmwares until the very end of the day after I’d tried everything else, so that isn’t what is causing the issue. I also have the old OWL board in storage as I recently upgraded to a V3 board. Perhaps I can dig the old one up and swap it out and things will work again?
Edit: I realized that I was updating with Lich.syx and not Lich3.syx. Now when I do a FW Flash I’m getting an “Invalid FLASH command” message instead of Firmware upload complete. Also the Owl 3 board is getting extremely hot.
So I’m thinking that I must have wonked something when I loaded the “Lich.syx” instead of the “Lych3.syx”. I tried to force boot mode by holding the encoder down as well as the jumper on the back to be safe, it is only loading OWL-LICH and I can not ever get OWL-BOOT as my device. I’ve tried updating with “Lych3.syx” many times and it either freezes on “sending data xxxxx bytes” or starts updating and then I get “Invalid FLASH command”. Also getting the invalid Sysex errors.
I’m thinking the only thing to try at this point is flashing the Bootloader. I’m assuming that I need to use a programmer and the MidiBoot-Lich3.bin file, yes? Any tips on specifically which Programmer to use and how to use it? I’ve searched quite a bit for this info and haven’t found it so hopefully this can be a resource to others??
Hmm, not sure, maybe you’ve sent firmware to a running firmware and overwritten bootloader this way. I’m not sure if we are able to detect this situation.
There’s multiple threads about flashing here and using openocd with ST-link, i.e. Dead Lich with no Response - #4 by antisvin , Owl Pedal Won't Connect
Programmer that you need would be called ST-Link v2 or something similar. Most likely you want not an official hardware from ST, but a cheap chinese clone that costs ~$5 in most microelectronics stores and looks like this: https://store.fut-electronics.com/cdn/shop/products/stlink-v2-stm32-programmer.jpg?v=1618097661 . Color is pinout can differ, but they generally work fine.
Flashing for OWL3 is pretty much the same as older boards, except that you’ll need to use openocd_h7.cfg config for openocd command.
Perfect, I thought I really dug around, sorry I missed those threads! I’ll give it a shot and confirm that this worked when I get it up and running again. I appreciate the help!
I have this programmer that I used to flash a Befaco muxlicer. Can I use this somehow or do I need specifically a STLink V2?
Nope, this one won’t work unfortunately
Okay, I’ve got the ST-Link V2 programmer, the MidiBoot-Lich3.bin file and the openocd_h7.cfg file. I downloaded openocd to my Macbook but it’s my first time using this program and it seems to go pretty deep. I don’t want to risk messing anything up, I’m much more of a musician than a programmer, can you give me the basics of putting all of this together? I’m getting a lot of “command not found” as I’m poking around openocd trying to get something to work. Do I need to install the 20GBs of “command line developer tools?” I’ve watched some videos and done some reading but haven’t gotten very far.
Sorry, I understand that it can get overwhelming, but I don’t have a Mac and have no ideas how to get openocd working on it. I know that it’s supposingly working with both Homebrew or MacPorts.
I can help a bit with programmer connection, i.e. this is the pins that you have to use:
You don’t need to solder, just take the board from the module and connect wires from below. The ones you need are SWDIO
, GND
, SWCLK
that go one after another. You can also take a look at this OWL1 pinout to understand which one is which. In some cases NRST
is also used, but generally this is a reset pin and we try resetting in software, so it’s optional (but should be safe to connect). +3V3
is sometimes necessary for progammers manufactured by ST, but I think the clones typically don’t use it.
So try connecting those 4 pins to pins with the same name on your programmer.
I think you don’t acually need to use the custom config that we have and something like this should work (with the actual bootloader path, of course):
openocd -f interface/stlink.cfg -f target/stm32h7x.cfg -c "program /path/to/MidiBoot-Lich3.bin verify reset exit"
I ran out of patience with OpenOCD, but was able to get things up and running with STM32CubeProgrammer. I erased, then flashed the Lich3 bootloader bin file and everything seemed good. Restarted the module and yay, the seven segment display is back, only showing an E unfortunately. Restarting into boot loader mode is now functioning as well and I was able to intstall the firmware without a problem. Unfortunately it still just maintains the E on the display and I can load any patches or get the module to do much of anything.
I was able to borrow a PC so I tried installing the boot loader with STM32Cube as well as a firmware flash and still nothing. Everything seemed to go well, flashes completed successfully but nothing more than the E error. I’ve tried erasing everything possible and redoing everything multiple times. Last time I tried I took some screenshots to show the errors I was getting. These messages are the result of me turning on the module and installing the firmware, both in boot mode and normal mode.
Boot Mode
Normal Mode
I’m losing hope, kinda wondering if my flash memory fried somehow, or Owl 3 is no good, or something is wrong with the Owl 3 software. Still willing to keep trying to get this to work if anyone has ideas! I reached out to Befaco and haven’t heard back.
Too bad that it didn’t get resolved after all that “learning experience” Hopefully Befaco support can offer something acceptable as a solution once they’re back to working hours.
It certainly sounds like this could be a hardware problem with your OWL3 board. If you say that flashing firmware or bootloader works, but you have problems with flashing patches or calibration results, then this is a very strong hint that exernal flash storage might have some problems. Patches and resources are stored on a separate chip, while firmware on internal flash on microcontroller itself. So they are accessed in a very different way both in hardware and software side.
Does the same issue persist if you run older firmware version that you had before 22.5.0? Also, make sure to try a different USB cable just in case.
BTW, error status (E on LED) is something you will probably get after erasing patch storage, simply because there’s no patch to run. But I think it would have a different error message in that case.
I love troubleshooting and figuring things out, so this was fun for me. Always a little more fun when I end up with a working product haha.
I have tried different USB cables and every configuration that I could think of. Unfortunately 22.5.0 is the only update with a version for Owl 3, so the older firmwares and bootloaders won’t work. I’m kinda wondering if there could be a problem with the v3 softwares since they are the newest, and don’t seem to be getting regularly updated anymore. Not sure what’s going on there but over a year without an update seems like a bad sign for future development.
Anyway, thank you so much for helping me through this, I’ll hope to hear back from Befaco at some point!
@taylorthediscordian , if you don’t mind doing another experiment and still have that OWL3 board, I was discussing something with people from Befaco and I wonder if your unit could have problem with overheating. It would be interesting to hear if you get the same problems if you keep it outside of the case and ambient temperature is not too high. Maybe even blow with some cool air with a fan.
I obviously don’t suggest that as a permanent fix, just a test.
Yeah, I’m happy to try anything at this point. Most of my flashes and testing were done outside the case, but I tried it this morning keeping everything “cold” as possible, not letting the module sit after I turned it on, and got similar results. I was able to get a “firmware upload complete” after flashing it, but that has happened before and it still goes back to the E message.
I went to go and try to load a patch from the owl patch site just in case but the site is down again. I will see if something has changed when the owl patch site is online again.
I was able to track down someone with a working Lich with an Owl 2 board and they were kind enough to let me swap Owl boards. The Lich started right up with no issues, so I can confirm that the problem is with the Owl board and not anything else in the Lich. I will also note that the Owl 2 was not heating up anywhere near as much as my Owl 3 upgrade board.
I also finally heard back from Befaco and they just told me to try uploading the firmware again. I’ve done this more times than I can count. They also said to ask for help on this forum. Not very helpful.
OWL3 is certainly much hotter, but generally it’s not a problem - at least for a few of those boards that I have. From what I’ve heard, a small fraction of OWL boards can overheat and become unstable if they are used in small cases with bad ventilation after you run them at very high load (~90% CPU) for a fairly long time. So lots of preconditions and such heave patches are not even present in the library (well, maybe a few were already made for OWL3 specifically)
The reason why I thought about it is that sysex checksum error that you’ve mentioned could be one of the symptoms, but it’s possible to get the same error for other reasons too.
If you want to flash any patch for testing while the main site is down, you probably could try those made for Witch as its sub-site is still working - https://witch.rebeltech.org/ . You won’t have access to all parameters, but for testing data transfer this is ok.
Still getting nothing, patches won’t store or load at all. Let me know if you have any other suggestions, I’ll keep trying anything I can on my end. Pretty sure at this point I got a bad Owl board though.