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?
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.
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.
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!
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.
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.
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:
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?)
For now I can confirm that:
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.
Yeah, when I’ve just reflashed bootloader without making a full erase, it still wasn’t working after reboot. And since device doesn’t seem to even start firmware booting (display, LEDs were not initialized), it can’t be an issue with patches - that would manifest only after booting is done.
Regarding remote debugging, I often use it for troubleshooting the other firmware I’ve mentioned. But Magus debug build gives me an error due to flash size exceeded:
Build/Magus.elf section `.data' will not fit in region `FLASH'
region `FLASH' overflowed by 400 bytes
Btw, I’m using vscode with this plugin for debugging - Cortex-Debug - Visual Studio Marketplace . Would recommend to check it out.
Well, no luck with any firmware files that I’ve tried. Then I’ve flashed debug firmware (without bootloader). With -O1 or -Os there’s enough space for debug firmware, and it looks like booting is stuck in a loop here:
Somehow HAL tick doesn’t get incremented - no idea why that started happening. It’s something that should be done by SysTick interrupt handler, so maybe something changed in Cube generated files and now we’re initializing RAM too early. But commenting out that line gives me a module that can boot. Except that there’s an error on display saying “failed to start program task” - not sure if that’s due to lack of bootloader, user patches, but I’ll restore bootloader and try loading something to check if that would solve it.
I’d say now would be good time to confess if you’ve uploaded firmware releases without testing it on every device.
Ok, the error was just due to no patches on device. And I’ve flashed bootloader and then loaded firmware without issues. I hope nobody else is going to have bricked devices.
I’ve just tested the upgrade procedure again, with the Magus.syx from github release 20.6, and it works for me.
Could you try adding __enable_irq() in Magus/Src/main.c line 198, before the call to SDRAM_Initialization_Sequence(&hsdram1); ?
I don’t know why interrupts would still be disabled for you at this point, seems very strange. Unless there are some other higher-priority interrupts firing away at the same time, but that seems even more unlikely.
Ok, so I’ve reflashed last version (without delay loop) to confirm that it still works. Then uncommented HAL_Delay and enabled IRQs like you’ve suggested - that also booted. Then removed __enabled_irq again to double check that it’s not something else - that gave me a brick with wooden cheeks again.
Unless there are some other higher-priority interrupts firing away at the same time
Wouldn’t that just delay SysTick handler call if there’s higher priority interrupt (simply adding some jitter to our timing)? It seems like it would take a constant flood of interrupts to prevent SysTick from advancing.
Oh wow. Worrying! I’ll take the v20.6 release down and add a call to __enable_irq().
Thank you @antisvin
Could this be the reason why it worked for you? If you didn’t run it from flash, this could explain why you couldn’t reproduce the issue.
Also, it could be happening to other devices that have SDRAM, not just Magus
I’ve tried firmware v20.5 with which I had no problems before and now I get the same hanging after flashing. This could mean that the issue is caused by specific bootloader version - maybe you should try testing it with latest MidiBoot if your Magus was running older one.
We disable IRQs in bootloader before jumping to application - OpenWare/main.c at master · pingdynasty/OpenWare · GitHub . So it makes sense that they should be enabled later explicitly - I can’t find where we do that.
I wonder if disabling IRQs was working the same way before this commit - added missing getFirmwareVersion() and changed to use __disable_irq()… · pingdynasty/OpenWare@b1f6ee9 · GitHub - not sure how much accessing register differs from ASM call that CMSIS does.
We don’t run code from SDRAM, but we do run patches from SRAM. I think in that case the poster just forgot to set the VTOR pointer correctly.
Huh, interesting.
The previous way of disabling interrupts was with RCC->CIR = 0x00000000. That is also executed in SystemInit(), which is still called before entering main.
Okay so I can confirm that the change in the bootloader causes the firmware to hang unless __enable_irq() is called, which previously it wasn’t.
I’ve published a new Release v20.7 which fixes this
If you’ve flashed v20.6: don’t panic!
The bootloader change was introduced in Feb this year, and no products have shipped with this version. So it is only if you’ve built and flashed a new bootloader yourself that this could be a problem.